将 git config core.ignorecase 设置为 false 是个好主意吗？

Question

我的团队目前管理跨多个文件系统的 git 存储库。我们大多数人使用 Windows，但也有一些人使用 Linux。另外，我们将生产代码部署在 Linux 服务器上。这导致了我们的代码库中文件名大小写的多个问题（即，Foo.js当文件实际上是 时导入foo.js）。最近，我完成了对项目文件夹的清理，主要包括重新组织目录并将目录/文件重命名为通用命名标准。许多文件名更改都改变了文件的大小写（例如foo.js-> Foo.js）。

\n\n

当我进行这些更改时，我并没有完全意识到 git 在区分大小写和不区分大小写的文件系统上如何以不同的方式处理文件名，这导致了很多奇怪的错误。我在研究这个问题时遇到的一件事ignorecase是.gitconfig.

\n\n

来自 git-config 文档：

\n\n

\n

内部变量，它支持各种解决方法，使 Git 能够在不区分大小写的文件系统上更好地工作，例如 APFS、HFS+、FAT、NTFS 等。例如，如果目录列表在 Git 时找到“makefile”如果需要“Makefile”，Git 会假设它确实是同一个文件，并继续将其记住为“Makefile”。

\n\n

\xe2\x80\xa6

\n\n

Git 依赖于您的操作系统和文件系统对此变量的正确配置。修改此值可能会导致\n 意外行为。

\n

\n\n

据我所知，设置ignorecase = true将使得如果 git 检测到相同的文件名但大小写不同，它将更改 git 索引中的名称以匹配文件系统上的名称（即，如果 Windows hasfoo.js和 git checkout/pull has Foo.js，它会假设这foo.js是正确的，并且 git 将使用该大小写）。我担心的是，如果我推送到远程并且我们的部署服务器接收到更改会发生什么。然后它将尝试导入Foo.js不存在的内容并出错。

\n\n

但是，通过设置ignorecase = false，git 应该能够检测到文件名存在差异并正确替换文件。这是正确的吗？因为我们跨不同的文件系统工作，我是否应该让我的团队将此值设置为 false？

\n\n

我读过一些帖子，人们说你绝对应该这样做，而有些帖子的说法恰恰相反。

\n

Answer 1

据我所知，设置ignorecase = true将使得如果git检测到相同的文件名但大小写不同，它将更改git索引中的名称以匹配文件系统上的名称（即如果 Windows 有foo.jsgit checkout/pull 有Foo.js，它将假定这foo.js是正确的并且 git 将使用该大小写）。

不，这是倒退的：文档指出，如果索引当前包含 a Foo.js，并且工作树出于某种原因包含 a foo.js，Git 会假设它foo.js确实存在Foo.js，并将放入Foo.js下一次提交中。然而，如果core.ignorecase设置为false，Git 完全相信工作树：git add .将删除大写名称（和内容）并使用小写名称foo.js根据工作树中的副本在索引中安装新副本。

（要查看索引中的内容，请使用git ls-files --stage，或省略 来--stage仅获取文件名。请注意，这会转储整个索引内容！添加路径参数以选择特定文件，例如 ，git ls-files "[Ff]oo.js"以仅查找这些文件。引号在类 Unix shell（例如 bash）中，需要防止 shell 解释[Ff]这里的元字符。shell 将删除引号。在其他特定于 Windows 的命令行解释器中使用什么，我不确定。）

一般来说，您不应该更改core.ignorecase. 如果你想重命名一个文件，最直接的方法是使用git mv（同时调整索引和工作树）。如果您只想更改大小写，您可以git mv两次：

git mv foo.js temporary-name
git mv temporary-name Foo.js

现在您Foo.js在索引和工作树中都拥有了初始资本。某些版本的 Git 可能能够在没有中间临时名称的情况下处理此问题，但当您使用中间名称时，所有版本都会做正确的事情。