From: Junio C Hamano Date: Wed, 16 Sep 2026 21:39:49 GMT Subject: Re: GIT_WORK_TREE is not exported for post-checkout-hook Message-ID: In-Reply-To: <17f331aef833b34fbddbefd66c330465@orcon.net.nz> Phil Sainty writes: > I have a post-checkout-hook shell script which indirectly calls > "git rev-parse --show-toplevel", and I've found that when that hook > runs for a checkout within a worktree directory, GIT_DIR is set but > GIT_WORK_TREE is not set, which leads to the CWD being returned > instead of the genuine toplevel value. > > The script is seeing a GIT_DIR value like this: > > GIT_DIR=/path/to/repo/.git/worktrees/name > > The only other git variables in the environment are GIT_EXEC_PATH > and GIT_PREFIX. > > The outcome I'm seeing is explained by > https://git-scm.com/book/en/v2/Git-Internals-Environment-Variables#_repository_locations > which says: > > "If --git-dir or GIT_DIR is specified but none of --work-tree, > GIT_WORK_TREE or core.worktree is specified, the current working > directory is regarded as the top level of your working tree." > > The current githooks(5) man page talks about this somewhat: > > "Environment variables, such as GIT_DIR, GIT_WORK_TREE, etc., are > exported so that Git commands run by the hook can correctly locate > the repository. If your hook needs to invoke Git commands in a > foreign repository or in a different working tree of the same > repository, then it should clear these environment variables so > they do not interfere with Git operations at the foreign > location." > > Unsetting GIT_DIR certainly fixes the problem, but I don't think that > ought to be necessary in my case, as my hook script is calling git in > the *same* working copy where the checkout happens. It is not dealing > with "a foreign" repository [or] a different working tree". > > My impression is that GIT_WORK_TREE should also be set for this hook > when dealing with a worktree. I have tested this in git version 2.34 > and 2.55 (maint) and also 2.56.0.rc0.355.g945ea7012d (next). That certainly would be a possible workaround. I do not know why we need to export GIT_DIR in the first place, though. The attached patch would export GIT_WORK_TREE when worktree exists and GIT_DIR would also be exported, but there is a large NEEDSWORK comment in the precontext of the hunk, which merits consideration before moving forward. setup.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git c/setup.c w/setup.c index 0d157ac254..d0c0b2f68a 100644 --- c/setup.c +++ w/setup.c @@ -2064,8 +2064,11 @@ const char *setup_git_directory_gently(struct repository *repo, int *nongit_ok) startup_info->have_repository || /* GIT_DIR_EXPLICIT */ getenv(GIT_DIR_ENVIRONMENT)) { - if (discovery.worktree) + if (discovery.worktree) { set_git_work_tree(repo, discovery.worktree); + if (discovery.gitdir || getenv(GIT_DIR_ENVIRONMENT)) + xsetenv(GIT_WORK_TREE_ENVIRONMENT, discovery.worktree, 1); + } if (discovery.gitdir) { apply_and_export_relative_gitdir(repo, discovery.gitdir, 0);