Re: [Gnu-arch-users] graphical merges

[Tom Lord]

    >>> From: Aaron Bentley <address@hidden>

    >>> Well, if I was trying to write my own merge, I wouldn't base it
    >>> on star-merge. [....]

    >> Tom Lord wrote:
    >> star-merge is already "expert" at one best way to pick ANCESTOR and
    >> already expert at finding or building-in-tmpdir the ANCESTOR tree.
    >> star-merge is already expert at invoking mkpatch in such a way that,
    >> instead of the usual patching, "something else" (diff3 currently)
    >> happens (but, meanwhile, mkpatch still does all the tree-rearrangement
    >> stuff in the usual way).

    > From: Aaron Bentley <address@hidden>

    > Yes, but we're talking about replacing diff3 with something else anyway.

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

Run star-merge, let it pick ANCESTOR, let it find or build ANCESTOR,
let it compute the diffs, let do the tree-rearrangements (until such
time as you can think of how to build a tool for that), then, where it
would currently call diff3, let it instead just write a file
containing triples of MINE,YOURS,ANCESTOR paths.

In a second phase, call your graphical tool.

    > I would really like star-merge to follow ancestry; I don't think tag 
    > boundaries should actually be boundaries to Arch, just as symlinks can 
    > be treated like the actual file for most purposes.  Even going back 
    > through one continuation would reduce the need for --ref by 90%.  So I'm 
    > also not totally satisfied with how star-merge picks ANCESTOR.

That's plausible but orthogonal to how to build a GUI merger.

    > And why can't --ref select a revision instead of a version?  If the user 
    > has to use ref, they must know more than tla knows, so why not give them 
    > full control?

Yes, star-merge needs an option to say "use revision X as ancestor". 


    >> I'm just about certain that the right way to build new 3way merges is
    >> to tweak star-merge in minor ways.

    > I think star-merge is the best thing I've ever used for merging.  But I 
    > think GUI tools aren't a good fit with the way tla usually operates.

When I say "use star-merge to do graphical 3way merges" I mean that
star-merge can do the first half of the work and separate, not-in-tla
tool can do the second half.

The maximum degree of integration would be something like a
`post-star-merge-external' hook.

    > Possibly it would work if you provided a script;

    > star-merge --guiscript "foo" HIS

    > And then foo would need to handle "selectref" and "do-merge" (instead of 
    > diff3) actions, while star-merge took care of the rest of its normal 
    > duties.  It would probably need to handle the case where foo do-merge 
    > exits with an error status, too.

No --- two phases.   Invoke star-merge first which should leave behind
a set of file triples that the GUI tool uses.   _Maybe_ you want a
third phase to clean-up any temp dirs that star-merge has to create.

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.


    > This was an argument for doing it *outside of tla*, e.g. in a
    > script.  I agree that if it was done inside tla, duplicating
    > functionality doesn't make sense.

Inside of tla, star-merge can do enough that after its done (except
perhaps for tmp-dir cleanups), a GUI tool can take over and operate
absolutely trivially.   Any of the existing GUI-merge tools should be
up to the task without any modification needed (just some tiny wrapper
code).

-t