[Top][All Lists]

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

Re: [Gnu-arch-users] graphical merges

From: Aaron Bentley
Subject: Re: [Gnu-arch-users] graphical merges
Date: Sun, 04 Apr 2004 12:57:46 -0400
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4

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.


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.


reply via email to

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