Git gutters don't show on filenames that have changed case

• VSCode Version: 1.47.3 91899dcef7b8110878ea59626991a18c8a6a1b3e
• OS Version: MacOS 10.14.6

Steps to Reproduce:

1. Initialize a git repository~ 2. Add a capitalized filename, e.g. Counter.jsx 3. Commit the file 4. Make some changes in the file and save

The file will show as modified in the explorer, but the changes are not shown in the gutter. If you follow the same step but with a lowercase filename instead, the modifications will appear in the gutter. This is problematic for React projects where uppercase filenames are not uncommon.

Edit: See my modified instructions below

This issue was already brought up in #48714 and closed by 375411e, but the issue still occurs. I’m opening this new issue since the old one is locked.

Does this issue occur when all extensions are disabled?: Yes

[Dionysusnu]

I’d just like to point out the bug also stretches to the built-in diff view. If you open that, select a range, right click and use “Stage selected ranges”, it gets staged in git as a new file that has the original casing, with the additions from the selected range as its only content.

While that original-case file is staged, the gutters do show up in the editor for the new-case file. Trying to stage something again in the diff view appends the additions from that range to the original-casing file.

It also creates an entry for the original-case file in the unstaged changes list. Viewing the diff of this shows it as the whole file being an addition, except for the range originally marked for staging.

Unstaging the original-case file in its entirety makes everything go back to the same state as before the first stage action, in which the file is shown only once in the changes window, and the gutters are not visible.

As suggested in https://github.com/microsoft/vscode/issues/103444#issuecomment-687071845, the bug stuck around if reloading while the file was open, but went away after closing all open file views and then reloading window.

[jrieken]

Well, I guess the uri identity service won’t help you then because it doesn’t know what the actual representation is. If the git is so sensitive then I am afraid that you need to resolve the true casing before interacting with git.