如何避免“git gc”生成垃圾松散对象？答案

【问题标题】：How to avoid that "git gc" generates garbage loose objects?如何避免“git gc”生成垃圾松散对象？
【发布时间】：2019-08-20 05:54:39
【问题描述】：

在我运行git gc 之前，我有几千个松散的对象：

$ git count-objects -v
count: 3706
size: 17164
in-pack: 147149
packs: 9
size-pack: 46619
prune-packable: 0
garbage: 0
size-garbage: 0

（注意松散对象count 和size）。在git gc 之后我有更多：

$ git count-objects -v
count: 6735
size: 19687
in-pack: 142215
packs: 1
size-pack: 43373
prune-packable: 0
garbage: 0
size-garbage: 0

我知道发生这种情况是因为git gc 在无法访问时将对象从包中逐出；作为松散的物体，它给了它们新的“生命租约”。

如何避免git gc 的这种单一行为发生？我希望保留它的所有其他行为，即所有超时、各种垃圾清除、除此之外的所有行为。

我最多每月运行git gc。出于某种我不知道的原因，git gc --auto 几乎没有运行过（我不想改变它）。

【问题讨论】：

标签： git git-gc

【解决方案1】：

如果您确定当您在该存储库上运行 git gc 时，该存储库中没有运行其他 Git 命令，您可以添加 --prune=all。默认为--prune=2.weeks.ago，这让其他正在运行的命令有 14 天的时间来完成它们的工作；例如，您可以使用--prune=1.day.ago 来减少他们的时间。

您还可以配置gc.pruneExpire：如果未设置，则默认为2.weeks.ago，这就是产生上述默认值的原因。作为j6t notes，gc.pruneExpire 的设置变量是now，而不是all。但是在这里设置now 是不明智的：自动的git gc 将使用此值并且将在后台运行，而其他Git 操作运行。

请注意，如果您的 Git 版本 >= 2.5 但低于 2.15.0，则减少的 gc.pruneExpire 可以在比默认两周更短的时间内破坏您添加的工作树。错误是 git gc 未能使用 HEAD 和添加的工作树的索引作为对象 DAG 的可达性遍历的起点。因此，git gc 可以删除尚未提交的已添加 blob，如果您有一个带有分离 HEAD 的工作树，甚至可以删除一些提交。 最好的解决方法是升级到 2.15.0 或更高版本，因为即使是 2 周的默认值也不一定足够。

【讨论】：

谢谢，就是这样。我将gc.pruneExpire 设置为now，因为all 只是一个无法解析的日期，恰好被解释为now（这可能会在未来的Git 版本中改变）。
对偶然发现这篇文章的读者的一句警告：如果您使用git worktree 和2.15.0 之前的Git，git gc 可能会破坏您的辅助工作树有或没有设置gc.pruneExpire。但是将其设置为now 会让你更加更容易在脚上开枪！
有趣。我打算使用now，但文档说要使用all（！）。这可能是因为将 pruneExpire 设置为 now 是不明智的（请参阅编辑）。是的，添加工作树的 gc-ing 在 2.5 到（但不包括）2.15.0 中中断；我自己也遇到过这个。
pruneExpire 指定时间。有一个discussion recently，当它说all 时，文档至少是不精确的。真的应该是now。