From: Jason Wenger <jcwenger@gmail.com>
Date: Wed, 18 Jan 2012 23:05:56 GMT
Subject: Interesting behavior in git mergetool with no BASE revision
Message-ID: <CAM6z=4_+yC4EnL9SZFd6=Nxs89QeHevNCakVzVycGBe7G+nTKQ@mail.gmail.com>

Doing a git merge on 1.7.4.3, on a case where both branches have a
file created, and the base does not.  Per git-mergetool:

"the configured command line will be invoked with $BASE set to the
name of a temporary file containing the common base for the merge, if
available;"

So testing in this case, I set my mergetool cmd as "echo $MERGED
$LOCAL $REMOTE $BASE", and I get the following:

cio/.cproject ./cio/.cproject.LOCAL.9029.cproject
./cio/.cproject.REMOTE.9029.cproject
./cio/.cproject.BASE.9029.cproject

ls -a cio shows the following files:

.cproject
.cproject.LOCAL.9325.cproject
.cproject.BACKUP.9325.cproject
.cproject.REMOTE.9325.cproject

So the lack of base file makes sense -- There is no base to start
from.  However, $BASE evaluates to ./cio/.cproject.BASE.9029.cproject,
which is a nonexistent file.  This makes my actual mergetool upset to
no end.  Intuitively from documents, I would expect $BASE to evaluate
to an empty string in this case.

Is this intended behavior?

--Jason C. Wenger