rev-parse drive casing no longer dependent on cwd input

[eamodio]

• 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.25.0.windows.1
cpu: x86_64
built from commit: 7c71c859c97853ed057da5cbab12f3c13b5554df
sizeof-long: 4
sizeof-size_t: 8

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

• 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: VIM
Custom Editor Path:
Path Option: Cmd
SSH Option: OpenSSH
Tortoise Option: false
CURL Option: OpenSSL
CRLF Option: CRLFAlways
Bash Terminal Option: MinTTY       
Performance Tweaks FSCache: Enabled
Use Credential Manager: Enabled    
Enable Symlinks: Disabled

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

No

Details

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

CMD (shelled out via execFile in node.js)

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

git rev-parse --show-toplevel

I am shelling out to git via execFile in node.js to run this command. And I am passing a cwd path like c:/Users/Eric/code/eamodio/vscode-gitlens. Prior to Git v2.25, the return of the command would be c:/Users/Eric/code/eamodio/vscode-gitlens (since that is the root folder of the repo). But in v2.25 the return is C:/Users/Eric/code/eamodio/vscode-gitlens note the capital C.

This is not reproducible on the command line. As it seems that on the command line you always get C:/Users/Eric/code/eamodio/vscode-gitlens.

So prior to v2.25, the toplevel path returned seemed to be dependent on the incoming cwd, where as in v2.25 it is not.

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

Expected the same behavior as prior to v2.25

• What actually happened instead?

Prior to v2.25, the toplevel path returned seemed to be dependent on the incoming cwd, where as in v2.25 it is not.

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

https://github.com/eamodio/vscode-gitlens

I only noticed this behavior change, because once upgrading to Git v2.25 GitLens in VS Code broke and I tried to track down what the difference was.

[dscho]

git rev-parse --show-toplevel

I am shelling out to git via execFile in node.js to run this command. And I am passing a cwd path like c:/Users/Eric/code/eamodio/vscode-gitlens. Prior to Git v2.25, the return of the command would be c:/Users/Eric/code/eamodio/vscode-gitlens (since that is the root folder of the repo). But in v2.25 the return is C:/Users/Eric/code/eamodio/vscode-gitlens note the capital C.

This is not reproducible on the command line. As it seems that on the command line you always get C:/Users/Eric/code/eamodio/vscode-gitlens.

So prior to v2.25, the toplevel path returned seemed to be dependent on the incoming cwd, where as in v2.25 it is not.

I guess that this is a difference between GetLongPathNameW() and GetFinalPathNameByHandleW(). We used to call the former, and only when that failed, we fell back to the latter.

However, we changed this because the former did not resolve symbolic links while the latter does.

Do you need to continue relying on the exact case, or could you make whatever comparison GitLens performs by a case-insensitive one if core.ignorecase = true?

[dscho]

I guess that this is a difference between GetLongPathNameW() and GetFinalPathNameByHandleW().

If you get a chance to compile Git for Windows from source, you could revert 1e64d18 and see whether that "fixes" the issue.

Do you need to continue relying on the exact case, or could you make whatever comparison GitLens performs by a case-insensitive one if core.ignorecase = true?

If you cannot switch to a case-insensitive comparison on case-insensitive filesystems, I would be willing to accept a PR that forces the drive letter (if any) to upper case right after a successful call to GetFinalPathNameByHandleW(), i.e. something like this (I leave the testing to you):

diff --git a/compat/mingw.c b/compat/mingw.c
index f5de482c545..6f1791ecbd3 100644
--- a/compat/mingw.c
+++ b/compat/mingw.c
@@ -917,6 +917,9 @@ int mingw_chdir(const char *dirname)
 			CloseHandle(hnd);
 			return -1;
 		}
+		/* Force the drive letter (if any) to upper case */
+		if (wdirname[0] >= L'a' && wdirname[0] <= L'z' && wdirname[1] == L':')
+			wdirname[0] += L'A' - L'a';
 		CloseHandle(hnd);
 	}
 
@@ -1274,6 +1277,9 @@ char *mingw_getcwd(char *pointer, int len)
 		CloseHandle(hnd);
 		if (!ret || ret >= ARRAY_SIZE(wpointer))
 			return NULL;
+		/* Force the drive letter (if any) to upper case */
+		if (wpointer[0] >= L'a' && wpointer[0] <= L'z' && wpointer[1] == L':')
+			wpointer[0] += L'A' - L'a';
 		if (xwcstoutf(pointer, normalize_ntpath(wpointer), len) < 0)
 			return NULL;
 		return pointer;

[joaomoreno]

Possibly related, seen on VS Code itself:

In 2.25, when core.ignorecase=false, and spawning with cwd set to a lowercase drive letter path such as c:\Users\joao\Work\fakeproject commands now fail:

$ git add -A -- c:\Users\joao\Work\fakeproject\folder\yeah.txt
fatal: c:\Users\joao\Work\fakeproject\folder\yeah.txt: 'c:\Users\joao\Work\fakeproject\folder\yeah.txt' is outside repository

Which seems weird, since the same casing is respected. So as a workaround we're going to have to always uppercase the drive letter when passing paths to git, regardless of what cwd we spawn it from.

[joaomoreno]

OK this is getting even weirder:

In 2.25, when core.ignorecase=false, and spawning with cwd set to a lowercase drive letter path such as c:\Users\joao\Work\fakeproject this will also fail:

> git clean -f -q -- c:\Users\joao\Work\fakeproject\.vscode\settings.json
fatal: c:\Users\joao\Work\fakeproject\.vscode\settings.json: 'c:\Users\joao\Work\fakeproject\.vscode\settings.json' is outside repository

And this (uppercase drive letter) succeeds but it's a no-op:

> git clean -f -q -- C:\Users\joao\Work\fakeproject\.vscode\settings.json

So it seems we simply can't use lowercase drive letters in cwd any more.

EDIT: Actually this seems like a different bug altogether, unrelated to core.ignorecase=false, but related to calling clean on a path which isn't at the root of the repository. 🤔

EDIT 2: Created #2499 for this.

[dscho]

@joaomoreno this suggestion applies to you, too. Please do try out that patch.

[dscho]

This is not reproducible on the command line.

@eamodio I beg to differ. I just tried this with v2.24.1 and with v2.25.0: git -C c:/git-sdk-64 rev-parse --show-toplevel. As you described, the former version retains the lower-case c while the latter up-cases the drive letter.

FWIW I had misunderstood when I wrote that patch, thinking that you actually wanted the v2.25.0 behavior and that that somehow got broken.

Now, the thing is that the paths are supposed to be case-insensitive. And that very much includes the drive letter.

So I would definitely contend that the expectation of a lower-case drive letter to be preserved is a untenable. The paths are normalized. For example, if you have initialized a Git repository at C:\git and then call git -C c:\giT rev-parse --show-toplevel, you would not expect that T to be kept incorrectly as an upper-case T, right? You would want it to be normalized to the canonical path.

And that is precisely what v2.25.0 does.

Therefore, I am rather certain that the described behavior of v2.25.0 is actually desired, and the one of v2.24.1 was not. In other words: it is not a bug, the current Git for Windows version performs as designed.