On Friday 04 September 2009 05:08:48 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.
>
> 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
Our git commit script already makes the thingy from the terminator movies look
like a drunk goat, making it any smarter runs a serious risk of having it
start checking out porn. Having said that the logic in there is as follows:
if (a push has more than 100 commits)
send one email for all
else
send individual emails for all
i could try to add special paths for merge if that's desired or lower the
number of commits.
------------------------------------------------------------------------------
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
