Hi devs, I'm deeply concerned about the way how we should handle pull requests that comes on GitHub. Currently, I see the following ways to process them:
1) Explicit merge aka GitHub workflow git remote add contributor https://github.com/... git fetch contributor git merge --no-ff contributor/pr-branch Example: https://github.com/apache/couchdb-fabric/commit/a4d985252 Pros: - Automatically closes PR on GitHub - Strong reference to origin of incoming changes - Responsible committer name is clearly defined in history Cons: - That's also the way to pollute commit history with useless merge commits. No, they are useful, but not for a single commit changes. 2) Fast forward merge. Same as 1) but without merge commit. Example: https://github.com/apache/couchdb-documentation/commit/27cc733 Pros: - Clean history - Automatically closes PR on GitHub Cons: - The related PR thread may contain some important information about these changes and the backward reference becomes lost outside of GitHub. - There is no information about who did actually merged those changes 3) Apply patches manually curl -O https://github.com/apache/couchdb-*/pulls/42.patch Edit the patch to put magic "This closes #42" into commit message git am --signoff < 42.patch Example: https://github.com/apache/couchdb-fabric/commit/adaf5c23 Pros: - Clean history - Responsible committer name is clearly defined in history - Automatically closes PR on GitHub Cons: - Need to put PR number into commit message to make PR automagically closed on merge - Not suitable for large series of changes - Literally closes PR on GitHub instead of merge (some people concerned about that) I was used the latter one. Recently I'd tried the other ways. I'm not happy with the results and I'm still not sure which way to use for CouchDB. Personally, I tend to follow the first way when PR contains multiple commits and the third when it's a question of some single change. But would like to discuss the this workflow and make sure that mine is fine for the other team. One day we'd tried to write our Git workflow, but it struggled because of some details. Let's return to that idea and make it iterative, case by case. Handling pull requests is a good topic for the start I think. Please share your though on this. Thanks! -- ,,,^..^,,,
