windows - Git:在保留历史记录的同时协调 Windows 中具有重复名称(大小写不同)的两个文件夹

Question

我最近发现我的解决方案中有几个文件夹在 Git 中有两个不同的路径(GitHub 显示两个单独的文件夹)，一个是 FooBar另一个是 Foobar .这是因为有些文件是用前一个文件夹名称作为它们的路径注册的，有些是用后者注册的。

这是通过将 Git 配置为不忽略大小写在本地(在 Windows 中)发现的:git config core.ignorecase false
我通过删除整个文件夹，提交，然后重新添加文件夹并再次提交来解决这个问题。这解决了问题，但是改变了路径的文件丢失了他们的 Git 历史 .运行gitk针对这些文件的新路径只显示了一个提交。运行gitk在他们的旧道路上揭示了他们的全部历史。

下一个刺:使用git mv移动文件:
git mv Foobar/file.txt FooBar/file.txt
这会产生错误:
fatal: destination exists, source=Foobar/file.txt, destination=FooBar/file.txt
如果我先尝试删除文件，Git 当然会提示源文件不存在。

然后我发现如果你添加 -f，Git 不会提示目的地已经存在。到mv命令。但是，在提交重命名后，gitk表明历史无论如何都被切断了!

我什至尝试做 three step dance described here但这只是执行 -f 的另一种方式.结果相同。

基本上我只想从 Foobar/file.txt 移动一个文件至FooBar/file.txt以某种方式在不区分大小写的操作系统中，同时保留 Git 历史记录。这可能吗？

Answer 1

真正的问题没有简单的解决方案。

在 Git 中，文件没有历史记录。提交有历史——或者更准确地说，提交就是历史。这就是所有的历史。让 Git “跟随”一个文件，如 git log --follow <path> , Git 查看提交，一次一个，将每个提交与其父提交进行比较。

如果父与子之间的差异显示父包含名为 parent/path/to/pfile 的文件并且 child 包含一个名为 child/path/to/cfile 的文件并且这两个文件的内容，在这两个提交中，“非常相似”(这里必须满足几个条件)，然后，在 Git 的“眼中”，父子转换代表该文件的重命名。所以那时，git log --follow , 一直在寻找 child/path/to/cfile , 开始寻找 parent/path/to/pfile .

没有 --follow , git log不做这种特殊的“查找重命名”操作……而且一般来说，Git 认为任何具有任何字节级别差异的路径名都代表不同的文件。换句话说，不会发生大小写折叠和 UTF-8 规范化。例如，考虑 schön 这个词, 可以表示为 s c h ö n或 s c h o结合- ¨ n .我们可以在 Linux 机器上使用这两个不同的 UTF-8 样式名称创建两个不同的文件。运行ls将显示两个名称相同的文件:

$ cat umlaut.py
import os
p1 = u'sch\N{latin small letter o with diaeresis}n'
p2 = u'scho\N{combining diaeresis}n'
os.close(os.open(p1.encode('utf8'), os.O_CREAT, 0o666))
os.close(os.open(p2.encode('utf8'), os.O_CREAT, 0o666))
$ python umlaut.py
$ ls
schön  schön  umlaut.py

Git 非常乐意分别存储这两个文件。但是，MacOS 拒绝允许这两个文件共存，就像 Windows(就此而言，默认情况下 MacOS 也是如此)拒绝允许两个文件共存 Foobar和 FooBar共存。

让Git将文件存储在新的字节序列下的新提交中，并保留历史记录，这不是您想要保留的历史记录。但是已经在存储库中的历史已经不是您想要保留的历史了。

在实践中，您可能应该只是在 Git 眼中重命名文件——这对您的操作系统眼中的文件名没有影响； FooBar和 Foobar在这里是同一个名字——然后继续做事。您的替代方法是通过将每个“坏”提交复制(稍作修改)到一个新的和改进的“好”提交来重写所有历史，使其及时回到错误配对首次添加到存储库中的时间点。但这意味着让每个使用 repo 的人从“坏旧 repo ”切换到“新的和改进的良好 repo ”。