是否git grep有bug -禁用并行搜索

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)

What I've try

1. 作为超级用户运行以排除文件保护的任何问题
2. git fsck报告没有什么不好的，只是几个悬空的物体
3. 克隆了repo，克隆没有错误，但是git grep在克隆中再次显示相同的行为
4. 查看一些使用git cat-file的SHA1s报告，似乎都很好
5. 谷歌一下

最有趣的Google搜索结果是:

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

这条消息是3小时前的。如果git grep有竞争条件，那就能解释一切了。他们在几个核心上并行搜索吗?(我这里有4个。)我怎么能禁用它，除了启动整个机器只有一个核心?

$ git --version
git version 1.7.3.4

Answer 1

看起来以下任何一个条件都会禁用git-grep中的线程:

• -O用于打开传呼中的匹配文件。
• NO_PTHREADS是在编译时定义的。
• -p用于显示函数名作为上下文。

希望最后一项不会对您的工作流程造成干扰。

Answer 2

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