Re: [matplotlib-devel] branch merge strategy

[Eric F. <ef...@ha...>]

On 2012/09/30 7:14 AM, Michael Droettboom wrote:
> On 09/29/2012 08:07 PM, Eric Firing wrote:
>> Mike,
>>
>> I'm getting confused about branch merge strategy.  Usually, it seems
>> that it has been to periodically merge the maintenance branch into
>> master.  Something like this:
>>
>> git fetch upstream
>> git checkout master
>> git merge --ff-only upstream/master
>> git merge upstream/v1.2.x
>> # test, commit changes if necessary
>> git push upstream master
>>
>> Is that correct?
>>
>> At present, however, we seem to be developing fairly long separate
>> threads on the two branches, with duplicate changesets, presumably
>> from cherry-picking.  Is this intentional?  Do you plan to go back to
>> the merge strategy?
>
> A few things were cherry-picked over to 1.2.x, since the PR was
> initially set up against master and github doesn't provide a way to
> change the destination of a PR after creating it.  But that was meant to
> be the exception...  the "preferred" way hasn't changed.
>
>>
>> I can see that a problem with branch merging is that there are
>> occasionally changesets in v1.2.x, such as the rc version tagging,
>> that are not appropriate for master.
> Tags don't merge across branches because tags are just pointers to
> particular commit hashes.  When doing a merge, you always get a new
> commit hash (since the parents are different).  As for updating the
> version number, however, yes, those changes need to be manually
> addressed -- though it usually shows up as a merge conflict, so it's
> obvious that it needs to be done.

Mike,

Thanks. I have performed the merge of v1.2.x into master, and I think 
everything is OK; the changes reflect only the commits that were not 
cherry-picked.  I also reverted what I think was an inadvertent version 
change in master, so now it is back to 1.3.x.

Eric


>
> Mike