停止 git gc --aggressive，这是一件坏事吗？

Question

我正在一个非常大的存储库（apx 100 GB）上运行 git gc --aggressive 。它从两天前的晚上开始运行，几个小时后，它一直卡在：“压缩对象：99％（76496/76777）”

如果我 Ctrl-C 这个过程，有什么后果？我的仓库会无法使用吗？我的直觉告诉我不会，但我想听听一些意见。谢谢！

Answer 1

git 应该永远不会受到这样的干扰。不过，如果您担心，我建议 Ctrl+Z 然后运行 ​​git fsck --full 以确保系统一致。

有许多 git-config 变量可以帮助您的 git-gc 运行得更快。我在一个特定的大型存储库上使用以下内容，但还有更多选项可以随机尝试（或仔细研究，以两者为准）。

git config pack.threads 1
git config pack.deltaCacheSize 1
git config core.packedGitWindowSize 16m
git config core.packedGitLimit 128m
git config pack.windowMemory 512m

仅当您的问题是内存不足时，这些才有帮助。

请注意，Brian J Murray 报告了最佳 (git-gc) 性能，pack.threads 应设置为您拥有的核心数量。另请注意 VonC 的另一个答案，它说您可以通过将 gc.aggressiveDepth 设置为小于默认值 250 的值来权衡 gc 性能和磁盘使用情况。

Answer 2

FWIW，我刚刚通过使用 CTRL+C 中止 git gc 来损坏存储库。 git fsck 现在显示以下错误：

error: HEAD: invalid sha1 pointer [...]
error: refs/heads/master does not point to a valid object!
notice: No default references

并且有很多错误

dangling commit [...]

我不会对此进行调查，但我想指出我将避免中止 git gc< /代码>。

Answer 3

注意：有一个有趣的演变git 2.0（2014 年第 2 季度）：

“git gc --aggressive”学习了“--深度”选项和“gc.aggressiveDepth”配置变量，以允许使用比内置默认值 250 更不疯狂的深度。

这在 提交 125f814，由 Nguyễn Thái Ngọc Duy (pclouds)：

当1c192f3（gc --aggressive）时：让它变得非常激进 - 2007-12-06）将 --depth=250 设置为默认值，它并没有真正解释背后的原因，特别是 --depth 的优缺点=250。

下面一封来自 Linus 的旧邮件详细解释了这一点。
长话短说，--depth=250 是一个磁盘节省者和性能杀手。
并非所有人都同意这种侵略性。
让用户配置它。

这可以帮助避免在大型存储库上运行该命令时遇到的“冻结”问题。