On Thu, 21 Feb 2019 04:27:21 -0500
Eric Sunshine [off-list ref] wrote:

On Wed, Feb 20, 2019 at 1:35 PM Eric Sunshine [off-list ref] wrote:

quoted

On Wed, Feb 20, 2019 at 12:16 PM Michal Suchánek [off-list ref] wrote:  

quoted

On Wed, 20 Feb 2019 11:55:46 -0500
Eric Sunshine [off-list ref] wrote:  

quoted

On Wed, Feb 20, 2019 at 11:17 AM Michal Suchanek [off-list ref] wrote:  

quoted

Another even rarer issue is that the file might be zero size because another
process initializing a worktree opened the file but has not written is content
yet.  

Based upon the explanation thus far, I'm having trouble understanding
under what circumstances these race conditions can arise. Are you
trying to invoke Git commands in a particular worktree even as the
worktree itself is being created?  

It's explained in the following paragraph. If you have multiple
worktrees some *other* worktreee may be uninitialized.  

I understand that, but setup.c:get_common_dir_noenv() is concerned
only with _this_ worktree -- the one in which the Git command is being
run -- so it's not clear if or how some other partially-initialized
worktree could have any impact. (And, I'm having trouble fathoming how
it could, which is why I'm asking these questions).  

I still can't see how setup.c:get_common_dir_noenv() could be
responsible for the behavior you're describing of _any_ Git command
erroring out due to _any_ worktree being incompletely-initialized.
However, I can imagine "git worktree add" itself being racy and
failing due to a missing or empty "commondir" file for some other
worktree since that command _does_ consult other worktree entries when
validating the "add" operation via
builtin/worktree.c:validate_worktree_add() which calls
get_worktrees(). If get_worktrees() is subject to that raciness
problem, then "git worktree add" will inherit that undesirable
raciness behavior (as will other "git worktree" commands which call
get_worktrees(), such as "git worktree list").

quoted

Is it possible that when you saw that error message, it actually arose
from some code other than setup.c:get_common_dir_noenv()?  

So, I'm suspecting get_worktrincludes both itees() or some function it calls (and so
on) as the racy culprit.

Yes, that's my explanation for the situation as well.

Thanks

Michal