From: David Aguilar Date: Fri, 20 Jan 2012 06:43:24 GMT Subject: Re: Interesting behavior in git mergetool with no BASE revision Message-ID: In-Reply-To: On Wed, Jan 18, 2012 at 3:05 PM, Jason Wenger wrote: > 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: I have not seen this in practice. Maybe escape the variables? In any case, I added a test case to cover this case. I think we should at least provide an empty file in place of a missing $BASE. > 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? Not really. I'll send a patch shortly. --             David