On Thu, 2009-09-03 at 15:13 -0700, Michel Dänzer wrote: > On Thu, 2009-09-03 at 14:43 -0700, Ian Romanick wrote: > > > > 2. It becomes increasing difficult to merge (as opposed to cherry-pick) > > from one branch to the other as the branches diverge. Michel has run > > into this. > > At least in the case I assume you're referring to, it would have been > more or less the same problem with cherry-picking, as the indentation of > the GLX code is different between branches. I think the lesson there is > to resist the temptation of whitespace-only changes, no matter how much > 'better' the result may appear.
There are a couple of points in favour of the periodic merge approach, firstly that if people really care about producing a high-quality, release-quality, QA'd Mesa-7.6, then you'll find yourself: - testing the 7.6 branch - spotting bugs on the 7.6 branch - developing and committing fixes on the 7.6 branch, - repeat for the entire supported life of the driver. >From that point on, it is natural to want to be 100% sure that bug-fixes have been preserved, and periodically merging the 7.6 branch to master guarantees that none of those bugfixes will be lost/forgotten. This doesn't prevent people who want to work a different way from developing bugfixes on master and cherry-picking them to stable, but it's not a natural workflow for the case where a bug is spotted on stable and needs to be fixed on stable. It seems the objections so far to this practice are that: 1) you get repeat mail-outs of merged fixes 2) it's different to some other projects workflow 3) merging becomes more difficult over time. Firstly, I'll just say that (3) hasn't been true in my experience. I'm sure branches that are allowed to grow infinitely far apart will be hard to merge, but the repeated merge from 7.5->master has had the effect of making each individual merge very easy. In fact, it seems easier than cherry-picking the same number of commits, as git is able to use more information to resolve conflicts in the merge path. I would argue that (1) could be fixed with a smarter git commit script, and that (2) will change over time as people realize how well git can manage these repeated merges between even hugely divergent branches. Keith ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Mesa3d-dev mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
