为什么git会运行；git gc——自动；每次合并？

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

）。我的担心是没有根据的吗？如果我的存储库正常，如何停止自动打包

您使用的是什么版本的git？不管怎样，我发现自动

gc

ing极具破坏性

git config--global gc.auto 0

编辑

我想我发现了问题所在

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

FIND: Parameter format not correct

错误消息。问题是，钩子脚本（或git内部？！）在某处调用find，它找不到UNIX（GNU）find实用程序，而是找到Windows（MSDOS…sic）find.EXE

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

---

旧答案供参考：

git-gc--auto

并不总是导致采取任何行动；你确定每次都要花时间，还是你刚刚注意到它被调用了

如果每次都有人打电话，你可能会

• 检查存储库权限（确保它对您完全可写！）
• 吉特fsck
• git重新包装

• git bundle--create mybundle.git--all

  和

  git clone mybundle.git

  看看你是否能以某种方式“动摇”罪犯
• 查看是否可以升级到更高版本
• 如果所有其他操作都失败，则检查或调试git gc二进制文件

或者，当你摇动了罪魁祸首，你也许能够分析你的“清理”回购和当前回购之间的区别

发件人： 使用此选项[--auto]，git gc检查是否需要任何内务管理；如果不是，它将不执行任何操作而退出 任何工作。一些git命令在执行可能会创建许多松散的代码的操作后运行git-gc--auto 对象

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

如果包的数量超过gc.autopacklimit的值，则现有包（标记的包除外 通过使用git repack的-a选项，可以将这些文件合并到单个包中。背景 gc.autopacklimit为0将禁用包的自动合并

---

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

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

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

git gc --prune=now

修复它。（在Mac电脑上，我没有

FIND:Parameter format not correct

问题。）现在我使用的是git 2.4.1，但这对我来说已经有好几个2.*版本了

表示可能需要用

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

---

为了使上面的命令发挥最大的效果，但我从来都不需要这样做来修复每次合并后的自动打包。

我没有运行任何钩子脚本（我知道！），所以它在内部必须是git。查找错误是通过更改路径修复的，但是我正在运行一个手动的

git-gc

来查看是否修复了它。似乎完整的

git-gc

修复了它。我猜发生了一些事情，在我的存储库中造成了大量垃圾，使其远远超过了“需要gc”阈值，甚至超过了“在一个自动gc中要做多少”阈值。那个事件是什么，我只能猜测（因为有6个人定期写信给回购协议），但现在已经停止了，所以我可以真正完成工作。基于

FIND

的建议，我将接受这个答案，并让我考虑运行一个完整的gc。我认为另一个可能导致它的原因是某种奇怪的操作（可能是提交前或提交后的钩子），它创建了数千个松散的对象。只是为了记录在案，以防其他人有这个问题。自动gc确实发生过，但通常很少发生。@asmuer的问题是它发生在每个操作上……我知道。但是你似乎很惊讶自动

gc

会发生，所以我只想指出它确实发生了。@asmurer我当时是git新手。我的假设是，它只运行一次GC，然后就完成了，不需要再运行了。现在我更清楚了（例如，git运行在一个稍微不同的自我一致的现实模型上；）也许我没有正确地表达我的自我。我的垃圾工每周都到我的街上来，不是每次我扔掉一件东西他都来。类似地，GC应该定期发生，而不是每次我运行git命令时。后一种情况正在发生，我很困惑，现在如果真的发生了，我会叹口气说“哦，天哪，你真是疯了。”这不是个好主意。这是自动发生的，因为没有人会记得手动运行它，这导致在repo中git的速度随着时间的推移而降低，并增加了文件系统的使用率。这种情况在正常情况下很少发生，所以不应该有那么大的破坏性。如果在您执行其他操作时发生这种情况，只需在终端中打开一个新选项卡，然后从那里继续。@asmeu