On Mon, Aug 6, 2018 at 9:38 AM Alexander Mills
wrote:
> Yeah this concurrency problem is real. Not only does it happen with
> `git status` the same thing happens with `git rev-parse
> --show-toplevel`.
"git rev-parse --show-toplevel" having this same problem helps. This
command should never make
(administrivia: please don't top-post)
Hi Alex,
Alexander Mills wrote:
> Yeah this concurrency problem is real. Not only does it happen with
> `git status` the same thing happens with `git rev-parse
> --show-toplevel`.
Sorry for the confusion --- I didn't mean to claim your experience was
not
To add something to the previous message, I have strong evidence that
the problem occurs when *different* repos are accessed concurrency,
not the same repo, as bizarre as that may be.
-alex
On Mon, Aug 6, 2018 at 12:36 AM, Alexander Mills
wrote:
> Hi Johnathan,
>
> Yeah this concurrency problem
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
On 08/05, Alexander Mills wrote:
> Also, as an aside, this seems to be a bug, but probably a known bug:
>
> $ git diff-index HEAD; echo $?
>
> :100755 100755 60e5d683c1eb3e61381b1a8ec2db822b94b9faec
> M cli/npp_check_merge.sh
> :100644 100644
I am on Ubuntu, I will run the checks that you mentioned. I assume
it's operator error for now though. Like I said, it was just `git
status` that was sometimes failing to send any stdout, presumably when
access to a certain git repo was concurrent, but possibly due to
concurrent access across
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
Hi,
Alexander Mills wrote:
> 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
Hi Alexander,
Alexander Mills wrote:
> On Sat, Aug 4, 2018 at 2:47 PM, Alexander Mills
> wrote:
>> 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?
Note, in my first paragraph, I should have said "If I have multiple
local git repos, and I run `git status -v` on them *concurrently*"...
-alex
On Sat, Aug 4, 2018 at 2:47 PM, Alexander Mills
wrote:
> If I have multiple local git repos, and I run `git status -v` on them,
> sometimes I don't get
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
11 matches
Mail list logo