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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Junio C Hamano <gitster@xxxxxxxxx> writes:

> "Steven E. Harris" <seh@xxxxxxxxx> 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).


--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]