Re: [Outreachy] GIT_DIR inherited by shell aliases in linked worktrees

From: Priestess <herroyalpriestess@gmail.com>
Date: Nov 2, 2026, 15:44 UTC
Message-ID: <CAOcE0wLn5tU6Ok90EhPfyQ0f_atkaFPQyWFLh7JovRGjZ9aZAQ@mail.gmail.com>
In-Reply-To: <CAKUOgLzP0CSwOwLeoSpM94A+XCT2X_cVojHsLugDfw+tBZk9LQ@mail.gmail.com>

On Fri, Oct 30, 2026 at 2:40 PM Immaculate Mecha <immaculatemecha87@gmail.com> wrote:

Show 31 quoted lines

>
> I'm considering a small Outreachy contribution around repository
> environment handling in external shell aliases.
>
> I reproduced the following behaviour:
>
> Create a repository with a linked worktree.
>
> Run an external shell alias from inside that worktree.
>
> Have the alias execute git -C ../TestBaseRepo rev-parse.
>
> The nested command reports the calling worktree's Git directory and
> common directory, even though --show-toplevel correctly identifies
> TestBaseRepo.
>
> I traced this to the inherited GIT_DIR variable. Unsetting GIT_DIR
> before running the nested command makes all three results point to the
> target repository.
>
> I found the earlier 2020 discussion about GIT_DIR inheritance in
> aliases, but I'm interested in whether there is still room for a
> focused contribution, particularly around regression tests for linked
> worktrees.
>
> Would this be a suitable microproject for Outreachy?
>
> Thank you,
>
> Immaculate Mecha
>

Hi Immaculate,

I reproduced this on git 2.56.GIT. From inside a linked worktree, an alias running `git -C <unrelated-repo> rev-parse --git-dir --git-common-dir --show-toplevel` printed the worktree's git dir and common dir, but a toplevel of the target. Running the same command with `env -u GIT_DIR` gave the target repo for all three, so the inherited GIT_DIR is the cause.

Note that with the main repo as the target, --git-common-dir looks correct either way, so an unrelated repo is the better test. The correct --show-toplevel seems to be just the cwd after -C, since GIT_DIR is set without GIT_WORK_TREE.

handle_alias() in git.c has a comment, "Aliases expect GIT_PREFIX, GIT_DIR etc to be set", so the export looks intentional. That makes this more a design question than a microproject, and a test locking in current behavior could age badly. I'm not a mentor, so I've added them to Cc to say whether it fits.

With the contribution period ending soon, a smaller microproject may be the safer route, and you could still raise this one afterwards.

Thanks, Cynthia