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?
***
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.
Pauli
_______________________________________________
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
