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
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
···
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
···
On 2012/09/30 7:14 AM, Michael Droettboom wrote:
On 09/29/2012 08:07 PM, Eric Firing wrote:
Mike
I had an idea this morning about how best to resolve this. I think the
developers' lives would be made slightly easier if contributors knew
where to branch from at the outset. I think when most people submit a
pull request (myself included) they automatically branch from master.
This is where the problem lies. If someone is submitting a bug fix
during a release cycle they should almost certainly branch from
v1.2.x, or whatever the current version branch is. This way, if the
pull request gets accept it's trivial to merge it into the correct
place (v1.2.x) and if it's accepted but is not deemed suitable for
v1.2.x it can be rebased onto master. This avoids the, in my opinion,
ugly cherry-picking solution.
Since all of our patches and contributions are taking place on github,
to get this information to contributors I propose updating the
readme.txt file to include this information. It's the first thing
people see when they're on the matplotlib github page so I think it
would make a big difference.
How does that sound?
···
On Sun, Sep 30, 2012 at 9:24 PM, Eric Firing <efiring@...229...> wrote:
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
--
Damon McDougall
http://www.damon-is-a-geek.com
B2.39
Mathematics Institute
University of Warwick
Coventry
West Midlands
CV4 7AL
United Kingdom