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

【问题标题】：What does "Auto packing the repository for optimum performance" mean?“自动打包存储库以获得最佳性能”是什么意思？
【发布时间】：2012-01-27 20:55:11
【问题描述】：

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

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

【问题讨论】：

git config gc.autoDetach 将禁用此行为。

标签： git git-rebase git-push

【解决方案1】：

短版：意思是它所说的，如果你让它完成，一切都会好起来的。

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

一个包是一个增量压缩的单个文件，包含大量对象。将对象存储在包中效率更高，但打包（压缩）对象需要时间，因此 Git 最初会创建松散对象，然后通过自动调用 git gc --auto 不时将它们打包。

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

请参阅man git-gc（--auto）和man git-config（gc.auto）了解更多信息。

【讨论】：

确实，这对我来说花了大约 5 分钟，但它确实完成了。很好的答案。
我们看到每次推送都会发生这种情况（持续几秒钟，呵呵）。
@dpk：这在正常情况下不应该发生 - 单次推送中的对象数量不应大到足以触发它（除非您的存储库巨大和/或者你正在推动大量提交），所以一旦它成功完成（你让它完成，对吗？）它不应该再次发生，直到你建立它。如果您无法弄清楚，请提出一个单独的问题。
“如果你让 Git 完成”，它可以...fatal: Out of memory, malloc failed (tried to allocate 79610689 bytes) error: failed to run repack——这就是我将整个代码库粘贴到一个 git 存储库中的结果。猜猜我要杀死应用程序并“手动”强制重新打包
我每次执行 git pull 时都会得到它。我已经手动完成了 git gc，但每次拉动时它仍然会发生。很奇怪。

【解决方案2】：

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

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

清理它们

git gc --prune=now

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

【讨论】：

虽然不是公认的答案，但这正是我所需要的。几天内，我每次执行git pull 时都会收到消息，而fsck 确实显示了大量悬空提交。
引用经典：就是这样
仅供参考 - 要让git gc --prune=now 工作，请确保所有 IDE、Git bash 和 Git UI 程序都已关闭。否则，它将无法工作，因为资源/文件被“锁定”。当我忘记关闭我的 GitKraken 工具时发生在我身上。

【解决方案3】：

为一个项目禁用：

cd your_project_dir
git config gc.auto 0

全局禁用：

git config --global gc.auto 0

【讨论】：

我想我找到了方法：转到 .git 文件夹，打开配置文件，删除文本“auto = 0”，然后保存。这似乎重新启用了自动打包。
git config --unset gc.auto

【解决方案4】：

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

【讨论】：

【解决方案5】：

希望git gc --auto 步骤现在（git 2.0.1，2014 年 6 月 25 日）更有效率。
见commit 62aad18 Nguyễn Thái Ngọc Duy (pclouds)

`gc --auto`: 不要在后台锁定 refs

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

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

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

还有 Git 2.22（2019 年第二季度）further optimize git gc。

【讨论】：

gc --auto: 不要在后台锁定 refs

`gc --auto`: 不要在后台锁定 refs