On 18.07.2014 19:47, Pauli Virtanen wrote: > 18.07.2014 19:35, Julian Taylor kirjoitti: >> On Fri, Jul 18, 2014 at 6:23 PM, Nathaniel Smith <n...@pobox.com> >> wrote: >>> On 18 Jul 2014 15:36, "Julian Taylor" >>> <jtaylor.deb...@googlemail.com> wrote: >>>> >>>> git rebase --onto $(git merge-base master maintenance/1.9.x) >>>> HEAD^ >>> >>> As a potential refinement, this might be simpler if we define a >>> branch that points to this commit. >>> >> >> we could do that, though the merge base changes to the last commit >> that was merged in that way. The old merge base is still valid but >> much older. I applied this method to some of my bugfixes so the >> current merge base of master and 1.9 is a commit from yesterday >> not anymore the diverging point of master and 1.9. But I don't know >> if the newer merge base makes any difference to git. > > Will the merge base actually ever change if you don't merge the > branches to each other
we want to merge them into each other so a change of merge base is unavoidable. > > The other well-known alternative to bugfixes is to first commit it in > the earliest maintenance branch where you want to have it, and then > merge that branch forward to the newer maintenance branches, and > finally into master. > wouldn't that still require basing bugfixes onto the point before the master and maintenance branch diverged? otherwise a merge from maintenance to master would include the commits that are only part of the maintenance branch (release commits, regression fixes etc.) basing bugfixes on maintenance does allow cherry picking into master as you don't care too much about backward mergeability here, but you still lose a good git log and git branch --contains to check which bugfix is in which branch. _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
