打开网易新闻 查看精彩图片

作者 | Tim Anderson

译者 | 平川

策划 | Tina

本文最初发布于 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 翻译，未经许可禁止转载。

2024 年收官之作：12 月 13 日 -14 日，AICon 全球人工智能开发与应用大会将在北京举办。从 RAG、Agent、多模态模型、AI Native 开发、具身智能，到 AI 智驾、性能优化与资源统筹等大热的 AI 大模型话题，60+ 资深专家共聚一堂，深度剖析相关落地实践案例，共话前沿技术趋势。大会火热报名中，详情可联系票务经理 13269078023 咨询。