Re: Interesting behavior in git mergetool with no BASE revision

From: David Aguilar <davvid@gmail.com>
Date: Jan 20, 2012, 06:43 UTC
Message-ID: <CAJDDKr5mUiJkNk-urNn5fP5x+gkzaTfx2y=K1S0AJZCy7Muwdg@mail.gmail.com>
In-Reply-To: <CAM6z=4_+yC4EnL9SZFd6=Nxs89QeHevNCakVzVycGBe7G+nTKQ@mail.gmail.com>

On Wed, Jan 18, 2012 at 3:05 PM, Jason Wenger <jcwenger@gmail.com> wrote:

Show 9 quoted lines

> 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.

Show 18 quoted lines

> 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