Thread (1 message) 1 message, 1 author, 2016-06-15

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

From: Junio C Hamano <hidden>
Date: 2016-06-15 22:53:56

Junio C Hamano [off-list ref] writes:
"Steven E. Harris" [off-list ref] writes:
quoted
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).
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help