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

[Aaron Bentley]

Tom Lord wrote:
>     > It seems sort of odd to use star-merge instead of apply-delta in this 
>     > context.  The person who submits the merge request should have enough 
>     > data to use that instead.
>
> I don't see merge packets as being end-to-end but rather as broadcast.

Oh.  I don't get it.  Do you see yourself pushing merge requests from 
tla--devo--1.3, for example?  Because really, you don't hafta.  I've 
already got auto-merging all rigged up.

> No, the sender doesn't know enough to recommend an apply-delta because
> while he can recommend a reference version he can't identify a
> specific ancestor revision unless he knows the target revision.

Oh yeah.  I was only considering the case where the merge was 
apply-delta $foo--patch-3 $foo--patch-5.  But if the submitter has 
merged something from the target version in patch-4, it could get ugly. 
    star-merge would be doing apply-delta $COMMON_ANCESTOR-REVISION 
$foo--patch-5, and.... ugh.  Too many special cases.

A while ago I wanted to be able to specify the common ancestor REVISION 
to star-merge, but then realized that apply-delta would do the same job. 
 Somehow I saw this as the same problem.

>     > I'd suggest considering the target revision advisory.  That's the 
>     > revision that the merge is guaranteed to succeed for, so if the merger 
>     > really wants the merge, they can see what it would look like.
>
> Advisory and optional, perhaps.  It would be a serious limitation if
> the merge packet had to specify a guaranteed-success target revision.

I'm not so sure it would be bad to require a guarantee that the merge 
will succeed against something.  Making sure the merge will work before 
submitting it seems like a best practice that I don't might requiring. 
And it's not like humans would have to work it.

Aaron

--
Aaron Bentley
Director of Technology
Panometrics, Inc.