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

From: Junio C Hamano <[email-masked]>
Date: Tue, 02 Dec 2014 08:20:53 -0800

Johannes Schindelin <[email-masked]> 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.