Re: Interesting behavior in git mergetool with no BASE revision

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Jan 18, 2012 at 3:05 PM, Jason Wenger <jcwenger@xxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]