Re: [Gnu-arch-users] [BUG] Fix merge commands to behave sanely for mixed versions

[Aaron Bentley]

Tom Lord wrote:
>     > From: Aaron Bentley <address@hidden>

>     > Therefore, update shall 
>     > scan the revision types before beginning, and fall back to the 
>     > apply-delta strategy if replay cannot be used safely.

> At the same time, please add to archive.c to cache revision-type
> information so that this change does not increase the number of
> roundtrips.

AFAICT, replay does not currently scan revision types, so it will slow
down the case where the replay strategy can safely be applied.  The scan
won't happen for the case where apply-delta is currently chosen.  So
caching will only help the case where replay would normally be selected,
but the scan determines this is unsafe.

I'm still in favour of it, but I don't think it'll help much.

>     > Therefore, replay VERSION shall apply only 
>     > simple revisions, and stop processing at the first non-simple revision 
>     > it encounters, unless passed the new "--frankenstein" option.  Replay 
>     > REVISION shall have no such safeguards.
>
> No.   I regard
>
>         replay VERSION
>
> as just shorthand for
>
>         replay VERSION--patch-X VERSION--patch-Y ....
>
> so I don't like adding in some arbitrary restriction.

As the name --frankenstein implies, replay across continuations will
produce a composite that contains the changes from several distinct
lines of ancestry.  It will probably result in conflicts, especially if
the continuation is produced by commit --base.

I think that behaviour will almost never be useful.

OTOH, skipping continuation revisions would interact very nicely with
commit --base.  It would be especially nice if there were no actual tree 
changes in the continuation commit (aside from the patchlog).

>     > Star-merge: Star-merge's common-ancestor selection algorithm may ignore 
>     > the fact that a version contains unrelated revisions.  If this is the 
>     > case, it should be updated to consider only related revisions.
>
> No.   It needs a "--ancestor REV" option, to be sure.

I'm not sure what you mean this option to do.  If that specifies the 
specific ancestor to use, there's no difference between

star-merge --ancestor A B

and

apply-delta A B

right?

> It _maybe_ needs some options that, like --reference, tweak the
> ancestor selection algorithm.

Well, if the only support was a --use-patchlog-ancestry option, that 
would be adequate to me.

> But picking the ancestor based on patch-log contents is pretty
> fundamental to arch.  It's predictable and fast and it does not
> require knowledge of the ancestry of the YOURS and MINE trees (hence,
> fewer roundtrips, etc.).

The patchlogs contain ancestry information as well merge information, so
there's no need for more round trips.  It should be very easy to use the 
"Continuation-of" header to exclude namespace-previous revisions that 
aren't actually ancestors.  The behavioural change is that star-merge 
would report "cannot merge unrelated trees" slightly more often, instead 
of doing ill-advised merges in those cases.

> It's pretty fundamental that ancestry is generally _not_ the basis of
> merge commands in arch.

That's not intuitive.  In fact, the star-merge documentation
consistently refers to finding an "ancestor".  It seems like a bug
to me that very occasionally it may pick an "ancestor" that is
not, in fact, an ancestor.

> Yes, that means you can do weird things
> like replay the changeset found in a continuation but (a) that's
> useful and (b) the alternative is worse, all around.

I haven't proposed preventing replay from applying continuation
changesets, just preventing it from doing so automatically.

And really, I don't care about fixing replay.  I'm happy to let people 
who use replay VERSION suffer, because I think they're doing it wrong.

If we can prevent star-merge from doing the wrong thing, then I think 
we'll have a solution.

Aaron
--
Aaron Bentley
Director of Technology
Panometrics, Inc.