Re: Continued work on sr/vcs-helper and sr/gfi-options

From: Sverre Rabbelier <srabbelier@gmail.com>
Date: Dec 6, 2009, 10:23 UTC
Message-ID: <fabb9a1e0912060223h148a67b0q589b8461dae6330e@mail.gmail.com>
In-Reply-To: <7vr5r8oov1.fsf@alter.siamese.dyndns.org>

Heya,

On Sun, Dec 6, 2009 at 02:47, Junio C Hamano <gitster@pobox.com> wrote:

>  - sr/vcs-helper seems to be near completion; I'd expect it to be among
>   the first batch of topics to go to 'master' after 1.6.6 final (some
>   fixes may happen between now and 1.6.6 final to make the series a bit
>   longer, though).

*nod*.

>  - sr/gfi-options started moving again and there could be a couple more
>   iterations before it would hit 'next'.

Yup, I'm hoping for a review by Shawn and the vcs list.

> Until sr/gfi-options becomes more solid, one way we can manage
> sr/remote-hg is (thinking aloud):
>
>  - Fork sr/remote-hg from today's sr/vcs-helper;

That makes sense, this way I don't have to re-resolve those merge conflicts either.

>  - Merge today's 'master' to sr/remote-hg (optional);

I'm not sure why this is though? (no objections against it, I just don't understand the motivation)

>  - Whenever any updates to vcs-helper topic appears, apply them to
>   sr/vcs-helper, and merge the result to sr/remote-hg;

*nod*

Show 6 quoted lines

>  - Create an unstable sr/pu-remote-hg branch that:
>
>   - is reset to the tip of sr/remote-hg at the beginning of the day;
>   - merges the day's sr/gfi-options on top;
>   - re-applies patches to implement Hg interoperation on top of the
>     result.

Ok, that does make sense, how would I send out patches for review from this unstable branch though? (since others would not have the required merges etc) I reckon it would be necessary to publish sr/pu-remote-hg somewhere?

Show 7 quoted lines

> When sr/gfi-options becomes solid, we can merge it to sr/remote-hg itself,
> get rid of sr/pu-remote-hg "patch queue", and move the Hg interoperation
> patches we helpd in sr/pu-remote-hg to sr/remote-hg branch.  We will merge
> early parts of sr/remote-hg (at least up to the merge with sr/gfi-options,
> and perhaps early parts of individual Hg interoperation patches as well)
> to 'next', and remaining parts on the branch to 'pu' (and they can be
> replaced).

Luckily the remote-hg patch is just that, a single patch. I've already put all the other work that's needed into sr/vcs-helper and sr/gfi-options.

Thank you for the detailed explanation :).

-- 
Cheers,

Sverre Rabbelier