Native paths with backslashes do not work in $env:EDITOR

[rkitover]

Setup

• Which version of Git for Windows are you using? Is it 32-bit or 64-bit?

$ git --version --build-options
git version 2.36.0.windows.1.6.ga8150f0d2f.20220422215518
cpu: x86_64
built from commit: a8150f0d2fd0a2229b25dac6b0285215d5aa0801
sizeof-long: 4
sizeof-size_t: 8
shell-path: /bin/sh
feature: fsmonitor--daemon

• Which version of Windows are you running? Vista, 7, 8, 10? Is it 32-bit or 64-bit?

$ cmd.exe /c ver
Microsoft Windows [Version 10.0.22598.200]

• What options did you set as part of the installation? Or did you choose the
  defaults?

Editor Option: VIM
Custom Editor Path:
Default Branch Option: master
Path Option: Cmd
SSH Option: ExternalOpenSSH
Tortoise Option: false
CURL Option: WinSSL
CRLF Option: CRLFCommitAsIs
Bash Terminal Option: ConHost
Git Pull Behavior Option: Rebase
Use Credential Manager: Disabled
Performance Tweaks FSCache: Enabled
Enable Symlinks: Enabled
Enable Pseudo Console Support: Enabled
Enable FSMonitor: Enabled

• Any other interesting things about your environment that might be related
  to the issue you're seeing?

Using PowerShell core and Windows Terminal as environment.

Details

• Which terminal/shell are you running Git from? e.g Bash/CMD/PowerShell/other

Using Windows Terminal with PowerShell core 7.2.2.

> $PSVersionTable

Name                           Value
----                           -----
PSVersion                      7.2.2
PSEdition                      Core
GitCommitId                    7.2.2
OS                             Microsoft Windows 10.0.22598
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

• What commands did you run to trigger this issue? If you can provide a
  Minimal, Complete, and Verifiable example
  this will help us understand the issue.

As discussed in #3629, for which this is a followup:

$env:EDITOR = 'C:\tools\neovim\Neovim\bin\nvim.exe'
git commit -a --verbose --signoff -S

• What did you expect to occur after running these commands?

Git to start editor for editing commit message.

• What actually happened instead?

hint: Waiting for your editor to close the file... C:\tools\neovim\Neovim\bin\nvim.exe: C:toolsneovimNeovimbinnvim.exe: command not found
error: There was a problem with the editor 'C:\tools\neovim\Neovim\bin\nvim.exe'.
Please supply the message using either -m or -F option.

Workaround for now:

$env:EDITOR = '''C:\tools\neovim\Neovim\bin\nvim.exe'''

this encloses the path in single quotes, which works fine in Git bash.

[dscho]

$env:EDITOR = 'C:\tools\neovim\Neovim\bin\nvim.exe'

I am afraid that this is incorrect. The backslash character is used as escape character in shell invocations, and like so many other programs, git executes $EDITOR as a shell snippet.

Workaround for now:

$env:EDITOR = '''C:\tools\neovim\Neovim\bin\nvim.exe'''

I can think of two better workarounds:

1. Add C:\tools\neovim\Neovim\bin to your PATH and use EDITOR=nvim.
2. Use forward slashes instead of backslashes.

I strongly prefer the first of these two. If you want a third workaround: Create the file $HOME/bin/nvim with the following contents:

#!/bin/sh

exec /c/tools/neovim/Neovim/bin/nvim.exe "$@"

and use EDITOR=nvim. This works because Git will add ~/bin to your PATH, and this strategy can be used if you really do not want to modify your PATH as suggested above.

But as I said, EDITOR is commonly assumed to be a shell script snippet (you can even set it to code -w to call Visual Studio Code with the -w option that ensures that the command only returns once the file has been closed), and therefore what you reported is Git behaving as designed. Therefore I will close this ticket.

[rkitover]

It's assumed to be a shell command on unix, why would there be an assumption about a unix shell on Windows, that makes no sense.

[dscho]

@rkitover many parts of Git assume that a Unix shell is present. It's just the reality I live in, I do not claim that it makes things easy.

[rkitover]

There is no standard as of yet for $env:EDITOR in the Windows ecosystem, but this situation seems far from ideal. I would propose something like checking if the initial token is a valid Windows path, or perhaps a global setting for which shell should interpret env vars and such.

[dscho]

There is no standard as of yet for $env:EDITOR in the Windows ecosystem

There is a standard, however, in the Unix ecosystem, from where Git hails. And if you want to introduce anything in the Windows world that is incompatible with the Unix version thereof, I am not interested 😁.

[rkitover]

I think I'd be able to come up with a fix for this that wouldn't introduce much incompatibility, it just needs to check if the first part is a path to a windows executable.

[dscho]

No, that would introduce an inconsistency. Please do keep in mind that EDITOR has well-known semantics, many users, and many projects operating using said semantics.

What you're arguing for is to introduce an incompatibility.

[rkitover]

@rimrul @phil-blain @PhilipOakley Any thoughts on this?

[phil-blain]

I don't have a strong opinion as I'm not really using Git on Windows and I'm really new to Windows.

What I do think is that in general there could be more documentation around how Git treats paths to programs on Windows. This here issue is about EDITOR but there are a lot of executables that can be used by Git: fs-monitor, external diff drivers, SSH, etc. Some of them have corresponding environment variables, some just have settings in the Git config. I'm not sure if they are all treated the same....

A note somewhere in the documentation (in git(1) or git-config(1)) about what kind of paths to use under different shells would be a nice addition, I would think. I found https://github.com/git-for-windows/git/wiki/File-names,-Branch-names,-Path-quotation,-Executable-bit-and-file-modes,-core.FileMode#path-quotation but there's not a lot there, plus it seems to relate to paths of tracked files...

[PhilipOakley]

It's assumed to be a shell command on unix, why would there be an assumption about a unix shell on Windows, that makes no sense.

Ultimately, this 'problem' (as I see it), is that Git (project) doesn't declare that it's raison d'etre is to be the SCM for Linux, which is what makes the assumption about using the unix shell syntax, and dir/path style, the 'sensible' option.

The success of Git in eating the world does mean that Windows compatibility can be awkward at times, but unfortunately Git isn't going to stop being Linux (unix) focussed any time soon.

I don't think we have a good plan/approach to documenting compatibility solutions so that all the good advice above can/could be collated into the [Git-for-Windows] version of the documentation.

It would be nice if there was a way of shimming in a e.g. 'Compatibility' section in various man pages that would allow different OS's (Mac, Windows, Non-Stop) to provide guidance (such as above) so it become integrated into the project slightly more than the current wiki and other notes.

[Aside: In a similar vein I'd also like the option of adding 'tutorial examples' to man pages to give newer users a help up, given that the man pages are in 'reference' style that presumes existing understanding of significant concepts]

[rkitover]

Is Git for Windows officially a project affiliated with Git itself?

The focus here seems to be on your MSYS2 "git bash" stuff, which a lot of people for some reason like better than regular MSYS2 (for one thing the MSYS2 git port is not great.)

But all of that stuff is horrible and a dead end.

You said you don't want to maintain too much code for VS support, so you are admitting that this is a low priority for you.

As we discussed in the other PR, the VS port currently does not even use the manifest, so VS binaries will be subtly wrong in their behavior whenever they do an OS build number check. I'll try to send a PR for that later.

I'd like to see a more native focused fork, built with MSVC of course, and using native tools and shell etc. most of which are already available in choco. Rather than bringing along a very crappy port of unix. A good native port doesn't port the whole os along with the program, but aims to target native idioms and users.

I probably don't have time to do something like that myself, but if some people are interested.

It doesn't look like you're interested in this being a separate track for this project anyway.

Ultimately, this 'problem' (as I see it), is that Git (project) doesn't declare that it's raison d'etre is to be the SCM for Linux, which is what makes the assumption about using the unix shell syntax, and dir/path style, the 'sensible' option.

I don't see how that makes things like this sensible, sorry.

[PhilipOakley]

Is Git for Windows officially a project affiliated with Git itself?

It's probably better to say that Git for Windows is closely affiliated with Git. Being 'Open Source' means there is more latitude in the arrangements.

The Git for Windows project seeks to provide the Git capabilities, on Windows, which does put it in a leader-follower position. The Git for Windows compatibility shims and patches are continually rebased on top of the latest Git release, rather than GfW choosing which parts of the Git release to pull in.

The focus here seems to be on your MSYS2 "git bash" stuff, which a lot of people for some reason like better than regular MSYS2

MSYS2 is the basic shim to fit Git onto Windows. Some may have chosen CYGWIN in the past, but from one perspective that's just abdicating from the underlying platform. The MSYS2 (+ MinGW) is the half way house (worst of both world from some perspectives ;-). If folk want to start with MSYS2, and then add apps, such as Git, then it's their choice. But it doesn't put Git (i.e. distributing source code storage and versioning to users) first.

Aside: I came to Git because I recognised it would solve my problem of personal source code versioning when writing exploratory Matlab code. The corporate offerings were too locked down.

One feature of the Git setup is its expectation of posix shell scripting (aka Torvalds), as that is still used in some of the Git commands and in the test suite. So that's needed somehow, which results in using/choosing bash (other shells possible).

A good native port doesn't port the whole os along with the program ...
I probably don't have time to do something like that myself, but if some people ...

The problem is a) Fast Moving Target b) lack of resources (devs) c) false focus.
There is a lot of progress and churn in Git driven by individual (usually Linux) contributors - keeping up is hard.
The Git core 'team' is actually quite small and looking for more contributors, so forks are unlikely to do better (unless they are Microsoft, but they have bought into the value of Git. "Insert MSFT concerns here").
Revision management is about ensuring security of the code, which is all about having a single core standard.

There is only so much that can be done within Git for Windows without active support, and an appreciation of the long term maintenance load. Steering that course isn't easy. I'm grateful for what @dscho has done, often stuck between a rock and a hard place.

[dscho]

the MSYS2 git port is not great

Every time you judge someone, you reveal a part of yourself that needs healing.

You said you don't want to maintain too much code for VS support, so you are admitting that this is a low priority for you.

It's not that it is a low priority. It's more that I do not want to maintain two essentially distinct products that do not need to be distinct in the first place.

I'd like to see a more native focused fork, built with MSVC

There are performance issues with MSVC's malloc() implementation. See #3427 (comment) for more details. Those issues would have to be addressed first.

In general, replacing a known component or toolchain with another one should be not only assessed looking for benefits, but also for risks. Ripping out the GCC toolchain and replacing it with an MSVC one bears a rather huge risk of introducing unwanted and unexpected problems. And I am not only talking about malloc() being slow, I also talk about problems like dependency hell, where we would have to rebuild all of the 164 distinct packages that are used to build Git for Windows ourselves, using the new toolchain, and then maintaining that ourselves, too, rather than tapping into the MSYS2 project for mutually-beneficial collaboration.

Rather than bringing along a very crappy port of unix.

See the comment above regarding judging someone.

One feature of the Git setup is its expectation of posix shell scripting

Indeed. One promise of Git (and hence, of Git for Windows) is that hooks and aliases are executed via a POSIX shell.

You can, of course, try to break that promise. It's up to the Git for Windows maintainer, however, to pay the price for that. And since I am the Git for Windows maintainer, that means I would have to pay the price for a goal that I do not even find particularly convincing ("avoid porting unix"; We are not actually porting Unix at all).

As a consequence, out of sheer self-preservation I will dismiss every attempt to remove the requirement to run hooks and aliases (and commands like git mergetool and git bisect) via a POSIX shell as a Chesterton's Fence.