[IPython-dev] Pull request workflow...

[Fernando Perez]

On Tue, Oct 12, 2010 at 12:12 PM, Fernando Perez <fperez.net at gmail.com> wrote:
>
>
> How does this sound for our final take?

One final note (again, not trying to pick on anyone, this time Brian,
just looking at the most recent example): for committers, I think we
should avoid actual merges for cases where it's just one (or even two)
commits.  Otherwise we'll end up with a ton of 'merge branch.. into
master' messages, one per single actual commit.  For example:

*   925c98c Merge branch 'master' into trunk
|\
| * ee8879c Uncommenting reply_socket.recvmore that was broken in 2.0.7.
* | 233d50f Stop-gap fix for crash with unicode input.
|/
* 4e2d3af merge review fperez-execution-refactor

In this case, ee8879 should have been rebased so that it was just
after 233d5, avoiding the need for the extra 925c merge commit.

My rule of thumb has become: just one or two commits, rebase and
commit as a linear set (basically I don't want 1/2 or 1/3 of the
metadata to be just the 'merging' commit).  Three or more are enough
to warrant keeping as their own branch.

But when keeping a branch, then it's important to edit the merge
commit (before pushing) with 'commit --amend' to add:

- Brief summary of what the merge does (especially if the merge
includes a ton of commits)

- If there was a pull request associated, adding

Closes gh-NNN (pull request).

so that Github automatically closes the request and links the commit
to the request in their webpages.

If y'all agree with this, I'll send it all to the summary later.

Cheers,

f