couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexander Shorin <kxe...@gmail.com>
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
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!

--
,,,^..^,,,

Mime
View raw message