# GIT_WORK_TREE is not exported for post-checkout-hook 3 messages from 2026-09-15 to 2026-09-25. Participants: Phil Sainty, Junio C Hamano. Thread: https://gitlist.dev/t/66332 ## Phil Sainty, 2026-09-15 08:24 Subject: GIT_WORK_TREE is not exported for post-checkout-hook Message-ID: <17f331aef833b34fbddbefd66c330465@orcon.net.nz> ``` 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). I have only tested post-checkout-hook, so I do not know if this applies to other hooks as well. [System Info] git version: git version 2.34.1 cpu: x86_64 no commit associated with this build sizeof-long: 8 sizeof-size_t: 8 shell-path: /bin/sh uname: Linux 6.8.0-138-generic #138~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Fri Aug 7 13:43:15 UTC x86_64 compiler info: gnuc: 11.4 libc info: glibc: 2.35 $SHELL (typically, interactive shell): /bin/bash ``` ## Junio C Hamano, 2026-09-16 21:39 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); ``` ## Phil Sainty, 2026-09-25 07:11 Subject: Re: GIT_WORK_TREE is not exported for post-checkout-hook Message-ID: In-Reply-To: ``` Hi Junio, On 2026-09-17 09:39, Junio C Hamano wrote: > The attached patch would export GIT_WORK_TREE when > worktree exists and GIT_DIR would also be exported, Thanks for looking at this. I've just tested your patch and it seems to me that discovery.worktree may not be (or at least may not /always/ be) the right value. With the patch I see the following in my script's environment: GIT_DIR=/path/to/repo/.git/worktrees/name GIT_WORK_TREE='.' Moreover, I see the '.' value regardless of which sub- directory of the worktree I was in at the time. "git rev-parse --show-toplevel" still returns the CWD (which may now be because it's the path for the explicit '.' value?) I can see a few places in setup.c where that value is being set: ./setup.c:510: setenv(GIT_WORK_TREE_ENVIRONMENT, ".", 1); ./setup.c:1213: repo_discovery_set_worktree(discovery, "."); ./setup.c:1269: repo_discovery_set_worktree(discovery, "."); ```