performance - 提高 git status 性能的方法

Question

我在 NFS 上的 Linux 机器上有一个 10 GB 的存储库。第一次 git status 需要 36 分钟，随后的 git status 需要 8 分钟。似乎 Git 依赖于操作系统来缓存文件。只有第一个 git 命令，如 commit、status 涉及打包/重新打包整个 repo，对于一个巨大的 repo 来说需要很长时间。我不确定您是否在如此大的存储库上使用过 git status，但是有人遇到过这个问题吗？

我已经尝试过git gc、git clean、git repack，但所花费的时间仍然/几乎相同。

子模块或任何其他概念(例如将存储库分解成更小的模块)会有帮助吗？如果是这样，哪个最适合拆分更大的 repo 协议(protocol)。有没有其他方法可以缩短大型存储库上 git 命令所花费的时间？

Answer 1

更准确地说，git 取决于 lstat(2) 系统调用的效率，因此调整您客户端的 “attribute cache timeout”可能会成功。

git-update-index 的手册——本质上是 git-status 的手动模式——描述了你可以做些什么来缓解这个问题，作者 using the --assume-unchanged flag抑制其正常行为并手动更新您已更改的路径。您甚至可以对编辑器进行编程，使其在每次保存文件时取消设置此标志。

如您所建议的，另一种方法是减小 checkout 的大小(包文件的大小在这里并没有真正发挥作用)。选项是稀疏 checkout 、子模块或 Google 的 repo工具。

(有一个邮件列表 thread about using Git with NFS ，但它没有回答很多问题。)