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

From: Steven E. Harris <seh@panix.com>
Date: May 29, 2012, 21:51 UTC
Message-ID: <m2sjei4pvq.fsf@Spindle.sehlabs.com>
In-Reply-To: <7vbol63ccs.fsf@alter.siamese.dyndns.org>

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

Show 7 quoted lines

> 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