Is git grep buggy - disable parallel search?

If I run a git grep command n times, I get errors about 0.8 * n times.

$ 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 (b917adbfffd1928c8f6ac0f746a4fdfcf2开发者_如何学运维088029)
$ git grep foo_bar_search `git rev-list HEAD` -- dir/subdir >/dev/null
fatal: unable to read tree (473a47dd3895b1db09baf4cf9463f4cbd224d5dd)

What I've tried

1. run as superuser to exclude any problems with file protections
2. git fsck reports nothing bad just a couple of dangling objects
3. cloned the repo, no errors on cloning, but git grep shows the same behavior in the clone again.
4. look at some of the reported SHA1s using git cat-file, seem to be all fine
5. Googled a bit

The most interesting Google hit was:

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

The message was just 3 hours old. Well, if they have race conditions in git grep, that could explain everything. So do they do search in parallel on several cores? (I have 4 here.) How could I disable that, short of booting the whole machine with only 1 core?

$ git --version
git version 1.7.3.4

(That's what came with OpenSUSE 11.4)

It looks like any of the following conditions will disable threads in git-grep:

• -O is given to open the matching files in a pager.
• NO_PTHREADS is defined at compile time.
• -p is given to show the function name as context.

Hopefully, the last one of these will be unobtrusive to your workflow.

If you can, compiling git with the proposed patch seems to fix the race issue. It seems like there's no way to disable the parallelization.