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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html