Re: [PATCH v5] Add another option for receive.denyCurrentBranch

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
>>> This is because you know receive-pack runs inside the $GIT_DIR,
>>> whether it is a bare or non-bare repository, so either core.worktree
>>> points at a directory that is otherwise unrelated to the $GIT_DIR
>>> (but is the correct $GIT_WORK_TREE), or the top of the working tree
>>> must be ".." for a non-bare repository....
>
> And this reasoning may be broken, unfortunately.
>
> In a repository with separate-git-dir, we enter $GIT_DIR that is
> pointed by the "gitdir: $over_there" thing, and once we go there,
> we have no linkage back to find where the working tree is unless
> there is core.worktree set, do we?
>
> This feature (with or without the push-to-checkout hook, as that
> shares exactly the same logic that discovers, or fails to do so,
> where the working tree is) needs to be documented with an entry in
> the BUGS section, saying that it will not work in a repository that
> is tied to its working tree via the "gitdir:" mechanism.
>
> It actually is a lot worse than merely "it will not work", when this
> problem ever manifests itself.  The use of this mechanism in such a
> repository will destroy the contents of a wrong directory that
> happens to be the parent directory of a repository pointed by the
> "gitdir:" mechanism, unless core.worktree is set.  Fortunately, real
> submodule directories found in the ".git/modules/" directory of the
> superproject, even though they are bound to their checkout locations
> in the working tree of the superproject using "gitdir:" mechanism,
> do maintain their core.worktree when "git submodule" manages them,
> so the use of the mechanism in submodule setting may be safe.