[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Tom Lord
Subject: Re: [Gnu-arch-users] Re: <<< conflict markers
Date: Thu, 15 Apr 2004 08:08:38 -0700 (PDT)

    > 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

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:

        [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:



        variance-adjust (hypothetical)

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

    history queries:


       latest-in-version (hypothetical)


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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]