Re: [Gnu-arch-users] graphical merges

[Aaron Bentley]

Tom Lord wrote:

>     > From: Aaron Bentley <address@hidden>
>
>     > Well, if I was trying to write my own merge, I wouldn't base it
>     > on star-merge.
>
>     > All I'd really need is a way to list candidates for ANCESTOR, so
>     > my tool can select one and the user can override.  The rest can
>     > be implemented in terms of get (--link) or library-find.
>
> Yikes.
>
> 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).

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.  What would the list contain?  I imagine it would be 
a list of the latest common revision for each version, starting with the 
ancestors of TREE and HIS.

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.

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?

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

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.

>     > It's not that I'm opposed to updating star-merge, I just think
>     > it would be easier this way.
>
> I doubt it would be easier and, more to the point, any new
> functionality you write that wouldn't simply duplicate what star-merge
> already does should _also_ be available in star-merge.

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.

Aaron