简而言之:它就是它所说的，如果你让它结束，一切都会好起来的。

在大多数可能会增加存储库中松散(解包)对象数量的操作(包括push)期间，Git调用Git gc——auto。如果有足够的松散对象(默认情况下，至少6700个)，它将调用git repack -d -l来打包它们。如果有太多单独的包装，它也会重新包装成一个。

包是一个delta压缩的单一文件，包含大量的对象。将对象存储在包中更有效，但打包(压缩)对象需要时间，因此Git最初创建松散对象，然后通过自动调用Git gc—auto将它们批量打包。

If you let Git finish repacking, this won't happen again for a while. It can indeed take a while, especially if you have a lot of large binary objects, but if it's triggering, then it's a sign that it will probably drastically reduce the amount of disk space taken by the repo. If you really don't want it to happen, you can change the config parameter gc.auto. If you increase it to something much larger than 6700, it will happen less frequently, but take longer when it does. If you decrease it, it'll still have to do your current repack, but subsequently it will happen more often and finish more quickly. If you set it to 0, it will disable automatic repacking.

更多信息请参见man git-gc(在——auto下)和man git-config(在gc.auto下)。

Git正在运行Git -repack，它将许多对象(=files，提交和树)打包到一个包文件中。Git有时会这样做，当启发式提示可以节省空间时(包文件包含压缩的对象增量，而objects/目录中的每个文件包含压缩的完整文件内容)

希望git gc -auto步骤现在(git 2.0.1, 2014年6月25日)更有效。 参见commit 62aad18 by nguyfrecn Thái ngibmc Duy (pclouds)

Gc——auto:不锁定背景中的引用

9f673f9 (gc: config option for running --auto in background - 2014-02-08, Git 2.0.0) puts "gc --auto" in background to reduce user's wait time. Part of the garbage collecting is pack-refs and pruning reflogs. These require locking some refs and may abort other processes trying to lock the same ref. If gc --auto is fired in the middle of a script, gc's holding locks in the background could fail the script, which could never happen before 9f673f9. Keep running pack-refs and "reflog --prune" in foreground to stop parallel ref updates. The remaining background operations (repack, prune and rerere) should not impact running git processes.

而Git 2.22 (Q2 2019)进一步优化了Git gc。

简而言之:它就是它所说的，如果你让它结束，一切都会好起来的。

在大多数可能会增加存储库中松散(解包)对象数量的操作(包括push)期间，Git调用Git gc——auto。如果有足够的松散对象(默认情况下，至少6700个)，它将调用git repack -d -l来打包它们。如果有太多单独的包装，它也会重新包装成一个。

包是一个delta压缩的单一文件，包含大量的对象。将对象存储在包中更有效，但打包(压缩)对象需要时间，因此Git最初创建松散对象，然后通过自动调用Git gc—auto将它们批量打包。

If you let Git finish repacking, this won't happen again for a while. It can indeed take a while, especially if you have a lot of large binary objects, but if it's triggering, then it's a sign that it will probably drastically reduce the amount of disk space taken by the repo. If you really don't want it to happen, you can change the config parameter gc.auto. If you increase it to something much larger than 6700, it will happen less frequently, but take longer when it does. If you decrease it, it'll still have to do your current repack, but subsequently it will happen more often and finish more quickly. If you set it to 0, it will disable automatic repacking.

更多信息请参见man git-gc(在——auto下)和man git-config(在gc.auto下)。

禁用一个项目:

cd your_project_dir
git config gc.auto 0

全局禁用:

git config --global gc.auto 0

虽然Jefroni是正确的，有时自动打包只需要时间来完成，但如果自动打包消息像OP所描述的那样持续了好几天，那么git的清理很有可能丢失了悬空对象，就像这个问题中描述的那样。

要查看悬空对象是否触发有关自动打包的持续消息，请尝试运行git fsck。如果你得到一个很长的悬垂提交列表，你可以用

git gc --prune=now

我通常必须每隔2-3个月在我的回购中运行一次，因为自动打包消息在一次拉取后没有消失。