From: Junio C Hamano <gitster@pobox.com>
Date: Mon, 13 Oct 2008 14:25:49 GMT
Subject: Re: What's cooking in git/spearce.git (Oct 2008, #02; Sun, 12)
Message-ID: <7vhc7gbmhe.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <20081013013752.8fc16695.stephen@exigencecorp.com>

Stephen Haberman <stephen@exigencecorp.com> writes:

> (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.