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

[Julian Taylor]

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 <njs at pobox.com>
>> wrote:
>>> On 18 Jul 2014 15:36, "Julian Taylor"
>>> <jtaylor.debian at 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.