Re: How does Git's maintenance policy handle topics that don't start from "master?"

From: Junio C Hamano <gitster@pobox.com>
Date: May 29, 2012, 23:16 UTC
Message-ID: <7vsjei1stj.fsf@alter.siamese.dyndns.org>
In-Reply-To: <7vzk8q1t9r.fsf@alter.siamese.dyndns.org>

Junio C Hamano <gitster@pobox.com> writes:

Show 17 quoted lines

> "Steven E. Harris" <seh@panix.com> writes:
>
>> What about this case, where topics "t1" and "t2" did depart from
>> "master," and are doing well along "next" together as of commit M.
>>
>>   ---o---o---o---o  master
>>       \   \       \
>>        \   o---o---o---M---o---o next
>>         \     /       /
>>          o---o t1    /
>>           \         /
>>            o---o---o t2
>>
>> The Git policy as I understand it prescribes that we merge from the tips
>> of "t1" and "t2" back to master, not from a commit like M. What harm
>> would come from merging from M in this case? Future archaeology of topic
>> provenance?

You would also have to think about what you write to explain that merge of M into 'master' in the commit log message. In the above special case where 'next' happened to have had only t1 and t2 when you decided to merge to 'master', you could say "Merge t1 and t2 to achieve X", but in the earlier example (elided), it is not clear what random bits you are merging with it.

Compared to that, if you merge t1 and t2 separately, you can say "I am merging t1 topic that does X", and readers of "git log master" (better yet "git log --first-parent master") would understand that the master branch after that commit can do X (and everything before that commit does not).