add support for full case sensitivity

[jtnord]

• 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.16.2.windows.1
cpu: x86_64
built from commit: e1848984d1004040ec5199e749b5f282ddf4bb09
sizeof-long: 4

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

• 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
Path Option: Cmd
Plink Path: C:\Program Files\PuTTY\plink.exe
SSH Option: Plink
CURL Option: OpenSSL
CRLF Option: CRLFCommitAsIs
Bash Terminal Option: ConHost
Performance Tweaks FSCache: Enabled
Use Credential Manager: Enabled
Enable Symlinks: Enabled

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

Nope

Details

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

cmd.exe

• git clone / git checkout? If you can provide a
  Minimal, Complete, and Verifiable example
  this will help us understand the issue.

git clone https://github.com/jenkins-x/jx-docs.git
git checkout e2deb350438183925be23b190019f4dfdf5cea77

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

No modified fiels are present.
both content/commands/jx_get_Apps.md and jx_get_apps.md are present.

Note they differ only by case

• What actually happened instead?

git thinks content/commands/jx_get_Apps.md is modified.

• 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/jenkins-x/jx-docs.git
https://github.com/jenkins-x/jx-docs/tree/e2deb350438183925be23b190019f4dfdf5cea77/content/commands

Any repo that has files that only differ by case will show this issue (can be created on a linux machine)

NTFS is a case sensitive file system. Windows by default disables case sensitivity so that it is only case-preserving.

You can override this behaviour but only on a per folder basis.
This request is that git when checking out etc sets (via an opt-in/opt-out option) the flag that causes the system to be treated case sensitive on every folder in the working directory (and follows through that all git commands on windows will use the correct case).

to enable the per directory case sensitivity you can run fsutil.exe file SetCaseSensitiveInfo drive:\path\to\folder enable

or you can possibly (untried) reproduce this by perfoming a git clone of an arbitraty repo, running bash (the WSL one not the git one)and then creating a new folder in the workspace and runningecho one > oneandecho ONE > ONE` verify that both files exist then watch git get confusued.

[dscho]

Oh wow. This is a pretty new feature, only supported when you have installed WSL, and you probably know that you tried to dump a whole lot of work into somebody else's lap.

[Com3t]

You might try to disable Windows Object Manager case-insensitivity by clearing the following registry key to 0:
HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\kernel
DWORD “obcaseinsensitive”

[PhilipOakley]

@jtnord @Com3t maybe you could collaborate on trying out these ideas to see if they may be an option (and how to manage the potential conflicts with other regular Windows user tools).

It would need to be pretty robust given the number of Git for Windows downloads (and hence issues from the tail of the Kruger-Dunning "UNSKILLED AND UNAWARE" curve)

[jtnord]

(and how to manage the potential conflicts with other regular Windows user tools).

most tools are already do the right thing and use the same case for the filename as the one they opened, for ones that do not I would expect this is an opt-in per repository (or global) such that this would only affect repositories that require this behaviour anyway. So either you have a broken clone (really really bad, or you have a working clone where some tools may not work which to me is the lesser of 2 evils)

[PhilipOakley]

I was thinking about the opening of files being often case insensitive, so the opened file may not be the one expected.
There have been similar issues for branch and ref names, including HEAD/head, etc.

Mainly I was warning that it could be an uphill struggle, as so many folks (on Windows) just assume that they can be case insensitive (while some are over-sensitive) without realising.

[jtnord]

creating new files is case preserving by default, and opening of files you are right will fudge case unless you have told windows not to for this folder (which is what would need to happen). But generally the filename would come from something that has enumerated the files on disk so they should be correct. The exception is where a user types in the filename in the wrong case and it does not work, but well that's what we want if we want case sensitivity on windows :-)

There have been similar issues for branch and ref names, including HEAD/head, etc.

Now I am curious... how about two different branches that only differ in case? (I only thought about filenames but well branches are just filenames too!). Maybe this is already handled (but looking on disk it seems it may not be)

[PhilipOakley]

There have been similar issues for branch and ref names, including HEAD/head, etc.

Now I am curious... how about two different branches that only differ in case? (I only thought about filenames but well branches are just filenames too!). Maybe this is already handled (but looking on disk it seems it may not be)

At present git for windows will happily checkout 'Branch' when really it's 'branch', and then when asked will give the branch list without the '*' marker for the current branch - there are plenty of older issues with that and similar problems...

At the moment, the upstream Git code often has separate call stacks for the names and the paths so that cross checking can be a real pain, along with the difficulties (i.e. slowness) of getting Windows to tell you the true on-disk name of a file. I've been keeping out of that tar pit, so much of my commentary is 'from a distance'.

[dscho]

I get the distinct impression that nobody wants to work on this, so let's just close this ticket.