[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 14:16:45 -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:

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

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.


reply via email to

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