Re: [Gnu-arch-users] [MERGE REQUEST: lord] documentation and help enhancements

[Robin Green]

On Wed, May 05, 2004 at 01:04:55PM -0700, Tom Lord wrote:
> Wow.   Talk about catching up.   Your new proposed merge request
> format passed completely beneath my radar during the move.
> 
> For reference, the format is currently documented at:
> 
>     http://www.greenrd.org/sw/arch/mergereq/spec.html
> 
> I can puzzle out the meaning of the enclosed request easily enough.
> 
> I think the general direction of your proposed format is right, but
> the details are an open question.

I must stress that it was a bit of a stab in the dark, since I didn't really
know what commands exactly would commonly be run by mergers. I'm pretty
confident with creating archives, branching, committing and mirrorring, but
I haven't really done much merging.

> One thing I don't see is a way to specify a merge which consists of a
> list of specific, non-contiguous changesets.

Well, my understanding from recent posts is that you'd like a one-to-one
mapping between merge requests and "coherent sets of changesets", i.e you don't
want unrelated stuff mashed up in the same merge, if possible.
So a list of changesets could be done with a list of sub-requests, but that
would be cumbersome.

So how about, RFC-style (using indentation to indicate continuation):

Merge-type: cherrypick
Baseline: ...
Pick: address@hidden/tla--devo--1.4--patch-3
               # here's a little comment explaining what patch-3 does
        tla--devo--1.4--patch-7
               # and here's another comment for patch-7
        tla--devo--1.4--patch-11

where the archive, if not specified, is taken to be the archive that was
mentioned last. You could have a similar rule for versions as well, although
I don't want to make it unnecesarily complicated.

(Oh no - now you're going to want to specify ranges inside a cherry-pick
request, aren't you?)

RangeStart should be renamed to Baseline, also, because that's what it
is. I included it because, although star-merge doesn't need to be handed
that information, Aaron indicated that people don't always use star-merge
for handling merge requests.

> I'd like to encourage further development of this standard.

Cool.

> Would you like to either propose the design of a tool which
> automatically processes these requests -or- explain why such a tool
> would be impossible?

I don't yet feel ready to do either, I'm afraid. As I say it was a bit of
a stab in the dark. I suggest we play for a time with submitting and merging
via bug-goo and see if we can see what form such a tool should take.

Actually the reason why I said it should "semi-automated" not "automated" was
that there is usually, but not always, a human merger who wants to review at
least some of the submissions before allowing them into his/her tree! :)

> Also: the documentation of the spec needs some T.L.C. to flesh it out.

Yes, again, *very* quick hack, and I'm not experienced at writing specs.

> But -- great initiative, first step, important niche, etc.  Thank you
> for making a good start on this.

Thanks. Help and suggestions from others would be appreciated.
-- 
Robin

pgpCP0_rd4a0z.pgp
Description: PGP signature