Re: Inconsistent results from git rev-parse --show-toplevel

On Sat, Jan 25, 2020 at 10:22:45PM +0000, Crabtree, Andrew wrote:

quoted

But the bigger thing, I think, is: who is setting GIT_DIR but not setting GIT_WORK_TREE to match? Because IMHO that's the situation that is causing the confusion.

Pre-commit hook when worktrees are used? 

pre-commit
#!/bin/bash
env | grep GIT

/tmp/pre_commit_test_worktree  (new_branch)$ git add frob
/tmp/pre_commit_test_worktree  (new_branch)$ git commit -m "frob"
GIT_DIR=/tmp/pre_commit_test/.git/worktrees/pre_commit_test_worktree
GIT_EDITOR=:
GIT_INDEX_FILE=/tmp/pre_commit_test/.git/worktrees/pre_commit_test_worktree/index
GIT_PREFIX=
GIT_AUTHOR_DATE=@1579990789 -0800
GIT_AUTHOR_NAME=Andrew Crabtree
GIT_EXEC_PATH=/usr/local/libexec/git-core
GIT_AUTHOR_EMAIL=andrew.crabtree@hpe.com
[new_branch 7b1b747] frob
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 frob

I dug into this a little bit. I think the culprit is actually that our
internal set_git_dir() puts GIT_DIR into the environment, but the
matching setup_work_tree() doesn't touch GIT_WORK_TREE unless it's
already set.

This is mostly fine because we chdir() to the top-level of the working
tree, meaning that any sub-processes would see the correct environment.
But if we execute some arbitrary script (like a hook) that does a chdir,
the results are surprising.

Something like this seems like it would be an improvement:

diff --git a/setup.c b/setup.c
index e2a479a64f..75e2d1393c 100644
--- a/setup.c
+++ b/setup.c

@@ -394,12 +394,7 @@ void setup_work_tree(void)
 	if (!work_tree || chdir_notify(work_tree))
 		die(_("this operation must be run in a work tree"));
 
-	/*
-	 * Make sure subsequent git processes find correct worktree
-	 * if $GIT_WORK_TREE is set relative
-	 */
-	if (getenv(GIT_WORK_TREE_ENVIRONMENT))
-		setenv(GIT_WORK_TREE_ENVIRONMENT, ".", 1);
+	setenv(GIT_WORK_TREE_ENVIRONMENT, work_tree, 1);
 
 	initialized = 1;
 }

but it fails a test in t5601 around git-clone. So there may be some
weird subtle interaction here (or possibly just a bug in git-clone, if
it isn't careful enough to clean its environment when moving into the
newly created repo).

-Peff