[Numpy-discussion] proposal: new commit guidelines for backportable bugfixes

[Charles R Harris]

On Fri, Jul 18, 2014 at 8:13 AM, Julian Taylor <
jtaylor.debian at googlemail.com> wrote:

> hi,
> I have been doing a lot of backporting for the last few bugfix
> releases and noticed that our current approach committing to master
> and cherrypicking is not so good for the git history.
> When cherry picking a bugfix from master to a maintenance branch both
> branches contain a commit with the same content and git knows of no
> relation between them. This causes unnecessary merge conflicts when
> cherry picking two changes that modify the same file. The git version
> (1.9.1) I am using is not smart enough too figure out the changesets
> in both leaf commits is the same.
> Additionally the output of `git log maintenance/1.9.x..master` becomes
> very large as all already backported issues appear again in master.
> [0]
>
> To help with this I want to propose new best practices for pull
> requests of bugfixes suitable for backporting.
> Instead of basing the bugfix on the head commit of the master, base
> them on the merge base between master and the latest maintenance
> branch.
> This allows merging the PR into both master and the maintenance branch
> without pulling in any extra changes from either branches.
> Then both branches contain the same commit and gits automerging can
> work better and git log will only show you the commits that are only
> really on one branch or the other.
>
> In practice this is very simple. You can still develop your bugfix on
> master but before you push it you just run:
>
> git rebase --onto $(git merge-base master maintenance/1.9.x) HEAD^
>
> In most bugfix PRs this should work without conflict as they should be
> relatively small.
> If you get a merge conflict during this operation, just do git rebase
> --abort and do a normal pull request, in that case the backporter
> should worry about the conflict.
>
> Does this sound like a reasonable procedure?
> Cheers,
> Julian
>
> [0] git cherry is supposed to help with that, but it never really
> worked properly for me
>

Arrived here promptly. This looks OK to me, but with the understanding that
a number of folks won't know what is going on. It should be documented in
doc/source/dev/gitwash/development_workflow.rst and perhaps a command alias
in .git/config would help, something like npyrebase, or hopefully something
better ;)

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20140718/0bff5354/attachment.html>