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

[Junio C Hamano <gitster@pobox.com>]

"Steven E. Harris" <seh@panix.com> writes:

> What about the case where an author started his work from the "next"
> branch instead? He may have submitted an earlier batch of work that's
> still cooking in "next," and now he needs to build something else that
> can take advantage of that earlier work.

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.

Sometimes a new work depends on multiple topics that are still
cooking, and *all* of these topics that the new work depends on are
in good shape.  In such a case, I create a new branch by merging
these prerequisite topics and then queue new work there.  Obviously
the new work is taken hostage to *all* of its dependent topics, and
cannot graduate until all of the base topics graduate.

Sometimes a new work depends on one topic that is still cooking in
"next", *and* also needs updates made by other topics that are
already in "master".  You can guess what should happen---take the
tip of that topic that is still cooking in "next", merge the commit
on "master" that adds other necessary bits, and then that becomes
the base of the new topic.  The "commit that adds other necessary
bits" could be the tip of "master" (easiest for me, but it makes the
new topic unmergeable to "maint" later) or the tip of an old topic
that was merged to "master" (more work for me, but it is worth if
both the other old topic and the topic that is cooking in "next" are
meant to be merged to "maint" later, and the new work is also meant
to eventually be merged to "maint").

In a rare cases where a new work depends on millions of uncooked
topics, we simply reject the follow-on series and tell the submitter
to wait until the dust settles, but in practice it does not happen
very often.

In other words, the "policy" is not a mechanical recipe to be
followed by brainless monkeys; the integrator needs to follow the
common sense of keeping the resulting topic branch mergeable to as
many relevant contexts as necessary.

And the contributor can help in this process, as well.