Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: pass (athena.apache.org: domain of gs@redcometlabs.com
 designates 74.125.82.54 as permitted sender)
From: Garren Smith <garren@apache.org>
Content-Type: multipart/alternative;
 boundary="Apple-Mail=_A8822528-782F-4C3B-AA33-66D8094C22D9"
Message-Id: <A1F49AD1-7133-4C13-B3DC-16B0967B57C3@apache.org>
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
Subject: Re: [DISCUSSION] GitHub PRs merging policy
Date: Mon, 23 Mar 2015 10:27:27 +0200
References: 
 <CAHdjip+kTa1Rm6c676uBLHiPXz948ZXd7Qn1oujt=8yOPw6ttA@mail.gmail.com>
To: dev@couchdb.apache.org
In-Reply-To: 
 <CAHdjip+kTa1Rm6c676uBLHiPXz948ZXd7Qn1oujt=8yOPw6ttA@mail.gmail.com>

--Apple-Mail=_A8822528-782F-4C3B-AA33-66D8094C22D9
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Here is how the Fauxton team merge our commits. We probably don=E2=80=99t =
follow the most scientific method but it seems to work well enough.

1) Add ability to remote fetch PR=E2=80=99s =
https://gist.github.com/piscisaureus/3342247 =
<https://gist.github.com/piscisaureus/3342247> instead of having to add =
the contributor each time
2) git fetch (fetches all PR=E2=80=99s)=20
3) git merge pr/111
4) git push

Using that gist is a real time saver. I think by default git merge is =
using git fast forward, I=E2=80=99m not sure.=20

I will now wait for Alexander=E2=80=99s email that tells me how wrong we =
are :)=20

Cheers
Garren


> On 22 Mar 2015, at 10:02 PM, Alexander Shorin <kxepal@gmail.com> =
wrote:
>=20
> Hi devs,
>=20
> 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:
>=20
> 1) Explicit merge aka GitHub workflow
> git remote add contributor https://github.com/...
> git fetch contributor
> git merge --no-ff contributor/pr-branch
>=20
> 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.
>=20
> 2) Fast forward merge.  Same as 1) but without merge commit.
>=20
> 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
>=20
> 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
>=20
> 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)
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> Please share your though on this. Thanks!
>=20
> --
> ,,,^..^,,,


--Apple-Mail=_A8822528-782F-4C3B-AA33-66D8094C22D9--