I am also merging fast-forward and can't say that the information gets lost who merged the commit (see https://github.com/apache/couchdb-fauxton/commit/8a1aaff198ceb16a4754dfce8453fda80fd17783 )
Regarding the process/tooling: I just started to use git-apply-pr ( https://github.com/joyent/git-apply-pr) which we use in the node project for fauxton, it adds nice metadata to the commit: https://github.com/apache/couchdb-fauxton/commit/cfd9ec85913879069d0294779a1eb6b700026b2a hint: it also solves the problem of not referencing the PR and discussion :) On Mon, Mar 23, 2015 at 12:28 PM, Alexander Shorin <[email protected]> wrote: > Hi Garren, > > I cannot say that is your workflow is wrong neither I cannot say the > mine is not. I'm more interested to define the one with which everyone > (or at least majority) is happy (: > > The default merge behaviour is fast forward, but it fallbacks to no-ff > if git cannot perform it or you're merges a tag. So it can have a > problem of p.2 when information about a committer is lost. > > P.S. Thanks for sharing gist! Very useful. > > -- > ,,,^..^,,, > > > On Mon, Mar 23, 2015 at 11:27 AM, Garren Smith <[email protected]> wrote: > > Here is how the Fauxton team merge our commits. We probably don’t follow > the most scientific method but it seems to work well enough. > > > > 1) Add ability to remote fetch PR’s > 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’s) > > 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’m not sure. > > > > I will now wait for Alexander’s email that tells me how wrong we are :) > > > > Cheers > > Garren > > > > > >> On 22 Mar 2015, at 10:02 PM, Alexander Shorin <[email protected]> wrote: > >> > >> 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! > >> > >> -- > >> ,,,^..^,,, > > >
