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
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
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 Sun, Sep 30, 2012 at 9:24 PM, Eric Firing <ef...@ha...> 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 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? -- Damon McDougall http://www.damon-is-a-geek.com B2.39 Mathematics Institute University of Warwick Coventry West Midlands CV4 7AL United Kingdom