couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexander Shorin <>
Subject [DISCUSSION] GitHub PRs merging policy
Date Sun, 22 Mar 2015 20:02:43 GMT
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

1) Explicit merge aka GitHub workflow
git remote add contributor
git fetch contributor
git merge --no-ff contributor/pr-branch

- Automatically closes PR on GitHub
- Strong reference to origin of incoming changes
- Responsible committer name is clearly defined in history
- 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.

- Clean history
- Automatically closes PR on GitHub
- The related PR thread may contain some important information about
these changes and the backward reference becomes lost outside of
- There is no information about who did actually merged those changes

3) Apply patches manually
curl -O*/pulls/42.patch
Edit the patch to put magic "This closes #42" into commit message
git am --signoff < 42.patch

- Clean history
- Responsible committer name is clearly defined in history
- Automatically closes PR on GitHub
- 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

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!


View raw message