Re: Conflict editing

[Theodore Tso <tytso@mit.edu>]

On Mon, Mar 05, 2007 at 10:59:33AM +1300, Martin Langhoff wrote:
> I find xxdiff much better than meld, tkdiff and kdiff -- but maybe I
> just don't know how to use them, or they have gotten better in the
> last few months.

I wasn't familiar with xxdiff until just now, but having played with
it, kdiff3 is much easier for a beginner to use.  The toolbar makes it
a lot easier to select from one or the other, I find the keyboard
accellerators to be much more intuitive (although I suppose if you are
a vi or nethack fan the H, J, K keys will make sense to you :-).  

In addition, with xxdiff it gives the user way too many options about
whether you want to save the left, right, or center, or merged
windows.  That makes sense maybe if you are doing something completely
general, but too many options is a net negative, not a feature.  I
prefer kdiff3, where you simply hit the save icon, and it saves the
reconciled merged file to the specified output file (which the
git-mergetool specified to kdiff3 on the command-line).  So from the
workflow perspective, kdiff3 fits in much more cleanly than xxdiff.  

The one advantage xxdiff has that I can see (and maybe that's why you
like it?) is that it has the -U feature which allows it to pick apart
the merge conflict markers and so you can use it fairly easily simply
by saying "xxdiff -U hello.c".  With kdiff3 it's a lot more
complicated to invoke off the command-line, with something like:

	kdiff3 --auto hello.c.BASE hello.c.LOCAL hello.c.REMOTE -o hello.c

...but that's why you have a shell script to keep you away from such
nastyness.  All I need to do with my mergetool script is to type, "git
mergetool" to merge all unresolved merge conflicts, or "git mergetool
hello.c" if I only want to resolve conflicts in a single file.

> I had written (and posted) a git-xxdiff earlier. A (minor) concern is
> that from a packaging and dependencies perspective, the packager has
> to suggest *all* of them, and still a default install may not work at
> all -- it might be a good idea to suggest what to install in the error
> message. Or depend on all of them (yuck!).

Depending on all of them is definitely a bad idea.  Suggesting all of
them doesn't seem to be a big issue, and I don't see what's the
problem if git-mergetool can't find a graphical resolver; it can
always fall back to opening the file in an editor and asking the user
to resolve the conflict manually.

> One thing I _don't_ want as a user is to see the graphical mergers
> starting by default. Most merges are trivial, and I can just edit them
> in emacs or vi.

Well, git will handle most merges automatially for you anyway.  You
would only use git mergetool to handle the merge conflicts.

						- Ted