如何在Windows上解决与Git的文件夹大小写冲突？

Question

我正在做git rebase，我被卡住了，因为在一次提交中我有一个名为Proto的文件夹，但在另一次提交中我有一个名为proto的文件夹。这是一个诚实的错误，在两种情况下都应该是Proto。我能想到的最好的方法是尝试从两次提交中删除文件夹，然后再次尝试使用rebase，但必须有更好的方法。

过去，当我遇到文件的大写问题时，我使用了git mv，但是对于文件夹它不会让我运行git mv，我不知道为什么。

在Windows上的git中修复文件夹大小写问题的正确方法是什么？

Answer 1

当大量文件被移动到不同的目录时，我们在Windows上的git存储库中遇到了类似的问题。

我第一次手动修复了我们的问题，将存储库克隆到Linux VM并运行带有git mv命令的bash脚本来修复文件路径案例问题。这是一个痛苦的过程，所以我决定开发一个自动化过程的实用程序。

Git Unite是我使用libgit2sharp库编写的.NET控制台应用程序。该程序识别所有git索引条目，其文件路径大小写与Windows文件系统报告的大小不同。

我写了一篇博文，详细介绍了Git Unite - Fix Case Sensitive File Paths on Windows

背后的工具，用法和历史

Answer 2

走私文件夹重命名为Git历史很困难，因为文件夹不会被跟踪 - 只有文件夹中的文件。假设您要将oldFolder重命名为oldfolder，可以尝试以下操作：

1. 从oldFolder中首次创建文件的位置开始以交互方式重新生成基础。编辑将文件添加到此文件夹的每个提交。当交互式rebase停止时，创建newFolder并执行git mv oldFolder/* newFolder/。对交互式rebase的每个停止执行后者。

2. 显然，您不能让oldFolder和newFolder成为Windows中同一个词的两个不同大小的版本。因此，请重复步骤1，将newFolder重命名为oldfolder。

Answer 3

git config --global core.ignorecase true应该可以在Windows上解决您的问题。

Answer 4

将帖子 我怀疑你需要将文件夹中的每个文件“git mv”转换为临时名称，如'ProtoX'，然后将“git mv”临时命名的文件改为'Proto'，因为Git不会自己跟踪文件夹 - 只有文件夹中的文件。

双“git mv”适用于Windows不区分大小写的文件系统。 （您应该能够在区分大小写的文件系统（例如Linux）上直接从'proto'移动到'Proto'。）