[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnu-arch-users] graphical merges
From: |
Tom Lord |
Subject: |
Re: [Gnu-arch-users] graphical merges |
Date: |
Sun, 4 Apr 2004 10:41:02 -0700 (PDT) |
>>> 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
- Re: [Gnu-arch-users] Fast commits, (continued)
- Re: [Gnu-arch-users] Fast commits, Tom Lord, 2004/04/03
- Re: [Gnu-arch-users] graphical merges, Aaron Bentley, 2004/04/03
- Re: [Gnu-arch-users] graphical merges, Matthieu Moy, 2004/04/03
- Re: [Gnu-arch-users] graphical merges, Aaron Bentley, 2004/04/03
- [Gnu-arch-users] A general way to get a specific revision, Stefan Monnier, 2004/04/03
- Re: [Gnu-arch-users] A general way to get a specific revision, Aaron Bentley, 2004/04/03
- Re: [Gnu-arch-users] graphical merges, Tom Lord, 2004/04/04
- Re: [Gnu-arch-users] graphical merges, Aaron Bentley, 2004/04/04
- Re: [Gnu-arch-users] graphical merges,
Tom Lord <=
- Re: [Gnu-arch-users] graphical merges, Aaron Bentley, 2004/04/04
- Re: [Gnu-arch-users] graphical merges, Tom Lord, 2004/04/04
- Re: [Gnu-arch-users] graphical merges, Juliusz Chroboczek, 2004/04/04
- Re: [Gnu-arch-users] graphical merges, Matthew Dempsky, 2004/04/05
- [Gnu-arch-users] Smart merging [was: graphical merges], Juliusz Chroboczek, 2004/04/05
- Re: [Gnu-arch-users] Fast commits, Robin Farine, 2004/04/03
- [Gnu-arch-users] Re: Fast commits, Stefan Monnier, 2004/04/03
- Re: [Gnu-arch-users] Re: Fast commits, Miles Bader, 2004/04/03
- Re: [Gnu-arch-users] Re: Fast commits, Tom Lord, 2004/04/04
- [Gnu-arch-users] Re: Fast commits, Stefan Monnier, 2004/04/04