concurrent access to multiple local git repos is error prone

> If I have multiple local git repos, and I run `git status -v` on them,
> sometimes I don't get any stdout for the command. This is highly
> reproducible.
>
> I assume that access more than 1 git repo concurrently on a local
> machine is not without errors. However this seems like a huge
> limitation or design flaw.
>
> Is my observation correct? Are there any plans to remove this limitation?
>
> My use case - I create a lot of developer tools and more than once I
> have hit this limitation...I have to create a queue with concurrency
> of 1 to run commands on git repos. It's very strange and
> counterintuitive to have to do this.
>
>
> --
> Alexander D. Mills
> ¡¡¡ New cell phone number: (415)730-1805 !!!
> alexander.d.mills@gmail.com
>
> www.linkedin.com/pub/alexander-mills/b/7a5/418/

>> I assume that access more than 1 git repo concurrently on a local
>> machine is not without errors. However this seems like a huge
>> limitation or design flaw.
>>
>> Is my observation correct? Are there any plans to remove this limitation?

> Yeah as long as git shouldnt fumble wrt concurrent access across repos, it
> was most likely the same repo being accessed concurrently and that's what
> was causing the issue.
>
> that being said, it would be really nice if git itself could handle
> concurrent requests to the same repo, that definitely seems to be a
> limitation.

> Alexander Mills wrote:
>
>> Yeah in this case what appeared to be happening is that if `git status` was
>> called concurrently, frequently I wouldnt get any stdout..
>
> Thanks for reporting.  A few questions:
>
> What platform are you on?  What version of Git are you running?  What
> is the output of "git version --build-options"?
>
> What is the exit status from these "git status" invocations that
> didn't write output?  What options are you passing to "git status"?
> Are there any other interesting symptoms?
>
> Is this part of a larger tool or script?  Are there other operations
> going on (e.g. something sending signals to these git processes)?
>
> Does the repository pass "git fsck"?  Any other symptoms or hints that
> could help in tracking this down?
>
> Can you paste a transcript of the commands or script you ran and what
> output it produced?  Is this something I should be able to reproduce?
>
> Thanks and hope that helps,
> Jonathan

> Also, as an aside, this seems to be a bug, but probably a known bug:
> 
> $ git diff-index  HEAD; echo $?
> 
> :100755 100755 60e5d683c1eb3e61381b1a8ec2db822b94b9faec
> 0000000000000000000000000000000000000000 M      cli/npp_check_merge.sh
> :100644 100644 35a453544de41e2227ab0afab31a396d299139e9
> 0000000000000000000000000000000000000000 M      src/find-projects.ts
> :100644 100644 c1ee7bc18e6604cbf0d16653e9366109d6ac2ec9
> 0000000000000000000000000000000000000000 M      src/tables.ts
> :100644 100644 29d9674fbb48f223f3434179d666b2aa991ad05a
> 0000000000000000000000000000000000000000 M
> src/vcs-helpers/git-helpers.ts
> 0
> 
> $ git diff-index --quiet HEAD; echo $?
> 1
> 
> different exit codes depending on whether --quiet was used. In this
> case, the exit code should be consistent.
> The bug is with the `git diff-index` command, as you can see.

> Alexander Mills wrote:
>
>> Yeah in this case what appeared to be happening is that if `git status` was
>> called concurrently, frequently I wouldnt get any stdout..
>
> Thanks for reporting.  A few questions:
>
> What platform are you on?  What version of Git are you running?  What
> is the output of "git version --build-options"?
>
> What is the exit status from these "git status" invocations that
> didn't write output?  What options are you passing to "git status"?
> Are there any other interesting symptoms?
>
> Is this part of a larger tool or script?  Are there other operations
> going on (e.g. something sending signals to these git processes)?
>
> Does the repository pass "git fsck"?  Any other symptoms or hints that
> could help in tracking this down?
>
> Can you paste a transcript of the commands or script you ran and what
> output it produced?  Is this something I should be able to reproduce?
>
> Thanks and hope that helps,
> Jonathan

> Hi Johnathan,
>
> Yeah this concurrency problem is real. Not only does it happen with
> `git status` the same thing happens with `git rev-parse
> --show-toplevel`.
> What happens is that I get no stdout when repos are accessed
> concurrently (and no stderr). If I limit concurrency to 1, the problem
> goes away. When I up the concurrency, the problem is sporadic, which
> is the exact signal for a concurrency/race-condition related issue.
> The signs are damn clear. I have seen this problem on MacOS I think a
> year back on a different project, but I never reported it b/c I hadn't
> really verified it.
>
> Like I said I am on Ubuntu. I have 3 git repos that are incorporated
> into the tool that's generating the problem. For one repo I got this:
>
> $ git fsck
>
> Checking object directories: 100% (256/256), done.
> dangling tree 4b825dc642cb6eb9a060e54bf8d69288fbee4904
>
> For `$ git version --build-options` I have:
>
> git version 2.17.1
> cpu: x86_64
> no commit associated with this build
> sizeof-long: 8
>
>
> -alex
>
>
>
> On Sun, Aug 5, 2018 at 1:11 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:
>> Alexander Mills wrote:
>>
>>> Yeah in this case what appeared to be happening is that if `git status` was
>>> called concurrently, frequently I wouldnt get any stdout..
>>
>> Thanks for reporting.  A few questions:
>>
>> What platform are you on?  What version of Git are you running?  What
>> is the output of "git version --build-options"?
>>
>> What is the exit status from these "git status" invocations that
>> didn't write output?  What options are you passing to "git status"?
>> Are there any other interesting symptoms?
>>
>> Is this part of a larger tool or script?  Are there other operations
>> going on (e.g. something sending signals to these git processes)?
>>
>> Does the repository pass "git fsck"?  Any other symptoms or hints that
>> could help in tracking this down?
>>
>> Can you paste a transcript of the commands or script you ran and what
>> output it produced?  Is this something I should be able to reproduce?
>>
>> Thanks and hope that helps,
>> Jonathan
>
>
>
> --
> Alexander D. Mills
> ¡¡¡ New cell phone number: (415)730-1805 !!!
> alexander.d.mills@gmail.com
>
> www.linkedin.com/pub/alexander-mills/b/7a5/418/

> What happens is that I get no stdout when repos are accessed
> concurrently (and no stderr). If I limit concurrency to 1, the problem
> goes away. When I up the concurrency, the problem is sporadic, which
> is the exact signal for a concurrency/race-condition related issue.
> The signs are damn clear. I have seen this problem on MacOS I think a
> year back on a different project, but I never reported it b/c I hadn't
> really verified it.
>
> Like I said I am on Ubuntu. I have 3 git repos that are incorporated
> into the tool that's generating the problem. For one repo I got this:
>
> $ git fsck
>
> Checking object directories: 100% (256/256), done.
> dangling tree 4b825dc642cb6eb9a060e54bf8d69288fbee4904
>
> For `$ git version --build-options` I have:
>
> git version 2.17.1
> cpu: x86_64
> no commit associated with this build
> sizeof-long: 8