How to handle multiple long-term branches (was Re: Notification mails for git repos)

[Derek Atkins]

Geert Janssens <janssens-geert at telenet.be> writes:

>> One more note on that: E may very well end up looking nothing like D
>> because B-C may have been enough of a change that a different
>> approach is required, but it's still necessary for it to be a
>> multi-parent commit.
>>
> Absolutely. The extreme case being if commit D is not even wanted on
> the trunk branch (like a product version number increase for
> example). It would still have to be merged. You could choose to do it
> on commit D, resulting in an empty commit with two parents, or you can
> wait for commit H, and make sure the changes from commit D are
> reverted during the later merge.

This is going to be important as we make new stable releases.  We're not
going to want the e.g. 2.6.0 -> 2.6.1 -> 2.6.2 commits to merge back
into trunk.  So when the branches are merged after stable releases these
commits will need to be omitted (or reverted) during the merge.

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord at MIT.EDU                        PGP key available