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

Question

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

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

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

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

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

Answer 1

行为由core.ignoreCase变量控制。引用文档：

如果true，则此选项启用各种解决方法，使 Git 能够在不区分大小写的文件系统（例如 FAT）上更好地工作。例如，如果一个目录列表"makefile"在 Git 期望的时候 找到"Makefile"，Git 将假定它确实是同一个文件，并继续将其记住为"Makefile"。

默认值是false，除非git-clone或将在创建存储库时git-init探测并设置core.ignoreCase true（如果适用） 。

情况可能就是这样。false您可以随时使用以下命令将其重置为：

git config core.ignorecase false

这个（相当古老的）论坛帖子揭示了如何准确地进行探测：

据我从代码中可以看出（我显然只查看普通的 git，并且msysgit可能对这部分有一些补丁，我不知道。哦，顺便说一句，你也没有说你抱怨的是哪个版本） ，我们对所有系统（包括安装了 FAT 文件系统的 POSIX 系统）进行探测，首先创建.git/config一个我们知道从未创建过的文件，然后检查是否.git/CoNfIg可以访问该文件。如果可以，这意味着文件系统忽略大小写，iow，我们不能同时拥有两个文件，并将其设置 config为true。CoNfIgcore.ignorecase