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

Why does git run "git gc --auto" on every merge?

提问by Mike Caron

Today, git started acting funny (well, funnier than usual) by insisting on running git gcafter every single merge, even if they are back to back.

今天，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(-)

This is incredibly disruptive, and I fear that it means that my repository is corrupt somehow (this is the first time I've ever seen it automatically gc). Are my fears unfounded? If my repository is OK, how do I make the auto-packing stop?!

这非常具有破坏性，我担心这意味着我的存储库以某种方式损坏了（这是我第一次自动看到它gc）。我的恐惧是没有根据的？如果我的存储库没问题，我该如何停止自动打包？！

采纳答案by sehe

EDIT

编辑

I think I spotted the problem.

我想我发现了问题。

You are probably running Cygwin/git or MsysGit on Windows. I noticed that because of the

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

FIND: Parameter format not correct

error message. The trouble is that somewhere your hook scripts (or git internally?!) is calling find, which does not find the UNIX (GNU) find utility but rather finds the Windows (MSDOS... sic) FIND.EXE.

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

You should be able to fix your system wide path. If that is not an option, explicitely specify the PATH environment variable inside your script (or before invoking them)

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

---

---

Old answer for information:

信息的旧答案：

git gc --autodoes not always result in any action taken; are you sure this is taking time every time, or did you just notice it is being called?

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

If it is being called every time, you might

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

• check repository permissions (make sure it is fully writable to you!)
• git fsck
• git repack
• git bundle --create mybundle.git --alland git clone mybundle.gitto see whether somehow you can 'shake' the culprit
• see whether you can upgrade to a later version
• if all else fails, strace or debug the git-gc binary

• 检查存储库权限（确保它对您完全可写！）
• git fsck
• git重新打包
• git bundle --create mybundle.git --all并且git clone mybundle.git，看是否在某种程度上可以“摇”的罪魁祸首
• 看看能不能升级到更高版本
• 如果所有其他方法都失败，请跟踪或调试 git-gc 二进制文件

Optionally, when you have shaken the culprit, you maybe able to analyze what is different between your 'cleaned' repo and the current one.

或者，当你动摇了罪魁祸首时，你也许能够分析你的“清理过的”repo 和当前的 repo 之间有什么不同。

From the git-gc man-page:

从git-gc 手册页：

With this option [--auto], git gc checks whether any housekeeping is required; if not, it exits without performing any work. Some git commands run git gc --auto after performing operations that could create many loose objects.

Housekeeping is required if there are too many loose objects or too many packs in the repository. If the number of loose objects exceeds the value of the gc.auto configuration variable, then all loose objects are combined into a single pack using git repack -d -l. Setting the value of gc.auto to 0 disables automatic packing of loose objects.

If the number of packs exceeds the value of gc.autopacklimit, then existing packs (except those marked with a .keep file) are consolidated into a single pack by using the -A option of git repack. Setting gc.autopacklimit to 0 disables automatic consolidation of packs.

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

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

如果包的数量超过 gc.autopacklimit 的值，则使用 git repack 的 -A 选项将现有包（标有 .keep 文件的包除外）合并为一个包。将 gc.autopacklimit 设置为 0 会禁用包的自动合并。

回答by Dave Schweisguth

I'm adding this answer even though it doesn't answer the original poster's specific problem because every time one of my repos starts auto-packing after every merge I've forgotten the fix, search for it again and find this question first.

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

When one of my repos starts "Auto packing the repository for optimum performance" after every merge,

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

git gc --prune=now

fixes it. (Being on a Mac, I don't have the FIND: Parameter format not correctproblem.) Right now I'm using git 2.4.1, but this has worked for me for several 2.* versions.

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

This answerto How to remove unreferenced blobs from my git reposuggests that one might need to clear one's reflog with

这个答案要如何从我的混帐回购协议中删除未引用斑点表明，人们可能需要用一个明确的引用日志

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

for the above command to be maximally effective, but I've never needed to do that to fix auto-packing after every merge.

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

回答by Stefan Kendall

What version of git are you using? Regardless, I find automatic gcing extremely disruptive.

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

git config --global gc.auto 0

git config --global gc.auto 0

回答by linquize

Your repository should have a lot of objects that the hashes start with 17. So this triggers git gc --auto. Default is at least 28 objects prefixed 17.

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