git - 远程仓库文件名的大小写与本地不同，但没有看到任何变化

Question

当我浏览到 gitlab 中包含特定文件的目录时，我看到 TimeHhMM.cs (第二个“M”大写)。

但在我的本地存储库中，该文件是 TimeHhMm.cs (第二个“m”小写)。

奇怪的是，git 并不认为这是值得提交的更改。不过，偶尔会出现一些奇怪的情况，表明存在问题。我刚刚从原始存储库重新克隆，并通过远程指向我的本地文件系统，从旧的本地存储库引入分支。然后，git status 显示 TimeHhMM.cs 已删除，但没有添加 TimeHhMm.cs。当我放弃删除并将文件重命名为适当的 TimeHhMm.cs 时，git 发现提交没有任何差异。

这真的很奇怪。为什么它一方面会检测到文件已被删除(区分大小写)，但一旦我将其带回并重命名，它就无法检测到带有小写“m”的"new"文件？

我可以通过删除文件然后在两个单独的提交中重新添加它来解决此问题，但似乎应该有某种方法可以导致此操作在单个提交中发生。有吗？

Answer 1

该行为由core.ignoreCase变量控制。引用the docs :

If true, this option enables various workarounds to enable Git to work better on filesystems that are not case sensitive, like FAT. For example, if a directory listing finds "makefile" when Git expects "Makefile", Git will assume it is really the same file, and continue to remember it as "Makefile".

The default is false, except git-clone or git-init will probe and set core.ignoreCase true if appropriate when the repository is created.

情况可能就是这样。您始终可以使用以下命令将其重置为 false:

git config core.ignorecase false

---

这个(相当旧)forum thread揭示了探测到底是如何完成的:

As far as I can tell from the code (I obviously only look at the plain vanilla git, and msysgit might have some patch to this part, I dunno. Oh by the way you didn't say which version you are complaining about, either), we do the probing on all systems (including POSIX folks with FAT filesystem mounted) by first creating .git/config and then checking if a file .git/CoNfIg which we know we never created can be accessed. If we can, that means the filesystem ignores case, iow, we cannot have two files config and CoNfIg at the same time, and set core.ignorecase to true.