我正在 Git 中尝试相当激进的自动 gc，主要用于打包目的。在我的回购中，如果git config --list我有设置
...
gc.auto=250
gc.autopacklimit=30
...
如果我这样做，git count-objects -v我会得到
count: 376
size: 1251
in-pack: 2776
packs: 1
size-pack: 2697
prune-packable: 0
garbage: 0
但git gc --auto不会改变这些数字，没有任何东西被打包！由于我超过 gc.auto 限制的 126 个对象，松散的对象不应该被打包吗？
的要点之一gc --auto是它应该非常快，因此其他命令可以经常称其为“以防万一”。为此，仅猜测对象计数。如下git help config所述gc.auto：
当存储库中的松散对象大约超过这么多时 [...]
查看代码 ( too_many_loose_objects()inbuildin/gc.c )，会发生以下情况：
17打开包含所有以开头的对象的文件夹这很好用，因为 SHA-1 是均匀分布的，所以“所有以 X 开头的对象”代表整个集合。但是当然这只适用于大量的对象。懒得做数学，我猜至少> 3000。使用 6700（的默认值gc.auto），这应该已经非常可靠地工作了。
对我来说，核心问题是为什么需要这么低的设置，以及它是否真的在 250 个对象上运行是否重要。设置为 250 时，gc只要您有 2 个以 . 开头的松散对象，就会运行17。发生这种情况的机会是> 80%600 个对象和> 90%800 个对象。
更新：忍不住——不得不做数学:)。我想知道这个估计系统的工作情况如何。这是结果图。对于任何给定的，当回购中有（红色）/ （绿色）/ （橙色）/ （蓝色）/ （紫色）松散对象时开始gc.auto的概率有多高？gcgc.autogc.auto * 1.1gc.auto * 1.2gc.auto * 1.5gc.auto * 2
请注意，gc auto在 Git 2.12.2（两天前发布，2017 年 3 月）中更加健壮。
请参阅David Turner ( )的提交 a831c06（2017 年 2 月 10 日） 。
帮助者：Jeff King ( )。（由Junio C Hamano 合并 -- --在d30ec1b 提交中，2017 年 3 月 21 日）csusbdtpeff
gitster
gc: 忽略旧gc.log文件服务器最终可能会处于存在大量未引用的松散对象的状态（例如，因为许多用户正在执行一堆变基并推送他们的变基分支）。
在这种状态下运行“git gc --auto”会导致gc.log文件被创建，阻止未来的自动 gcs，导致包文件堆积。
由于很多 git 操作都O(n)在包文件的数量中，这会导致性能不佳。Git 永远不应该让自己进入拒绝进行任何维护的状态，因为在某些时候某些维护没有取得进展。
教 Git 忽略
gc.log早于（默认）一天的文件，可以通过gc.logExpiry配置变量进行调整。
这样，如果有必要，这些包文件将每天至少清理一次。发现需要更频繁的 gcs 的操作员可以进行调整gc.logExpiry以满足他们的需求。
注意：由于 Git 2.17（2018 年第二季度），git gc --auto也将在每个版本上运行git commit。
请参阅“导致所有命令的列表git gc --auto”。