diff options
| -rw-r--r-- | docs/CONTRIBUTE | 34 |
1 files changed, 13 insertions, 21 deletions
diff --git a/docs/CONTRIBUTE b/docs/CONTRIBUTE index 83fa42099..fe69238db 100644 --- a/docs/CONTRIBUTE +++ b/docs/CONTRIBUTE @@ -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 ============================================================================== @@ -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 @@ -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. |