Re: What's cooking in git/spearce.git (Oct 2008, #02; Sun, 12)

From: Junio C Hamano <gitster@pobox.com>
Date: Oct 13, 2008, 14:25 UTC
Message-ID: <7vhc7gbmhe.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <20081013013752.8fc16695.stephen@exigencecorp.com>

Stephen Haberman <stephen@exigencecorp.com> writes:

Show 5 quoted lines

> (I also have a test comment typo and test_expect_failure change to make
> to rebase-i-p from Junio's feedback and would like to know the
> preferred way to submit those--e.g. a patch on top of your pu, a patch
> on top of the existing series, or a new series all together. Given it
> is not next, I'm guessing a new series all together.)

You guessed it right.

As sh/maint-rebase3 is about a pure fix, while the other -i-p is a more involved enhancement, I am guessing Shawn decided not to queue the latter for 1.6.0.X, and I agree with that. The final shape of the history should look like:

 * maint will eventually get sh/maint-rebase3 to be in 1.6.0.X, which in
   turn will eventually be merged to master;

 * master will eventually get sh/rebase-i-p.

When two series have dependencies like this, it is generally the easiest and cleanest to prepare them to match such a final shape of the history. Hence, we would want two series built like this:

 * sh/maint-rebase3 applicable to the tip of 'maint' (this is already done;
   what is in sh/maint-rebase3 is exactly that);

 * apply the above locally to 'maint', merge the result locally to
   'master', and prepare sh/rebase-i-p series applicable on top of that
   merge.

Thanks.