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 ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://ad.doubleclick.net/clk;258768047;13503038;j? http://info.appdynamics.com/FreeJavaPerformanceDownload.html _______________________________________________ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
