为什么 git 在每次合并时都运行“git gc --auto”？答案

【问题标题】：Why does git run "git gc --auto" on every merge?为什么 git 在每次合并时都运行“git gc --auto”？
【发布时间】：2011-09-12 18:22:51
【问题描述】：

今天，git 开始变得有趣（嗯，比平时更有趣），坚持在每次合并后运行 git gc，即使它们是背靠背的。

C:\Projects\my-current-project>git pull
remote: Counting objects: 31, done.
remote: Compressing objects: 100% (16/16), done.
remote: Total 16 (delta 11), reused 0 (delta 0)
Unpacking objects: 100% (16/16), done.
From git.company.com:git/
   e992ce8..6376211  mybranch/next -> origin/mybranch/next
Merge made by recursive.
Auto packing the repository for optimum performance. You may also run "git gc" manually. See "git help gc" for more information.
FIND: Parameter format not correct
Counting objects: 252732, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (59791/59791), done.
Writing objects: 100% (252732/252732), done.
Total 252732 (delta 190251), reused 252678 (delta 190222)
Removing duplicate objects: 100% (256/256), done.
 .../stylesheets/style.css                          |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

这是令人难以置信的破坏性，我担心这意味着我的存储库以某种方式损坏（这是我第一次自动看到它gc）。我的担心是没有根据的吗？如果我的仓库没问题，如何让自动打包停止？！

【问题讨论】：

确实会发生自动 gc，但通常很少发生。
@asmeurer 问题是每次操作都会发生这种情况...
我知道。但是您似乎对自动gc 会发生感到惊讶，所以我只想指出它确实会发生。
@asmeurer 当时我是一个 git 新手。我的假设是它运行一次 GC，然后它就完成了，不必再做任何事情了。现在我知道得更清楚了（例如，git 在一个稍微不同的自洽现实模型上运行；）
也许我没有正确地传达我的自我。我的垃圾人每周都来我的街上，我每次扔东西他都不会来。同样，GC 应该定期发生，而不是每次我运行 git 命令时。后者正在发生，我很困惑，现在如果发生了，我只会叹息说“哦，混蛋，你太疯狂了。”

标签： git

【解决方案1】：

编辑

我想我发现了问题。

您可能正在 Windows 上运行 Cygwin/git 或 MsysGit。我注意到是因为

FIND: Parameter format not correct

错误信息。问题是你的钩子脚本（或内部的git？！）在某个地方调用find，它没有找到UNIX（GNU）find实用程序，而是找到了Windows（MSDOS...原文如此）FIND.EXE。

您应该能够修复系统范围的路径。如果这不是一个选项，请在脚本中明确指定 PATH 环境变量（或在调用它们之前）

信息的旧答案：

git gc --auto 并不总是导致采取任何行动；你确定这每次都需要时间，还是你只是注意到它被调用了？

如果每次都被调用，你可能会

检查存储库权限（确保它对您完全可写！）
git fsck
git 重新打包
git bundle --create mybundle.git --all 和 git clone mybundle.git 看看你是否能以某种方式“摆脱”罪魁祸首
看看是否可以升级到更高版本
如果一切都失败了，strace 或调试 git-gc 二进制文件

或者，当你摆脱了罪魁祸首时，你也许可以分析你的“清理”回购和当前回购之间有什么不同。

来自the git-gc man-page：

使用这个选项 [--auto]， git gc 检查是否需要任何内务处理；如果没有，它会退出而不执行任何工作。一些 git 命令在执行可能会创建许多松散的操作后运行 git gc --auto 对象。

如果存储库中有太多松散的对象或太多的包，则需要进行内务管理。如果松散对象的数量超过 gc.auto 配置变量的值，则所有松散对象使用 git repack -d -l 组合成一个包。将 gc.auto 的值设置为 0 禁用松散物品的自动打包。

如果包的数量超过 gc.autopacklimit 的值，则现有的包（除了那些标记使用 .keep 文件）通过使用 git repack 的 -A 选项合并为一个包。环境 gc.autopacklimit 为 0 会禁用包的自动合并。

【讨论】：

我没有运行任何钩子脚本（我知道！），所以它必须是内部的 git。 FIND 错误已通过更改我的 PATH 得到修复，但我正在运行手册 git gc 以查看是否可以修复它。
似乎完整的git gc 修复了它。我猜发生了一些事情，导致我的存储库中出现大量垃圾，将其推到远高于“需要 gc”阈值，甚至超过“在一个自动 gc 中做多少”阈值。那件事是什么，我只能猜测（因为有 6 个人定期写信给这个 repo），但现在它已经停止了，所以我实际上可以完成工作。我将根据FIND 的建议接受这个答案，同时让我想到运行一个完整的 gc。
我认为可能导致它的另一件事是某种奇怪的操作（可能是提交前或提交后的钩子），它创建了数千个松散的对象。仅作记录，以防其他人遇到此问题。

【解决方案2】：

我添加了这个答案，即使它没有回答原始发布者的具体问题，因为每次我的一个存储库在每次合并后开始自动打包时，我都忘记了修复，再次搜索它并先找到这个问题。

当我的一个存储库在每次合并后开始“自动打包存储库以获得最佳性能”时，

git gc --prune=now

修复它。（在 Mac 上，我没有 FIND: Parameter format not correct 问题。）现在我使用的是 git 2.4.1，但这对我来说适用于几个 2.* 版本。

This answer 到 How to remove unreferenced blobs from my git repo 建议人们可能需要清除自己的 reflog

git reflog expire --expire-unreachable=now --all

为了最大限度地提高上述命令的效率，但我从来不需要这样做来修复每次合并后的自动打包。

【讨论】：

【解决方案3】：

你使用的是什么版本的 git？无论如何，我发现自动 gcing 极具破坏性。

git config --global gc.auto 0

【讨论】：

这不是一个好主意。它是自动发生的，因为没有人会记得手动运行它，从而导致 git 在 repo 中的速度随着时间的推移而降低，并增加了文件系统的使用率。在正常情况下，这种情况很少发生，所以它不应该具有那么大的破坏性。如果在您执行其他操作时发生这种情况，只需在终端中打开一个新选项卡并从那里继续。
@asmeurer 我同意 Stefan 的观点... crontab -e 与 git gc --aggressive 并且您不再需要记住手动运行它并且可以在非工作时间运行它所以不要不必担心在随机时间被它击中。
当然可以，只要您手动运行它就可以了，答案中从未建议过。
避免中断的正确解决方案不是禁用自动gc（出于上述其他人提到的原因）。相反，使用以下内容创建一个 pre-auto-gc 钩子：echo "Git thinks it's time to run git gc."; exit 1 这样您就会得到及时的提醒，并且只在适合您的时间运行 git gc，而不是随机运行。
+1，因为我不太关心它为什么突然决定每次都运行，而不是我关心它不会破坏我正在尝试的事情。目前，它可以被禁用。性能是没有流量中断的小代价。

【解决方案4】：

您的存储库应该有很多哈希以 17 开头的对象。所以这会触发 git gc --auto。默认为至少 28 个以 17 为前缀的对象。

【讨论】：