Loading docs/CONTRIBUTE +13 −21 Original line number Diff line number Diff line Loading @@ -34,7 +34,7 @@ 3.3 How To Make a Patch without git 3.4 How to get your changes into the main sources 3.5 Write good commit messages 3.6 Please don't send pull requests 3.6 About pull requests ============================================================================== Loading @@ -52,6 +52,10 @@ We also hang out on IRC in #curl on irc.freenode.net If you're at all interested in the code side of things, consider clicking 'watch' on the curl repo at github to get notified on pull requests and new issues posted there. 1.2. License When contributing with code, you agree to put your changes and new code under Loading Loading @@ -288,27 +292,15 @@ and make sure that you have your own user and email setup correctly in git before you commit 3.6 Please don't send pull requests 3.6 About pull requests With git (and especially github) it is easy and tempting to send a pull request to one or more people in the curl project to have changes merged this way instead of mailing patches to the curl-library mailing list. We don't like that. We want them mailed for these reasons: - Peer review. Anyone and everyone on the list can review, comment and improve on the patch. Pull requests limit this ability. - Anyone can merge the patch into their own trees for testing and those who have push rights can push it to the main repo. It doesn't have to be anyone the patch author knows beforehand. - Commit messages can be tweaked and changed if merged locally instead of using github. Merges directly on github requires the changes to be perfect already, which they seldom are. request to the curl project to have changes merged this way instead of mailing patches to the curl-library mailing list. - Merges on github prevents rebases and even enforces --no-ff which is a git style we don't otherwise use in the project We used to dislike this but we're trying to change that and accept that this is a frictionless way for people to contribute to the project. We now welcome pull requests! However: once patches have been reviewed and deemed fine on list they are perfectly OK to be pulled from a published git tree. We will continue to avoid using github's merge tools to make the history linear and to make sure commits follow our style guidelines. Loading
docs/CONTRIBUTE +13 −21 Original line number Diff line number Diff line Loading @@ -34,7 +34,7 @@ 3.3 How To Make a Patch without git 3.4 How to get your changes into the main sources 3.5 Write good commit messages 3.6 Please don't send pull requests 3.6 About pull requests ============================================================================== Loading @@ -52,6 +52,10 @@ We also hang out on IRC in #curl on irc.freenode.net If you're at all interested in the code side of things, consider clicking 'watch' on the curl repo at github to get notified on pull requests and new issues posted there. 1.2. License When contributing with code, you agree to put your changes and new code under Loading Loading @@ -288,27 +292,15 @@ and make sure that you have your own user and email setup correctly in git before you commit 3.6 Please don't send pull requests 3.6 About pull requests With git (and especially github) it is easy and tempting to send a pull request to one or more people in the curl project to have changes merged this way instead of mailing patches to the curl-library mailing list. We don't like that. We want them mailed for these reasons: - Peer review. Anyone and everyone on the list can review, comment and improve on the patch. Pull requests limit this ability. - Anyone can merge the patch into their own trees for testing and those who have push rights can push it to the main repo. It doesn't have to be anyone the patch author knows beforehand. - Commit messages can be tweaked and changed if merged locally instead of using github. Merges directly on github requires the changes to be perfect already, which they seldom are. request to the curl project to have changes merged this way instead of mailing patches to the curl-library mailing list. - Merges on github prevents rebases and even enforces --no-ff which is a git style we don't otherwise use in the project We used to dislike this but we're trying to change that and accept that this is a frictionless way for people to contribute to the project. We now welcome pull requests! However: once patches have been reviewed and deemed fine on list they are perfectly OK to be pulled from a published git tree. We will continue to avoid using github's merge tools to make the history linear and to make sure commits follow our style guidelines.
