Matthew, On Thu, Jun 2, 2011 at 8:17 PM, Matthew Brett <matthew.br...@gmail.com> wrote: > Hi, > > On Thu, Jun 2, 2011 at 5:07 PM, Darren Dale <dsdal...@gmail.com> wrote: >> On Thu, Jun 2, 2011 at 7:46 PM, Eric Firing <efir...@hawaii.edu> wrote: > ... >>> Even without the foulup, I think you would see that the merges from >>> maintenance branches into subsequent branches and into master make it >>> very hard to figure out what has actually been done on any given branch. >> >> I strongly disagree. The only reason you get cleaner history graphs >> with cherry picking is because it doesn't graph the cherry picks! If >> you want to know what has been merged, you have to inspect the commit >> message in one branch and match it up with the commit message in >> another branch. How does that make it easier to figure out what has >> been done on any given branch? > > I think Eric's point is that it kind of feels (and looks) wrong to > merge maintenance into master, rather than backporting fixes from > master with cherry-picks. Maybe 'feels wrong' might be translatable > as 'harder to think about' and therefore 'more error prone'?
Maybe "feels wrong" translates to "unfamiliar", and has nothing to do with difficulty or potential for error. Git is a powerful tool. If we used a cherry-picking workflow (which I would not advocate), there would still be chances for error by inappropriately specifying hash ranges, for example. I think there is much more potential for error using cherry-picking. There are other advantages as well, see http://stackoverflow.com/questions/1241720/git-cherry-pick-vs-merge-workflow (note the warnings about rebasing, which are not relevant to this discussion) > I can > see the argument for doing it though. It is a common workflow? Yes, I believe it is a very common workflow. Before we made the git transition, I read about various workflows. What we are doing now is somewhat similar to what used to be done with svnmerge. I just googled "git workflow", and found http://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html . See the section on "Merging Upwards": --- The "downwards graduation" discussed above cannot be done by actually merging downwards, however, since that would merge all changes on the unstable branch into the stable one. Hence the following: Rule: Merge upwards Always commit your fixes to the oldest supported branch that require them. Then (periodically) merge the integration branches upwards into each other. This gives a very controlled flow of fixes. If you notice that you have applied a fix to e.g. master that is also required in maint, you will need to cherry-pick it (using git-cherry-pick(1)) downwards. This will happen a few times and is nothing to worry about unless you do it very frequently. --- With cherry picking, imagine we get ready to cut a v1.0.2 release, and we want to know if all of the bug fixes that should be applied to the maintenance branch have been applied. How do we verify? Much easier is to apply them like the docs at kernel.org suggest, to the oldest supported branch that require them and then merge upwards. Then the history graph can tell you that the bug fixes in older versions have been applied to newer branches. Merging is going to happen anyway, whenever someone files a pull request. We have a good workflow, we just had a small mistake and have now overcome it. Darren ------------------------------------------------------------------------------ Simplify data backup and recovery for your virtual environment with vRanger. Installation's a snap, and flexible recovery options mean your data is safe, secure and there when you need it. Discover what all the cheering's about. Get your free trial download today. http://p.sf.net/sfu/quest-dev2dev2 _______________________________________________ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
