vimdiff as mergetool causes E810 and E97

[JacksonBailey]

I am using version 2.6.0.windows.1, this also occurred in 2.5.3.windows.1.

Relevant snippet from .gitconfig:

[merge]
    tool = vimdiff
    conflictstyle = diff3
[mergetool]
    prompt = false

When I run git mergetool I get this error:

E810: Cannot read or write temp files
E97: Cannot create diffs
Press ENTER or type command to continue

[dscho]

No. I cannot reproduce with this description.

Here is what I tried:

me@work MINGW64 ~
$ git init issue-468
Initialized empty Git repository in C:/Users/dscho/issue-468/.git/

me@work MINGW64 ~
$ cd issue-468/

me@work MINGW64 ~/issue-468 (master)
$ git config merge.tool vimdiff

me@work MINGW64 ~/issue-468 (master)
$ git config merge.conflictstyle diff3

me@work MINGW64 ~/issue-468 (master)
$ git config mergetool.prompt false

me@work MINGW64 ~/issue-468 (master)
$ git mergetool
No files need merging

Please note: the easier you make it for me to replicate your issue, the sooner I will be able to help you (and the happier I will be to do so).

[JacksonBailey]

The problem was I added some custom MyDiff() function that was for using vimdiff through cmd, which I misinterpreted as being for vim on windows in general (not through a bash shell). The solution was to remove all that and use MSYS_NO_PATHCONV=1 in front of git mergetool.

It'd be nice to know of a way to always apply MSYS_NO_PATHCONV=1 when using mergetool, maybe the best way is through an alias. I'm not sure I want it to always be 1, seems a big commitment.

[dscho]

I'm not sure I want it to always be 1, seems a big commitment.

That would not be a big committment, it would instead be a big breakage of Git for Windows...

[JacksonBailey]

Here's a way to replicate it, my thought is maybe it didn't work because there wasn't a merge that needed to happen. I only put this because I'm not sure it's an issue or not.

mkdir zoo
cd zoo
git init

git config merge.tool vimdiff
git config merge.conflictstyle diff3
git config mergetool.prompt false

echo Animal > animal.txt
git add .
git commit -m "Add animal"

git checkout -b dog
echo Dog > animal.txt
git commit -a -m "Replace with dog"

git checkout master
echo Cat > animal.txt
git commit -a -m "Replace with cat"

git merge dog
git mergetool

Here is what shows on the screen:

"./animal_REMOTE_5880.txt" [dos] 1L, 5C
Cannot execute shell C:/Program Files/Git/usr/bin/bash

Cannot execute shell C:/Program Files/Git/usr/bin/bash
E810: Cannot read or write temp files
E97: Cannot create diffs
Cannot execute shell C:/Program Files/Git/usr/bin/bash

Cannot execute shell C:/Program Files/Git/usr/bin/bash
E810: Cannot read or write temp files
E97: Cannot create diffs
Cannot execute shell C:/Program Files/Git/usr/bin/bash

Cannot execute shell C:/Program Files/Git/usr/bin/bash
E810: Cannot read or write temp files
E97: Cannot create diffs
Press ENTER or type command to continue

But if you run MSYS_NO_PATHCONV=1 git mergetool or have set MSYS_NO_PATHCONV to 1 (export MSYS_NO_PATHCONV=1; git mergetool) it works correctly.

[JacksonBailey]

There is a question relating to this on Stack Overflow also (it's actually where I found my solution) so I know it affects others.

[dscho]

From a conversation that is well-hidden inside Gitter, it appears that the SHELL environment variable is at fault: apparently vim cannot handle the colon. So it needs to be Unix style.

[JacksonBailey]

In this file, would temporarily setting MSYS_NO_PATHCONV to 1 work maybe? I don't have gvim so I don't know if its affected.

This also happens with vimdiff as the difftool. (From the above example, do git difftool --tool=vimdiff HEAD instead of git mergetool)

[dscho]

would temporarily setting MSYS_NO_PATHCONV to 1 work maybe?

It is quite likely that this will break things. As soon as you need to mix MSys2 with MinGW programs, this will break things. Badly.

The best way forward would be to identify where the SHELL variable is mangled (I guess it is when calling git.exe, what with it being a MinGW program). And then we have to make sure that those environment variables are converted back at the correct time.

I imagine that the MSys2 runtime actually converts SHELL into a Windows path when calling any non-MSys2 program, and likewise, it should convert it back when being entered as part of git.exe calling vim (which is an MSys2 program).

[dscho]

Since my impression is firmly that #498 is discussed more actively and has a better chance to actually do anything about this issue, I close this ticket as a duplicate.