本文最初发布于 DEV CLASS。
Git 计算同一文件不同版本差异的方法存在缺陷，可能会使代码库膨胀数倍，导致性能问题并消耗过多的存储空间。
微软高级工程师 Jonathan Creamer发文 介绍了其团队使用的一个非常大的 JavaScript Git 存储库，一个单体库（一个存储库，存储多个相关的项目）。该库的每月活跃用户数超过 1000 人，代码行数约为 2000 万行。根据 Creamer 的报告，克隆这个存储库消耗了超乎想象的 178GB 磁盘空间。
该团队咨询了 Git 贡献者 Derrick Stolee（曾在 GitHub 工作，现为微软首席软件工程师）。他发现，在比较两个文件名是常用名的文件（本例中为 CHANGELOG.md）时，Git 实际上是在比较来自不同软件包的文件，因此每次提交都会发现很大的差异。
Stolee 向 Git 提交了一个 Pull 请求，添加了他所谓的 “path walk API”，使 Git 能够按路径对对象进行分组，“完全避免了文件名的哈希碰撞”。Creamer 使用新增的-path-walk参数，将git repack命令应用于这个大型存储库，结果库的大小减小到了 5GB。
在 Linux 内核邮件列表上，Stolee 也 发了 关于这个问题的帖子，称 “其主要发现是当前的文件名哈希算法只考虑了路径名的最后 16 个字符，在这样一个范围内自然会发生一些碰撞”。
在另一篇文章中，Stolee 指出：“在我查看的存储库中，按磁盘大小排序的前 100 个文件路径有一个明显的模式：其中 99 个是 CHANGELOG.json 和 CHANGELOG.md 文件...... 本应是一组微不足道的增量，却膨胀到了 20-60MB” 。
Stolee 还举了其他一些存储库的例子，用于说明新选项大大减少了它们所需的存储空间，其中一个存储库占用的存储空间从 130049MB 减少到了 4432MB。
Git 存储库过大的后果不仅是占用过大的磁盘空间，而且还会导致 Git 运行缓慢，有时甚至会完全失败，这取决于延迟和可用带宽。
虽然新选项确实可以显著节省空间，但这些例子都是大型存储库，有很多潜在的文件名冲突。典型的 Git 存储库无法以同样的方式受益。尽管如此，开发者们还是很希望在 Git 的发行版本中看到这些新功能。
https://devclass.com/2024/10/29/microsoft-engineer-describes-a-flaw-in-git-that-can-hugely-bloat-repositories-fix-is-on-the-way/
声明：本文为 InfoQ 翻译，未经许可禁止转载。