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

Question

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

如果我Ctrl-C过程，有什么后果？我的回购将无法使用吗？我的直觉说不，但我想要一些意见。谢谢！

Answer 1

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

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

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

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

Answer 2

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

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

还有不少

dangling commit [...]

我不打算对此进行调查，但我想指出我要避免 aborting git gc。

Answer 3

注意： git 2.0 (Q2 2014)有一个有趣的演变：

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

这在提交 125f814中有描述，由Nguyễn Thái Ngọc Duy ( pclouds)完成：

当1c192f3 ( gc --aggressive: make it really actuator - 2007-12-06)设为--depth=250默认值时，并没有真正解释背后的原因，尤其是--depth=250.

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

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