RE: The merge from hell...

From: Brown, Len <len.brown@intel.com>
Date: Feb 3, 2006, 04:20 UTC
Message-ID: <F7DC2337C7631D4386A2DF6E8FB22B3005EFE7FF@hdsmsx401.amr.corp.intel.com>

>Thank Len. He may have done it as a way to avoid having extra merges, 
>since I complained about those last time ;)

Seems I'm batting 1000 for entertainment value over my last two kernel patch pushes:-)

The previous one I took abuse for unwittingly cluttering history with "extra" merges. The thread went on and on, but buried in there were some interesting observations on work flow, and somebody asserted that the "cleanest" way to cherry pick the topic branches onto the release branch was with a multi-branch merge.

As git merge seemed to advertise support for it w/o me needing to learn a new command, I tried it out and it seemed to work fine -- including a nice colorful diagram in gitk:-)

I can do 16 next time, or 22, or none -- or you can have git merge under the covers do this via iteration instead of all at once -- that's up to you guys. My topic branches tend to be disjoint topics with little expected overlap; so grabbing a bunch of them when they're fully "cooked" in -mm and plunking them down in one merge is actually an example of history matching reality.

cheers, -Len