如何避免这种情况；git gc“；生成垃圾松散对象？

在运行

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

（注意松散的物体

计数

和

大小

）。在

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-gc

时确定该存储库中没有运行其他git命令，则可以添加

--prune=all

。默认值为

--prune=2.weeks.ago

，这使其他正在运行的命令有14天的时间来完成其工作；例如，您可以使用

--prune=1.day.ago

来缩短时间

您还可以配置

gc.prueexpire

：如果未设置，则默认为

2.weeks.ago

，这就是产生上述默认值的原因。正如前面所说，这个设置变量的

gc.prueexpire

设置变量是

now

，而不是

all

。现在在这里设置

是不明智的：自动
git gc
将使用此值并在后台运行，而其他git操作将运行

请注意，如果您的Git>=2.5但低于2.15.0，则减少的
gc.pruneExpire
可以在少于默认两周的时间内中断添加的工作树。错误在于，
git gc
未能使用添加的工作树的
头和索引作为对象DAG的可达性遍历的起点。因此，
git gc
可以删除添加的尚未提交的blob，如果您有一个具有分离头的工作树，甚至可以删除一些提交。最好的解决办法是升级到2.15.0或更高版本，因为即使是2周的默认值也不一定足够。
谢谢，就这样。我将
gc.pruneExpire
设置为
now
，因为
all
只是一个不可解析的日期，恰好被解释为
now
（这可能会在未来的Git版本中发生变化）。对于在这篇文章中跌跌撞撞的读者，我要提醒一句：如果您使用的是
Git worktree
和2.15.0之前的Git，
git-gc
可以在设置或不设置
gc.prueexpire
的情况下破坏辅助工作树。但是现在将其设置为
，
会更容易击中自己的脚！有趣。我本来打算现在使用
，但文档中说要使用
all
（！）。这可能是因为将
prueexpire
设置为
now
是不明智的（请参见编辑）。是的，在2.5到（但不包括）2.15.0中添加worktrees的gc中断；我自己也遇到过这个问题。
prueexpire
指定了一个时间。有一种观点认为，文档中的
all
至少是不精确的。现在应该是
了
。