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

["Steven E. Harris" <seh@panix.com>]

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

> It often is clear that the follow-on topic depends on an earlier topic
> branch (mostly because the contributor is aware of it and state it in
> the message).  An obvious thing to do in such a case is to create a
> new branch to queue that topic starting at the tip of the earlier
> topic.  Note that this is never from the tip of "next", as it is very
> unlikely that such a follow-on topic depends on everything that is not
> in "master" yet.

Thank you for the thorough reply.

I want to make sure that I understand the main hazard that the policy
aims to avoid. If an author bases a topic branch on the tip of "next,"
then, later, it will not be possible to merge his work to "master"
without implicitly accepting all of "next" (or, at least the part of
"next" the precedes this topic branch) into "master." We are trying to
avoid merging "upward" from "next" to "master" like that, and prefer to
take the topics to "master" directly rather than implicitly by way of
their inclusion in "next."

What isn't so clear to me, though, is /why/ this don't-merge-from-"next"
rule is so important. Say that we had one topic "t1" depart from "next,"
and then another topic "t2" depart from "t1," and both have been cooking
in "next," with good results.

  ---o---o---o---o  master
                  \
                   o---o---o---o---o---M---o---o next
                        \     /       /
                         o---o t1    /
                              \     /
                               o---o t2

If we wanted to graduate these two topics to "master," we /could/ merge
from commit M back to "master," though here I deliberately included the
nefarious commit X, which shows other interleaved contributions along
"next" that are also part of the M commit.

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?

-- 
Steven E. Harris