Hi, On Thu, Jun 2, 2011 at 7:06 PM, Darren Dale <dsdal...@gmail.com> wrote: > 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.
Ah no - I mean that the way I think most of think of bugfix workflow is that we fix in trunk and backport the fix to the maintenance branch. Here though you are fixing in the maintenance branch and _merging_ to trunk. The counter-argument is 'well think of it the other way round and it will be fine'. It's a little difficult to know if that's true I suppose. It's a funny kind of thing too, because it puts an extra constraint on the bugfix. For example, imagine a bugfix in maintenance, in some code that has crazy-changed in trunk. Now you have to decide if you try and merge it anyway, and basically do a rewrite as you fix the merge conflict. Or you could merge-ours on that commit and write a completely different fix on trunk. But that's getting a bit dark and magic. And so it imposes some slight what-will-happen brain overhead on the person writing the fix. > 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. Ah - OK, I guess I had not seen it before. > 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": Yes, I think I see why it would be attractive. > 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. I believe that the git log --cherry etc machinery is designed to deal with this case, but I haven't used it myself. I have to emphasize, the projects I've been involved with have fewer developers and smaller code-bases, Cheers, Matthew ------------------------------------------------------------------------------ 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
