Re: [Gnu-arch-users] graphical merges

[Tom Lord]

    > From: Aaron Bentley <address@hidden>



    > Yeah, but it's really a five-phase process by my count.

Whatever.  Please forgive my imprecise language.  We're clearly
converging on agreement on the essential points which are that:

        1) star-merge does all the work except for the 3way of
           individual files

        2) interaction is not intermingled with flow of control
           in tla.


Details:


    > Tom Lord wrote:

    >>>> There might be _other_ best ways to pick ANCESTOR -- but star-merge
    >>>> should learn about any new ones we come up with.

    >>> The "Pop up a dialog box and ask the user" approach seems to violate 
    >>> most of the conventions of tla :-)  But in the GUI world, I don't think 
    >>> less is acceptable.  

    >> That has nothing to do with anything.

    > That's the main new method of picking ANCESTOR that I'm proposing.

Sorry I confused two issues in explaining why dialog boxes have
nothing to do with anything.

To try to clear up:

I'm saying: do GUI merging as a wrapper around star-merge.   Your
wrapper can prompt for an ancestor and pass that to a `--ancestor'
option if you like.

Leave it star-merge to work out where to find or build the ancestor.

Leave it to star-merge to compute the changeset between two ANCESTOR
and YOURS (perhaps not bothering to emit diffs but that's
inconsequential).

Leave it to star-merge to go ahead and apply the tree-delta part of
the changeset (renames, adds, deletes, etc.) until such time as the
relatively hard problem of making a graphical 3-way tree-delta merge
tool is available.

Leave it to star-merge to generate a file of MINE/ANCESTOR/YOURS
triples that can trivially drive an existing 3-way merge tool.

Basically exit star-merge and let the user poke around doing GUI
merges.

Clean up any temp cruft.

    > There needs to be phase zero: find or build HIS, return ANCESTOR version.

    > That way, if there is no ANCESTOR, the gui can let the user decide.

You're worried about the case where there is no obvious ancestor?
star-merge will need a tweak for all of this to leave temps around.
It may as well be willing to re-use them, too.

    >> let do the tree-rearrangements (until such
    >> time as you can think of how to build a tool for that), 

    > You mean renaming files and directories?  Possible, but not
    > strictly necessary IMHO.  The user can decide "yep, that's a
    > rename", unless there are lots of renames involved.

Arch-style 3-way merging works (in part) by computing a changeset from
ANCESTOR to YOURS and then applying the tree-delta part to MINE.

As you know, changesets represent tree-deltas with two partial
inventories, one for ORIG and one for MOD.

The problem is that the translation from ORIG/MOD inventories to
operations like "move/rename/add/delete" is non-trivial.   For
example, you can't implement a set of renames, in the general case,
without using some temporary names for things (trivially, consider
swapping the names of two files).

Conflicts can arise during application of tree-deltas.

So, ideally, there'll eventually be some kind of GUI tool that
describes the tree-delta parts that would conflict and let's the user
pick-and-choose how to resolve those --- but there's some math to do
first to figure out how to express that choice to the user in a useful
form.

Make sense?


    >> You're talking about the mistake I said to not make -- mixing up
    >> user-interaction into the flow of control in mkpatch.  That would,
    >> indeed, be a mess.

    > Unless I truly don't understand star-merge, I'm talking about mixing up 
    > user interaction into the flow control of star-merge, not mkpatch.  Not 
    > saying that I like it, though.

There should be no need.   Multiple-invocations of tla, perhaps with
some new persistent state between them.


    > The lack of support for crossing continuations, rigid approach to 
    > selecting ANCESTOR and lack of support for selecting ANCESTOR's revision 
    > lead me to conclude that the ANCESTOR-picking in star-merge isn't usable 
    > for a GUI tool.  Without that, I think star-merge has very little to 
    > offer that isn't available through other commands.


That's utterly silly.   The ancestor-choosing algorithm in star-merge
is isolated in a single function.  It's ripe for adding all kinds of
new variations.

    > So I think the solution is a thick wrapper that does the actual merges, 
    > and invokes the GUI tools as needed.

The wrapper should invoke the GUI tools.

I don't know what you mean by "thick" but it really shouldn't take
much new code.

-t