Re: [Outreachy] GIT_DIR inherited by shell aliases in linked worktrees
Hi,
Thank you for reproducing the issue and for explaining the design implications.
Given the contribution deadline, I would like to use the reproduction and investigation as my Outreachy contribution.
The investigation has helped me understand how Git handles repository environment variables in external shell aliases, particularly when linked worktrees and `git -C` are involved.
I understand that changing the current behaviour may require a broader design discussion. I would appreciate the mentors' guidance on whether this investigation is suitable as a contribution for the Git Outreachy project, or whether they would prefer a small follow-up task.
Thank you for your time and guidance.
Immaculate Mecha
On Mon, Nov 2, 2026 at 6:44 PM Priestess <herroyalpriestess@gmail.com> wrote:
Show 61 quoted lines
>
> On Fri, Oct 30, 2026 at 2:40 PM Immaculate Mecha
> <immaculatemecha87@gmail.com> wrote:
> >
> > 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