Bryan Turner <bturner@xxxxxxxxxxxxx> writes: > Git on Windows is not designed to run with anything other than > core.ignoreCase=true, and attempting to do so will cause unexpected > behavior. Even though I fully agree with your conclusion that the document must make it crystal clear that core.ignoreCase must be set to reflect the reality, I found the above statement misleading and do not want it to be used as the basis of a documentation update. But it is possible that I am misunderstanding the current state of affairs. Is the case insensitivity that deeply ingrained in the Git for Windows code? IOW, even if the code used to build Git for Windows were executed on a case sensitive filesystem, is there a case-smashing code on _our_ side that kicks in to cause unexpected behaviour, _even_ when core.ignorecase is set to false to match (hypothetical) reality? To put it yet another way, if a case sensitive filesystem were available, wouldn't running "git init" from Git for Windows in a directory on such a filesytem set core.ignoreCase to false in the resulting repository and from then on wouldn't everything work fine? If my suspicion (i.e. the code for Git for Windows is perfectly fine---it is just the users are not running with case sensitive filesystems and flipping core.ignoreCase to true does not make case incapable filesystems suddenly capable) is correct, then it is not "Git on Windows is not designed to run" from two angles. (1) it is not just Git for Windows---Git running on UNIX that mounts VFAT, or Git running on macOS with default HFS+, would exhibit the same symptom, and (2) it is not "Git is not designed to run"---it is core.ignoreCase that is not designed to be a way to make case incapable filesystems suddenly capable of distinguishing cases in filesystems. Thanks.
