Interesting behavior in git mergetool with no BASE revision
- From
- Jason Wenger <jcwenger@gmail.com>
- Date
- Jan 18, 2012, 23:05 UTC
- 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