Re: GIT_WORK_TREE is not exported for post-checkout-hook
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Sep 16, 2026, 21:39 UTC
- Message-ID
- <xmqqqzisvpsq.fsf@gitster.g>
- In-Reply-To
- <17f331aef833b34fbddbefd66c330465@orcon.net.nz>
Phil Sainty <psainty@orcon.net.nz> writes:
Show 39 quoted lines
> 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);