git gc - 停止 git gc --侵略性，这是一件坏事

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"

学习了"--depth"选项和"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 是磁盘保护程序和性能杀手.
不是每个人都同意这种侵略性.
让用户配置它。

这可能有助于避免在大型存储库上运行该命令时遇到的"冻结"问题。