Git grep是否存在缺陷 - 禁用并行搜索？

Question

如果我运行git grep命令n次，大约会出现0.8 * n次的错误。

$ git grep foo_bar_search `git rev-list HEAD` -- dir/subdir >/dev/null
fatal: unable to read tree (bc9e3369c6d6f027075e794fa11db02af3f8fb38)
$ git grep foo_bar_search `git rev-list HEAD` -- dir/subdir >/dev/null
fatal: unable to read tree (473a47dd3895b1db09baf4cf9463f4cbd224d5dd)
$ git grep foo_bar_search `git rev-list HEAD` -- dir/subdir >/dev/null
$ git grep foo_bar_search `git rev-list HEAD` -- dir/subdir >/dev/null
fatal: unable to read tree (b917adbfffd1928c8f6ac0f746a4fdfcf2088029)
$ git grep foo_bar_search `git rev-list HEAD` -- dir/subdir >/dev/null
fatal: unable to read tree (473a47dd3895b1db09baf4cf9463f4cbd224d5dd)

我尝试过：

1. 用超级用户运行，排除文件保护的问题
2. git fsck没有报告任何问题,只有一些悬空的对象
3. 克隆存储库，在克隆时没有出现错误，但git grep在克隆中显示相同的行为。
4. 使用git cat-file查看报告的SHA1值，都好像没问题
5. 谷歌了一下

最有趣的谷歌搜索结果是：

http://www.spinics.net/lists/git/msg164520.html

这个消息只有3小时。如果git grep存在竞争条件，那就可以解释一切了。那么他们是在几个核心上并行搜索的吗？（我这里有4个。）我怎样才能禁用它，而不用只开启一个内核重新启动整个机器呢？

$ git --version
git version 1.7.3.4

（这是OpenSUSE 11.4自带的）

- Uwe Geuder

---

（或编译建议的更新，或重新编译定义了NO_PTHREADS的Git。） - Josh Lee

谢谢，NO_PTHREADS听起来很有用。不确定邮件列表上的补丁是否会出现在他们的存储库中（如果有的话）。目前我需要集中精力在工作上，没有打算去处理工具的补丁。 - Uwe Geuder

看起来即将发布的1.7.8版本将包含这个补丁。 - Josh Lee

Answer 1

看起来下列任一条件都会导致在 git-grep 中禁用线程：

• -O 选项用于在分页器中打开匹配文件。
• 在编译时定义了 NO_PTHREADS。
• -p 选项用于显示函数名作为上下文。

希望这些条件中的最后一个不会妨碍您的工作流程。

- Josh Lee

---

感谢您的回答。选项1根本不起作用，-O仅允许搜索工作区。选项2可行。选项3也可行，但有点侵入性（会产生额外的输出，在我的情况下很难解释）。 - Uwe Geuder

Answer 2

如果可以的话，使用建议的补丁编译git似乎可以解决竞争问题。看起来没有办法禁用并行处理。

- holygeek

---

并行化可以在编译时使用Josh Lee提到的-DNO_PTHREADS禁用。我只是通过在源包（git-1.7.3.4）编译时添加此标志来完成它。我没有时间尝试这个补丁。 - Uwe Geuder