"/" is replaced with the directory path of Git installation when using MinGW64 Bash

[moonchant12]

• I was not able to find an open or closed issue matching what I'm seeing

Setup

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

$ git --version --build-options

git version 2.34.1.windows.1
cpu: x86_64
built from commit: 2ca94ab318509b3c271e82889938816bad76dfea
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.22000.376]

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

# One of the following:
> type "C:\Program Files\Git\etc\install-options.txt"
> type "C:\Program Files (x86)\Git\etc\install-options.txt"
> type "%USERPROFILE%\AppData\Local\Programs\Git\etc\install-options.txt"
$ cat /etc/install-options.txt

Editor Option: Notepad
Custom Editor Path:
Default Branch Option:
Path Option: Cmd
SSH Option: OpenSSH
Tortoise Option: false
CURL Option: OpenSSL
CRLF Option: CRLFAlways
Bash Terminal Option: MinTTY
Git Pull Behavior Option: Merge
Use Credential Manager: Enabled
Performance Tweaks FSCache: Enabled
Enable Symlinks: Disabled
Enable Pseudo Console Support: Disabled
Enable FSMonitor: Disabled

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

It's only an average desktop environment.

Details

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

MinGW64 Bash

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

user@Desktop MINGW64 ~/Downloads/NewFolder
$ git init
Initialized empty Git repository in C:/Users/user/Downloads/NewFolder/.git/

user@Desktop MINGW64 ~/Downloads/NewFolder (master)
$ touch a.txt

user@Desktop MINGW64 ~/Downloads/NewFolder (master)
$ git add .

user@Desktop MINGW64 ~/Downloads/NewFolder (master)
$ git commit -m "/somecommit"
[master (root-commit) dc6ec94] D:/Program Files/Git/somecommit
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 a.txt

user@Desktop MINGW64 ~/Downloads/NewFolder (master)
$ git log
commit dc6ec94041d455313cf21ca3a3a8f7f3cbe4471a (HEAD -> master)
Author: _ <_>
Date:   Mon Jan 10 04:39:43 2022 +0900

    D:/Program Files/Git/somecommit

user@Desktop MINGW64 ~/Downloads/NewFolder (master)
$

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

git commit -m "/somecommit"

• What actually happened instead?

git commit -m "D:/Program Files/Git/somecommit"

• If the problem was occurring with a specific repository, can you provide the
  URL to that repository to help us with testing?

This happens in any repository.

[rimrul]

That's the posix to windows path conversion.

Use MSYS_NO_PATHCONV=1 git commit -m "/commit".

https://github.com/git-for-windows/build-extra/blob/main/ReleaseNotes.md#known-issues

[moonchant12]

Not a chance we would get a better workaroud?

user@Desktop MINGW64 ~/Downloads
$ echo "/"
/

user@Desktop MINGW64 ~/Downloads
$ git "/"
git: 'D:/Program Files/Git/' is not a git command. See 'git --help'.

user@Desktop MINGW64 ~/Downloads
$

WTF? Even $ echo "/" can print /.

I just don't get a sense how come $ git "/" has to be replaced with $ git "D:/Program Files/Git/".

[moonchant12]

This undesired path conversion is not a user's fault. MSYS_NO_PATHCONV=1 gives only a temporary solution. I hope people recognize the issue to be fixed, not accepting it as a feature.

[rimrul]

Not a chance we would get a better workaroud?

Unlikely. Well, maybe the trick with the two slashes would work here.

WTF? Even $ echo "/" can print /.

Because echo is a shell builtin. Path conversion only happens when calling non-msys2 programs.

I just don't get a sense how come $ git "/" has to be replaced with $ git "D:/Program Files/Git/".

Because the msys2 runtime has no way of knowing what git is supposed to do with that argument that looks likee a posix path.

[rimrul]

This undesired path conversion is not a user's fault. MSYS_NO_PATHCONV=1 gives only a temporary solution. I hope people recognize the issue to be fixed, not accepting it as a feature.

Well it is listed under "known issues", so we do recognize it's an issue, but likely one that we won't have a solution for within the next couple of years.

[moonchant12]

Thanks for the answer. Then can we make Windows git to use MSYS_NO_PATHCONV=1 by default in its own MinGW64 shell? So users don't have to type MSYS_NO_PATHCONV=1 git everytime they launch git. We've confirmed that it at least works well in MSYS_NO_PATHCONV=1 git commit -m "/somecommit".

[rimrul]

Thanks for the answer. Then can we make Windows git to use MSYS_NO_PATHCONV=1 by default in its own MinGW64 shell?

Absolutely not. That would break a lot of things.

So users don't have to type MSYS_NO_PATHCONV=1 git everytime they launch git.

They don't have to and in fact shouldn't. MSYS_NO_PATHCONV should be used sparingly.

We've confirmed that it at least works well in MSYS_NO_PATHCONV=1 git commit -m "/somecommit".

That it does what you want it to do in this one specific edgecase, does not mean you should use it all the time, for everything.

[dscho]

Another user might be equally focused on only their use case and say: "why on Earth would anybody start their commit message with a slash? Just don't!".

We cannot cater to everybody's favorite workflow at the same time, we have to make a compromise.

And changing a default that literally millions of users have grown accustomed to, over the course of more than 14 years, sounds like a really foul compromise to me. I won't do that. I owe that to the existing users.