vimdiff as mergetool causes E810 and E97 #468

JacksonBailey · 2015-10-05T14:54:36Z

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

The text was updated successfully, but these errors were encountered:

dscho · 2015-10-05T18:15:53Z

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 · 2015-10-05T18:47:30Z

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 · 2015-10-05T18:50:26Z

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 · 2015-10-06T14:03:50Z

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 · 2015-10-06T17:06:50Z

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 · 2015-10-07T13:39:08Z

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 · 2015-10-07T15:02:27Z

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 · 2015-10-07T17:14:45Z

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 · 2015-11-09T19:24:10Z

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.

When calling a non-MSys2 binary, all of the environment is converted from POSIX to Win32, including the SHELL environment variable. In Git for Windows, for example, `SHELL=/usr/bin/bash` is converted to `SHELL=C:\Program Files\Git\usr\bin\bash.exe` when calling the `git.exe` binary. This is appropriate because non-MSys2 binaries would not handle POSIX paths correctly. Under certain circumstances, however, `git.exe` calls an *MSys2* binary in turn, such as `git config --edit` calling `vim.exe` unless Git is configured to use another editor specifically. Now, when this "improved vi" calls shell commands, it uses that $SHELL variable *without quoting*, resulting in a nasty error: C:\Program: No such file or directory Many other programs behave in the same manner, assuming that $SHELL does not contain spaces and hence needs no quoting, unfortunately including some of Git's own scripts. Therefore let's make sure that $SHELL gets "posified" again when entering MSys2 programs. This fixes git-for-windows/git#542, git-for-windows/git#498, and git-for-windows/git#468. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

When calling a non-MSys2 binary, all of the environment is converted from POSIX to Win32, including the SHELL environment variable. In Git for Windows, for example, `SHELL=/usr/bin/bash` is converted to `SHELL=C:\Program Files\Git\usr\bin\bash.exe` when calling the `git.exe` binary. This is appropriate because non-MSys2 binaries would not handle POSIX paths correctly. Under certain circumstances, however, `git.exe` calls an *MSys2* binary in turn, such as `git config --edit` calling `vim.exe` unless Git is configured to use another editor specifically. Now, when this "improved vi" calls shell commands, it uses that $SHELL variable *without quoting*, resulting in a nasty error: C:\Program: No such file or directory Many other programs behave in the same manner, assuming that $SHELL does not contain spaces and hence needs no quoting, unfortunately including some of Git's own scripts. Therefore let's make sure that $SHELL gets "posified" again when entering MSys2 programs. Earlier attempts by Git for Windows contributors claimed that adding `SHELL` to the `conv_envvars` array does not have the intended effect. These reports just missed that the `conv_start_chars` array (which makes the code more performant) needs to be adjusted, too. Note that we set the `immediate` flag to `true` so that the environment variable is set immediately by the MSys2 runtime, i.e. not only spawned processes will see the POSIX-ified `SHELL` variable, but the MSys2 runtime *itself*, too. This fixes git-for-windows/git#542, git-for-windows/git#498, and git-for-windows/git#468. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

…k files, fix loose-objects task The maintenance.lock file exists to prevent concurrent maintenance processes from writing to a repository at the same time. However, it has the downside of causing maintenance to start failing without recovery if there is any reason why the maintenance command failed without cleaning up the lock-file. This change makes it such that maintenance will delete a lock file that was modified over 6 hours ago. This will auto-heal repositories that are stuck with failed maintenance (and maybe it will fail again, but we will get a message other than the lock file exists). The intention here is to get users out of a bad state without weakening the maintenance lock _too_ much. I'm open to other thoughts, including expanding the timeframe from 6 to 24 hours. --- The `fixup!` commit fixes the use of the `gvfs.sharedcache` config value around the loose-objects task. Specifically, the loose-objects step might fail because it is calling `git pack-objects {garbage}/pack/loose` which fails.