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

[Tom Lord]

    > From: Aaron Bentley <address@hidden>

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

Nuts.  Yeah.

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

I partly want replay to work on continuation revisions just as it
currently does: for adding back patchlogs.

I also want it for what might be called "multi-patch submission
branches" in which successive revisions are each distinct patches
rather than each being rewrites of a single patch.   Such a branch is
similar to an ordinary star-merge-using commit branch but ommits the
"update" commits.  It's kind of the platonic ideal of what rbcollins
is aiming for with --skip-present.


    >>> 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?

Three-way.   You could add a --three-way option to apply delta instead
of a --ancestor option to star-merge but I like the idea of keeping
apply-delta as just, well, a delta applier.


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

I could live with that.   (Did I rule it out in the past or something
embarassing like that?)


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

    > That's not intuitive.  

I know.  It basically comes down to:

   1. using patch logs is controllable
   2. patch logs can easily be managed so that the right thing
      always happens
   3. you can do some weird "special effects" as a result of this
      rule that you couldn't with a purer semantic
   4. the alternative, using true ancestory, would be very nasty
      for many aspects of performance, no matter how you implement
      it


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

You proposed two things that I think are bogus.

  1. that `replay VERSION' should treat each indicated 
     revision differently than it would be treated by
     `replay REVISION'.

  2. that `replay REVISION', which needs only a changeset from
     that revision, should for some reason treat the two kinds of
     revisions that have changesets differently.


(2) sounds plausible until you realize that there's no unique and
obviously right rule for it.   Any rule you pick is therefore going to
be an arbitrarily inserted irregularity in the command set.


-t