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

[Jeff King <peff@peff.net>]

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

> > 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