git “自动打包存储库以获得最佳性能”是什么意思？

What does "Auto packing the repository for optimum performance" mean?

提问by Furqan Asghar

I'm having a problem with my git repo. For the last couple of days whenever I do a push to the server I get this message: "Auto packing the repository for optimum performance", and it does not seem to go away and return the shell.

我的 git 存储库有问题。在过去的几天里，每当我推送到服务器时，我都会收到以下消息：“自动打包存储库以获得最佳性能”，并且它似乎并没有消失并返回外壳。

I also tried checking out to a new branch and then doing a rebase on my previous branch and then did git gcto remove the unused history objects and then did a push but still this message appears. Please let me know what's going on with my repo.

我还尝试签出到一个新分支，然后在我之前的分支上进行变基，然后git gc删除未使用的历史对象，然后进行推送，但仍然出现此消息。请让我知道我的回购发生了什么。

回答by Cascabel

Short version: it means what it says, and if you just let it finish, all will be well.

简短版本：它意味着它所说的，如果你让它完成，一切都会好起来的。

During most operations which can potentially increase the number of loose (unpacked) objects in the repository (including pushes), Git invokes git gc --auto. If there are enough loose objects (by default, at least 6700), it will then invoke git repack -d -lto pack them. If there are too many separate packs, it will also repack them into one.

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

A pack is a delta-compressed single file, containing a large number of objects. It's more efficient to store objects in packs, but it takes time to pack (compress) objects, so Git initially creates loose objects, then packs them in batches now and then, via automatic invocation of git gc --auto.

包是增量压缩的单个文件，包含大量对象。将对象存储在包中更有效，但打包（压缩）对象需要时间，因此 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.

如果你让 Git 完成重新打包，这种情况在一段时间内不会再次发生。这确实需要一段时间，特别是如果您有很多大型二进制对象，但如果它正在触发，则表明它可能会大大减少 repo 占用的磁盘空间量。如果您真的不希望它发生，则可以更改 config 参数gc.auto。如果将其增加到比 6700 大得多的值，它发生的频率会降低，但发生时需要更长的时间。如果你减少它，它仍然需要做你当前的重新打包，但随后它会更频繁地发生并且完成得更快。如果将其设置为 0，它将禁用自动重新打包。

See man git-gc(under --auto) and man git-config(under gc.auto) for more information.

有关更多信息，请参阅man git-gc（下--auto）和man git-config（下gc.auto）。

回答by wbharding

While Jefroni is correct that sometimes the auto-packing just needs time to complete, if the auto-packing message persists over multiple days as OP describes, there's a good chance that git's cleanup is missing dangling objects, as described in this question.

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

To see whether dangling objects are triggering ongoing messages about auto-packing, try running git fsck. If you get a long list of dangling commits, you can clean them with

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

git gc --prune=now

git gc --prune=now

I usually have to run this on my repo every 2-3 months when the auto-packing message doesn't go away after a single pull.

当自动打包消息在一次拉动后不会消失时，我通常必须每 2-3 个月在我的 repo 上运行一次。

回答by Anders Lindén

To disable for one project:

为一个项目禁用：

cd your_project_dir
git config gc.auto 0

To disable globally:

要全局禁用：

git config --global gc.auto 0

回答by Rudi

Git is running git-repack, which packs many objects(=files, commits and trees) into one pack file. Git does this sometimes, when a heuristic says that there can be space saved (a pack file contains compressed object deltas, while each file in the objects/ directory contains the compressed full file content)

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

回答by VonC

Hopefully, that git gc --autostep is now (git 2.0.1, June 25th, 2014) more efficient.
See commit 62aad18by Nguy?n Thái Ng?c Duy (pclouds)

希望这git gc --auto一步现在（git 2.0.1，2014 年 6 月 25 日）更有效。
见提交62aad18通过Nguy 2 N泰伍2 C维战（pclouds）

gc --auto: do not lock refs in the background

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 --autois 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-refsand "reflog --prune" in foreground to stop parallel ref updates. The remaining background operations (repack, prune and rerere) should not impact running git processes.

9f673f9（gc：用于在后台运行 --auto 的配置选项 - 2014-02-08，Git 2.0.0）将“ gc --auto”置于后台以减少用户的等待时间。
垃圾收集的一部分是打包引用和修剪引用日志。这些需要锁定一些引用，并且可能会中止试图锁定同一个引用的其他进程。

如果gc --auto在脚本中间触发，gc 在后台持有锁可能会使脚本失败，这在9f673f9之前永远不会发生。

继续运行pack-refs并reflog --prune在前台运行“ ”以停止并行引用更新。剩余的后台操作（repack、prune 和 rerere）不应影响正在运行的 git 进程。

And Git 2.22 (Q2 2019) further optimize git gc.

并且 Git 2.22（2019 年第二季度）进一步优化了git gc.