matplotlib-devel Mailing List for matplotlib

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

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

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?
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.
Eric