了解git gc --auto

Question

我在Git中尝试使用相当激进的auto 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个物体？

Answer 1

gc --auto的一个要点是它应该非常快，所以其他命令可以经常称它为“以防万一”。为此，仅猜测对象计数。正如git help config在gc.auto下所说的那样：

  

当大约超过存储库中的这么多松散对象时，[...]

查看代码（too_many_loose_objects() in buildin/gc.c），接下来会发生什么：

1. gc.auto除以256并向上舍入
2. 包含以17开头的所有对象的文件夹已打开
3. 检查文件夹是否包含的对象多于步骤1的结果

这很好用，因为SHA-1是均匀分布的，所以“以X开头的所有对象”代表整个集合。但是，这当然只适用于大量的物体。懒得做数学，我猜至少会> 3000。使用6700（默认值gc.auto），这应该已经非常可靠。

对我来说，核心问题是为什么你需要这么低的设置，以及它是否真的在250个对象上运行是很重要的。设置为250时，只要有2个以gc开头的松散对象，17就会运行。发生这种情况的可能性为> 80% 600个对象和> 90% 800个对象。

更新：无法帮助它 - 不得不做数学:)。我想知道估算系统的效果如何。这是结果图。对于任何给定的gc.auto，当gc（红色）/ gc.auto（绿色）/ gc.auto * 1.1（橙色）gc.auto * 1.2开始的概率有多高回购中的/ gc.auto * 1.5（蓝色）/ gc.auto * 2（紫色）松散物体？

Answer 2

请注意，gc auto在Git 2.12.2（2017年3月发布，两天前）中更加强大。

commit a831c06见David Turner (csusbdt)（2017年2月10日） 帮助：Jeff King (peff)。
^{（Junio C Hamano -- gitster --于2017年3月21日commit d30ec1b合并）}

  

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上运行。
请参阅“List of all commands that cause git gc --auto”。

还有pre-gc --auto hook associated to that command too。

Answer 3

这对我有帮助：

git config --global gc.auto 0

https://git-scm.com/docs/git-gc/2.6.7