Keith Whitwell wrote: > 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.
Exactly. I keep two separate git trees, one for master and one for the mesa_7_5_branch branch. If I'm developing new features I work in the former tree. If I'm fixing bugs I work in the later tree. This simple system works pretty well for me. -Brian ------------------------------------------------------------------------------ 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 Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
