Re: [PATCH v4 2/4] doc: for-each-ref: say how to read %(worktreepath) safely

[Junio C Hamano <gitster@pobox.com>]

Ben Knoble <ben.knoble@gmail.com> writes:

>>> I was under the impression a branch could not be checked out in
>>> multiple worktrees due to possible races from each worktree performing
>>> updates; or at least, that the porcelain would refuse to create such
>>> worktrees.

Phillip's answer covers everything, but I am not sure if "possible
races" is a good explanation to describe the reason this is
strongly discouraged.

You checkout 'main' in worktree A and worktree B, so their working
tree files and their index files all match what is recorded at the
commit pointed at by 'main'.

You then make changes and commit your changes in worktree A.  The
'main' branch now points at a newly created commit, and the working
tree files and the index in worktree A are in sync with the new
commit (note: unlike the initial state, I am not saying "all match"
in this case, as this commit may have been a partial one.  The
important thing is that from the end-user's perspective who has been
working in worktree A, things are consistent without any unexpected
change).

In the meantime, if worktree B weren't doing anything, its index and
the working tree files have not changed since the beginning.  Yet
because 'main' (hence HEAD) moved, "git status" in worktree B
reports as if it reverted the change made in the updated 'main'.

That would be a grave confusion, and that is what we want to avoid
by forbidding a single branch from being checked out in multiple
worktrees.  But given that worktree B was doing absolutely nothing
while worktree A was doing its own thing, I would not call this a
"race".  It is something else.

Thanks.