[IPython-dev] Tips on merging: the green button is good...

[Aaron Meurer]

We've also found the green merge button to be a good thing with SymPy.
 I was initially reluctant to the idea because it would make it too
easy to accidentally merge a branch that's not ready yet.  But we've
merged hundreds of pull requests since it's inception, and I don't
think that has happened once.

In addition to the advantages you list, the green button helps prevent
accidental pushes to master.  It's really easy to mess things up with
the command line, as git will basically let you do anything you want,
and you don't always see what you're doing unless you use git log
--graph or a similar visualization.  With the merge button, you always
see exactly what commits and diff are being merged.  You cannot
accidentally force push to master, and you won't have bad commits slip
in or good commits slip out through a messy rebase process.

Another advantage: requiring that all updates to master go through the
green button also essentially adds the requirement that all update go
through a pull request, which is in general a good thing as well.

Regarding the forced merged commit, this is also a good thing, as it
makes it easier to find the pull request discussion given a commit.  I
couldn't figure out how to get the merge commit from a given commit,
though, other than finding the commit in git log --graph (or something
similar like gitk) and following the line up to the nearest merge
commit.  Anyone know a git oneliner to do this?

Aaron Meurer

On Fri, Jan 20, 2012 at 2:48 PM, Fernando Perez <fperez.net at gmail.com> wrote:
> Hi folks,
>
> I just wanted to mention some things regarding workflow that we kind
> of settled on in the 0.12 merge frenzy but that we haven't really said
> explicitly in a summary.  A while ago, I had defended the idea that we
> should allow fast-forward merges and even force them via a rebase for
> really small PRs of one or two commits; my argument was that this kept
> a more linear and clean history, without adding 'unnecessary' commits.
>  But in the run-up to 0.12, Mateusz and Min talked about it and Min
> came back with some good points in favor of *always, exclusively*
> doing merges with the green button.
>
> The main point is that by doing the merge with the green button, we
> gain evidence for what code was reviewed and what wasn't.  When a
> merge is done that way, the merge commit has a link to the review
> right there, that is even clickable in github.  This way, even single
> commits that were reviewed can be distinguished from commits that were
> pushed without review.  In the long run, this information is useful to
> the project, and in fact shows a flaw in my original argument.  I said
> that the extra merge commit was 'noise', but in reality that extra
> commit is data: it links to the *review* of the commit(s) being
> merged, and so it's in fact very important data and certainly not
> noise.
>
> Furthermore, we gain:
>
> - the PR is automatically closed, which otherwise doesn't always happen.
>
> - it's super easy to type into the merge message a summary of the PR,
> b/c you can copy straight out from either the initial PR request or
> from relevant pieces of the discussion.
>
> So the workflow we had settled on, and that I hope you will all agree with, was:
>
> - *Always* merge from the 'green button'.
>
> - When doing the merge, add a reasonable summary of the PR in the
> message box, don't just leave it empty.  A good tip is to click on
> 'edit' at the top in the PR request message, so you can copy/paste the
> whole Markdown of the PR.  That text is typically a good starting
> point for the commit message, though I typically trim it down or
> rephrase it slightly so it's a good summary of the PR.
>
> - At the bottom of the merge message, add 'Closes #NNN, closes #NNN'
> as appropriate for any tickets this PR has been confirmed to close.
> This way, github will auto-close them reliably.
>
> That's it.  Once I got used to this, it became very natural.  I use
> 'git mrb' to test locally, then I simply merge the PR with the green
> button and issue 'git pull' right away.  Since git already has all the
> actual commits, the pull is very quick.
>
> Cheers,
>
> f
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev