On Fri, Jul 18, 2014 at 8:13 AM, Julian Taylor < jtaylor.deb...@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
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion