Johannes Schindelin <Johannes.Schindelin@xxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html