Re: [Gnu-arch-users] graphical merges

[Aaron Bentley]

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.

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.

> Run star-merge, let it pick ANCESTOR, let it find or build ANCESTOR,
> let it compute the diffs,

Which diffs?

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

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

Yeah, but it's really a five-phase process by my count.
- get HIS
- pick ref
- get ANCESTOR, return paths
- invoke external merge tool
- cleanup

> The maximum degree of integration would be something like a
> `post-star-merge-external' hook.
>
>     > Possibly it would work if you provided a script;

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

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.

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

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.

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

Aaron