The git-mergetool program can be used to automatically run an appropriate
merge resolution program to resolve merge conflicts.  It will automatically
run one of kdiff3, tkdiff, meld, xxdiff, or emacs emerge programs.

Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
---
 .gitignore                      |    1 +
 Documentation/config.txt        |    5 +
 Documentation/git-mergetool.txt |   46 +++++++++
 Makefile                        |    2 +-
 git-mergetool.sh                |  208 +++++++++++++++++++++++++++++++++++++++
 5 files changed, 261 insertions(+), 1 deletions(-)
 create mode 100644 Documentation/git-mergetool.txt
 create mode 100755 git-mergetool.sh

diff --git a/.gitignore b/.gitignore
index 0eaba0a..27797d1 100644
--- a/.gitignore
+++ b/.gitignore
@@ -75,6 +75,7 @@ git-merge-ours
 git-merge-recursive
 git-merge-resolve
 git-merge-stupid
+git-mergetool
 git-mktag
 git-mktree
 git-name-rev
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 5408dd6..0a72e41 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -453,6 +453,11 @@ merge.summary::
 	Whether to include summaries of merged commits in newly created
 	merge commit messages. False by default.
 
+merge.tool::
+	Controls which merge resolution program is used by 
+	gitlink:git-mergetool[l].  Valid values are: "kdiff3", "tkdiff", 
+	"meld", "xxdiff", "emerge"
+
 merge.verbosity::
 	Controls the amount of output shown by the recursive merge
 	strategy.  Level 0 outputs nothing except a final error
diff --git a/Documentation/git-mergetool.txt b/Documentation/git-mergetool.txt
new file mode 100644
index 0000000..8cc00fb
--- /dev/null
+++ b/Documentation/git-mergetool.txt
@@ -0,0 +1,46 @@
+git-mergetool(1)
+================
+
+NAME
+----
+git-mergetool - Forward-port local commits to the updated upstream head
+
+SYNOPSIS
+--------
+'git-mergetool' [--tool=<tool>] [<file>]...
+
+DESCRIPTION
+-----------
+
+Use 'git mergetool' to run one of several ...
[ message continues ]

Hmph.  We already have a tool to achieve such a goal, and that


Do we want to do this by hand ourselves, or dot-source sh-setup

You should be able to set IFS to exclude SP and then you only
have to say you do not support LF and HT, both of which are much


It is depressing to see that the differences between the command
lines of these have to be much larger than just the command name
and order of three (or four if we count the result) paths
parameters.  I was hoping that we could do something like:




Careful.  I think --abbrev=8 just means use at least 8 but more
as needed to make them unique.  sed -e 's/^[^	]*	//'
(whitespace are HTs) would be safer and simpler, as you are not
dealing with a pathname that has LF in it anyway.

-

[ message continues ]

Oops, sorry, I thought I had fixed that.  Guess you figured out which

Hey, that's what the COPYING file requested, and it was late when I
started doing the git package integration, hence the stupid think-o
with the man page.  :-)

I assume you would prefer that it read Junio instead?  Should we
change the COPYING while we're at it, perhaps after consulting with
Linus since he still owns so a fair amount of the copyright on git?
It seems that if we're going to pre-collect permissions to move to


Do we have any coding guidelines about what characters we have to
support in filenames?  I had assumed that we should support at least



Yep, it is depressing.  There is no standard calling convention, and
there is no standard exit status convention, either.  Hence the
requirement for meld and xxdiff to check to see if the file has

The problem is that if you don't do this, using xxdiff is user-hostile
in the extreme.  The problem isn't so much that the save command has
no accelerators, but the Save menu gives you five (5!) save options.
You can save the merged file as:

	* The right file
	* The middle file
	* The left file
	* The file that was specified as the output on the command-line
	* Some user-specified file (save-as)

So without those resource changes, the user would have to click on the
File menu, and drag down to the "correct" save option or the file with
the resolved merge conflicts would get saved to some random place.

Gaaah.  I thought xxdiff was user hostile in the extreme, but Martin
Langhoff really wanted it, and he was right that xxdiff will give you
a built-in character-diff so you can see what changed on the
individual line.  So the resource changes were in my opinion the
minimum necessary so that the user would have some chance of seeing
which one of the five save options would actually do the right thing

Yeah, that should probably read "merge conflict resolution programs",

OK, I can do that.  Alternatively I guess I could submit a patch ...
[ message continues ]

I'm ok with Junio controlling it as far as I'm concerned. After all, he's 
been the maintainer for the last two years, so he gets the blame, and he'd 
better get the credit too.

			Linus
-

[ message continues ]

I had a chance to use git-mergetool in real life for the first
time today, when I merged 'maint' into 'master'.  It has a
symlink vs symlink conflict, so I got something like this:

================================================================
Merging the files: RelNotes

Symlink merge conflict for RelNotes:
    'RelNotes' is a symlink containing 'Documentation/RelNotes-1.5.1.txt' in the local branch
    'RelNotes' is a symlink containing 'Documentation/RelNotes-1.5.0.6.txt' in the remote branch
Use (r)emote or (l)ocal, or (a)bort?
================================================================

A few observations.

(1) Saying "a" <Return> does not let me exit.  It keeps asking
    the same question.

(2) The word "symlink" might be less geekish if worded "symbolic
    link".

(3) The message look very long, and repeats the same information.

(4) The status info gives local and then remote, but the choice
    is between remote and local.

The attached is a minimum fix for the above issues, but not for
immediate application, as I am sure the rewording would make
messages inconsistent with other cases.  The updated output
would look like this:

================================================================
Merging the files: RelNotes

Symbolic link merge conflict for 'RelNotes':
  local: a symbolic link -> 'Documentation/RelNotes-1.5.1.txt'
  remote: a symbolic link -> 'Documentation/RelNotes-1.5.0.6.txt'
Use (l)ocal or (r)emote, or (a)bort? l
================================================================

---
 git-mergetool.sh |   19 ++++++++-----------
 1 files changed, 8 insertions(+), 11 deletions(-)

diff --git a/git-mergetool.sh b/git-mergetool.sh
index 7942fd0..0b30133 100755
--- a/git-mergetool.sh
+++ b/git-mergetool.sh
@@ -44,27 +44,24 @@ function describe_file () {
     branch="$2"
     file="$3"
 
-    echo -n "    "
+    echo -n "  ${branch}: "
     if test -z "$mode"; then
-	echo -n "'$path' was deleted"
+	echo "deleted"
     elif ...
[ message continues ]

Yeah, I fixed that last night, along with a bunch of other git
mergetool cleanups.  I was about to request you to do a pull when I

OK, let me fix up the display and try to clean up the other messages.
I agree that your output looks much nicer.

						- Ted
-

[ message continues ]