Re: [Gnu-arch-users] Re: <<< conflict markers

[Tom Lord]

    > From: Aaron Bentley <address@hidden>

    > > E.g., it doesn't, strictly speaking, need to build the common ancestor
    > > to achieve it's effect.   

    > > It's basically just "redo my tree-local changes against a revision
    > > that happens to have a common ancestor with my tree".

    > But you need to build the common ancestor to determine what "my 
    > tree-local changes" are.  
    [....]
    > are you drawing a distinction that the three trees don't all exist at 
    > the same time with update?

Yes, exactly.  (I misspoke.)


    > > (But, again, an update-like (i.e., using those same 3 trees) 3-way
    > > merge could be handy.)

    > Personally, I find star-merge makes a fine update, so I'm not sure what 
    > it'd be handy for.

I'm not certain it would be.   This is part of the reason it might be
nice to design a parameterized "super-merge" command whose space of 
parameters give us all the existing merge commands as particular
settings and, beyond that, give us a taxonomy of possible merge
commands.

One could understand `update' as:

    TMP = get YOURS
    delta-patch --dir TMP ANCESTOR
    . := TMP

but with an implementation that optimizes it, often to:

        [1] undo ANCESTOR
        [2] replay ANCESTOR ... YOURS
        [3] redo

That shares a property with `star-merge' and `delta-patch' (but not
`replay --list') that it can only generate conflicts during the final
changeset application.


Variations might include changing the choice of ANCESTOR in steps [1]
or [2] (together or independently) or replacing the `replay' in step
[2] with just about anything else.

Some of those variations might (like ordinary replay) generate
conflicts at more than one changeset application (during step [2])
but, the undo/redo steps ([1],[3]) might nevertheless give much 
reduced or otherwise more favorable conflicts.

As an example, how about:

        [1] undo MY-IMMEDIATE-TREE-VERSION-ANCESTOR
        [2] replay --skip-present YOuRS
        [3] redo

I have a hunch there my be interesting cases where [2] is a star-merge
--reference, too.

We've underexplored the space of merge commands a bit and I wonder if
we've (a) missed any good simple ones;  and (b) whether "multi-phase"
(possible conflicts at intermediate steps) merges might be more useful 
if (i) conflict recording and composition in trees is improved;  (ii)
partially complete (resumable) merge state in trees is improved;
(iii) gui tools are around.

It seems to me that the set of merge operations is the same as the
space of compositions of:

    merge operations:

        delta

        dopatch

        variance-adjust (hypothetical)

        3-way-patch (hypothetical;  star-merge where ancestor is named
                     explicitly) 

    history queries:

       tree-version

       latest-in-version (hypothetical)

        etc.


Also: similarly (dually, in fact) to the way "backbuilding" points out
that `get' can be optimized using search, the merge operations can be
optimized using search, too.

For example, `undo' often comes out as:


        [1] undo ANCESTOR
        [2] replay ANCESTOR ... YOURS
        [3] redo

but, why not:

        [1] what-changed --output ,tmp ANCESTOR
        [2] delta-patch MINE YOURS
        [3] dopatch ,tmp



Having lived for a long time now with just our current collection of
special-case, hand-optimized merge operators (and I'm reasonably happy
with them) --- I'm starting towonder about the general space.

-t