Git gutters don't show when you Uppercase a filename

[deejaybill]

• VSCode Version: Code 1.13.1 (379d2ef, 2017-06-14T18:21:47.485Z)
• OS Version: Windows_NT ia32 10.0.15063
• Extensions:

Extension	Author	Version
azurenodeessentials	azuresdkteam	0.2.6
vscode-eslint	dbaeumer	1.2.11
code-runner	formulahendry	0.6.24
beautify	HookyQR	1.1.1
minify	HookyQR	0.3.0
ftp-sync	lukasz-wronski	0.3.3
yo	samverschueren	0.9.3
vscode-wakatime	WakaTime	1.1.12
vsc-jsonsnippets	wmontalvo	0.1.4

---

Git gutter doesn't show when you Uppercase a filename (partial or full)

Steps to Reproduce:

1.Add some code to an existing repository and rename the filename with an Uppercase (in the screenshot app.js -> App.js)
2.The git gutters disappear and the Source Control tab stage the changes with the old filename (app.js instead of App.js)
3. Commit the staged changes
4. Add some code to the renamed file
5. Git gutters doesn't show again but the Working Tree looks good
6. If you rename the files as before (App.js -> app.js) the git gutters appear correctly

[rianadon]

It seems this is because Windows treats file case insensitively, but git's object storage treats them case sensitively. Therefore, to git only app.js exists, while it's App.js under Windows.

From what I can tell VS Code executes git show :App.js (feel free to correct me if I'm wrong) to retrieve the contents of the file before the modifications, and runs its own diffing internally. However since to git App.js doesn't exist, VS Code's diffing treats the file as a new file.

The only solution I can think of would be in the cases that git show fails, to query what files git knows about (through git ls-files), try to case-insensitively find the current filename in the output of the command, and if it is present use the git-provided filename in the git show command.

If no one can think of a better solution I'd be happy to write a PR for this.

[deejaybill]

I know the difference between Windows and Unix based system about the filename case sensitive but git and vscode are software that run not only in Windows bus also in macOS and Linux. I think due to Windows "limitations" the only case you can't have is two files with these name: app.js and App.js but you have to handle the rename from app.js to App.js for git and the other OS.

[rianadon]

I'm not sure I understand what you mean.

What I was trying to explain was that because windows treats app.js and App.js as the same file (so you can't have both as you said), git decides to ignore the rename and thinks that only app.js exists, while to windows an App.js exists and when Windows tries to query git for App.js git's object storage is case sensitive and believes it doesn't exist, hence unless there is a way to make the git show command case sensitive whatever fix this issue requires will need to query the case of the files git knows about.

As for the rename there are ways of getting git to recognize this (using git mv rather than the filesystem's move which will force git to recognize the rename or making git treat files case sensitively). I'm not sure whether it would be a good idea for VS Code to stage files as a site effect of git mv or to tamper with options. However even if VS Code manages the move in a way that triggers git to recognize the rename it should still handle cases where this is done from outside VS Code.

[BuraChuhadar]

Renaming a file creates a new file and removes the old renamed file and makes the new file unstaged. For that reason, unstaged file doesn't show the git gutters. Thus, this is not directly related to renaming a file with uppercase letters. It happens when you rename the file no matter what. Same problems happens if you create a new file, it doesn't show the git gutters. @joaomoreno I would like to take a look at this but I am not sure what can be done in terms of fixing the issue. Should unstaged files show git gutters or renaming a file should automatically staged the newly created file?

[joaomoreno]

Actually, like @bugrac, I'm not so convinced we should do anything. For git this is a simple file move, for which the disappearance of the gutter decorations makes sense. I don't think unstaged files should show gutter decorations and we should definitely not automatically stage anything.

What is interesting for me is that git continues to report the file as lowercase after the rename.

[pcblues]

I haven't come across a use case for renaming the case of a file where the history isn't wanted to be kept. If I change the case of a filename, it's usually a correction for style rather than a desire to create a new file. Interestingly, the file extensions/git/src/git.ts doesn't include mv in its available commands. If you manually do a git mv on a file after changing the case in vscode, it behaves more how I would want it to in vscode. YMMV.

[joaomoreno]

Interestingly, the file extensions/git/src/git.ts doesn't include mv in its available commands.

Code doesn't need to. The equivalent of git mv is achieved by renaming the file and staging the two changes (add, delete). It will appear as a move in the index. That is exactly what you would get with git mv: the change is staged.

[pcblues]

I ran tests to check this:

• The problem is that on a case-insensitive file system, Code doesn't bring the file name change through to git if only the case of the name is changed.
• Changing the case of a file in Code is not the same as git mv on a case-insensitive file system.
• When you push the changes to a remote repository and clone the repository to a case-sensitive file system, the original case of the file is created.
• This is going to cause problems eventually. If we made the rename function in Code also call a git mv when the file name change is only different by case, then the record of the case change in the filename will be saved to the repository correctly even if it is done on a case-insensitive file system. (I know this issue is about gutters, but I think it has exposed a real problem in keeping filenames aligned between case-insensitive and case-sensitive file systems)
• I have been looking at how best to do this, and would be happy to try to come up with a pull request if you are interested.

[joaomoreno]

The problem is that on a case-insensitive file system, Code doesn't bring the file name change through to git if only the case of the name is changed.

What happens if you rename the file in the Windows Explorer and run git status? You'll notice this behaviour isn't related to Code at all. It's not about Code bringing file name changes to git or otherwise.

If we made the rename function in Code also call a git mv when the file name change is only different by case, then the record of the case change in the filename will be saved to the repository correctly even if it is done on a case-insensitive file system.

This is a bad idea since it involves automatically staging changes.

[rianadon]

I agree. Automatic staging of files would be more annoying than helpful and once you unstage the file it turns back into delete + add operations. I also have never run into a case where I'd want to change the case of a filename and not want that tracked by git, and I'd presume that this would be a fairly rare case. However not handling untracked filename case changes is an edge case that VS Code does not handle. For showing git gutters on files that have been moved but not yet staged, I wonder if VS Code could use the same algorithm that git uses to turn an add + delete into a move upon staging to determine the move operation, and use that in its diffing.

…

[pcblues]

OK. Off to find another issue :)

[alexkrolick]

We've had issues creating files/folders in VSCode on Mac (case-insensitive), then building the app on a Linux server. Occasionally half the files in a folder will show up in MyFolder and the rest in myfolder.

[agm1984]

Here is some sample code that may be relevant here. I came across it for doing fuzzy searches:

const searchTerms = (opts.caseSensitive) ? new RegExp(term) : new RegExp(term, 'i')

The 'i' option makes it case insensitive.

In that example, opts.caseSensitive is a boolean, and term is the search term such as "Bob" or "bob".

My overall point would be that there could and probably should be some kind of Exact Match [true/false] toggle.

[joaomoreno]

Fixed by #49397