{"thread":{"id":"66717","subject":"[Outreachy] GIT_DIR inherited by shell aliases in linked worktrees","startedAt":"2026-10-30T13:37:18Z","lastAt":"2026-11-04T10:05:23Z","messageCount":3,"participants":["Immaculate Mecha","Priestess"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"556917","messageId":"CAKUOgLzP0CSwOwLeoSpM94A+XCT2X_cVojHsLugDfw+tBZk9LQ@mail.gmail.com","threadId":"66717","inReplyTo":null,"subject":"[Outreachy] GIT_DIR inherited by shell aliases in linked worktrees","fromName":"Immaculate Mecha","fromEmail":"immaculatemecha87@gmail.com","sentAt":"2026-10-30T13:37:18Z","receivedAt":"2026-10-30T13:37:18Z","isPatch":false,"sender":{"key":"immaculatemecha87@gmail.com","avatar":null},"body":"I'm considering a small Outreachy contribution around repository\nenvironment handling in external shell aliases.\n\nI reproduced the following behaviour:\n\nCreate a repository with a linked worktree.\n\nRun an external shell alias from inside that worktree.\n\nHave the alias execute git -C ../TestBaseRepo rev-parse.\n\nThe nested command reports the calling worktree's Git directory and\ncommon directory, even though --show-toplevel correctly identifies\nTestBaseRepo.\n\nI traced this to the inherited GIT_DIR variable. Unsetting GIT_DIR\nbefore running the nested command makes all three results point to the\ntarget repository.\n\nI found the earlier 2020 discussion about GIT_DIR inheritance in\naliases, but I'm interested in whether there is still room for a\nfocused contribution, particularly around regression tests for linked\nworktrees.\n\nWould this be a suitable microproject for Outreachy?\n\nThank you,\n\nImmaculate Mecha\n\n"},{"id":"557196","messageId":"CAOcE0wLn5tU6Ok90EhPfyQ0f_atkaFPQyWFLh7JovRGjZ9aZAQ@mail.gmail.com","threadId":"66717","inReplyTo":"CAKUOgLzP0CSwOwLeoSpM94A+XCT2X_cVojHsLugDfw+tBZk9LQ@mail.gmail.com","subject":"Re: [Outreachy] GIT_DIR inherited by shell aliases in linked worktrees","fromName":"Priestess","fromEmail":"herroyalpriestess@gmail.com","sentAt":"2026-11-02T15:44:33Z","receivedAt":"2026-11-02T15:44:33Z","isPatch":false,"sender":{"key":"herroyalpriestess@gmail.com","avatar":null},"body":"On Fri, Oct 30, 2026 at 2:40 PM Immaculate Mecha\n<immaculatemecha87@gmail.com> wrote:\n>\n> I'm considering a small Outreachy contribution around repository\n> environment handling in external shell aliases.\n>\n> I reproduced the following behaviour:\n>\n> Create a repository with a linked worktree.\n>\n> Run an external shell alias from inside that worktree.\n>\n> Have the alias execute git -C ../TestBaseRepo rev-parse.\n>\n> The nested command reports the calling worktree's Git directory and\n> common directory, even though --show-toplevel correctly identifies\n> TestBaseRepo.\n>\n> I traced this to the inherited GIT_DIR variable. Unsetting GIT_DIR\n> before running the nested command makes all three results point to the\n> target repository.\n>\n> I found the earlier 2020 discussion about GIT_DIR inheritance in\n> aliases, but I'm interested in whether there is still room for a\n> focused contribution, particularly around regression tests for linked\n> worktrees.\n>\n> Would this be a suitable microproject for Outreachy?\n>\n> Thank you,\n>\n> Immaculate Mecha\n>\n\n\nHi Immaculate,\n\nI reproduced this on git 2.56.GIT. From inside a linked worktree, an\nalias running `git -C <unrelated-repo> rev-parse --git-dir\n--git-common-dir --show-toplevel` printed the worktree's git dir and\ncommon dir, but a toplevel of the target. Running the same command\nwith `env -u GIT_DIR` gave the target repo for all three, so the\ninherited GIT_DIR is the cause.\n\nNote that with the main repo as the target, --git-common-dir looks\ncorrect either way, so an unrelated repo is the better test. The\ncorrect --show-toplevel seems to be just the cwd after -C, since\nGIT_DIR is set without GIT_WORK_TREE.\n\nhandle_alias() in git.c has a comment, \"Aliases expect GIT_PREFIX,\nGIT_DIR etc to be set\", so the export looks intentional. That makes\nthis more a design question than a microproject, and a test locking\nin current behavior could age badly. I'm not a mentor, so I've added\nthem to Cc to say whether it fits.\n\nWith the contribution period ending soon, a smaller microproject may\nbe the safer route, and you could still raise this one afterwards.\n\nThanks,\nCynthia\n\n"},{"id":"557419","messageId":"CAKUOgLzN-7-ywvdPnpNF+KPbPovHko5iqZ2X6VaJvZjAaaZGkA@mail.gmail.com","threadId":"66717","inReplyTo":"CAOcE0wLn5tU6Ok90EhPfyQ0f_atkaFPQyWFLh7JovRGjZ9aZAQ@mail.gmail.com","subject":"Re: [Outreachy] GIT_DIR inherited by shell aliases in linked worktrees","fromName":"Immaculate Mecha","fromEmail":"immaculatemecha87@gmail.com","sentAt":"2026-11-04T10:05:23Z","receivedAt":"2026-11-04T10:05:23Z","isPatch":false,"sender":{"key":"immaculatemecha87@gmail.com","avatar":null},"body":"Hi,\n\nThank you for reproducing the issue and for explaining the design implications.\n\nGiven the contribution deadline, I would like to use the reproduction\nand investigation as my Outreachy contribution.\n\nThe investigation has helped me understand how Git handles repository\nenvironment variables in external shell aliases, particularly when\nlinked worktrees and `git -C` are involved.\n\nI understand that changing the current behaviour may require a broader\ndesign discussion. I would appreciate the mentors' guidance on whether\nthis investigation is suitable as a contribution for the Git Outreachy\nproject, or whether they would prefer a small follow-up task.\n\nThank you for your time and guidance.\n\nImmaculate Mecha\n\n\nOn Mon, Nov 2, 2026 at 6:44 PM Priestess <herroyalpriestess@gmail.com> wrote:\n>\n> On Fri, Oct 30, 2026 at 2:40 PM Immaculate Mecha\n> <immaculatemecha87@gmail.com> wrote:\n> >\n> > I'm considering a small Outreachy contribution around repository\n> > environment handling in external shell aliases.\n> >\n> > I reproduced the following behaviour:\n> >\n> > Create a repository with a linked worktree.\n> >\n> > Run an external shell alias from inside that worktree.\n> >\n> > Have the alias execute git -C ../TestBaseRepo rev-parse.\n> >\n> > The nested command reports the calling worktree's Git directory and\n> > common directory, even though --show-toplevel correctly identifies\n> > TestBaseRepo.\n> >\n> > I traced this to the inherited GIT_DIR variable. Unsetting GIT_DIR\n> > before running the nested command makes all three results point to the\n> > target repository.\n> >\n> > I found the earlier 2020 discussion about GIT_DIR inheritance in\n> > aliases, but I'm interested in whether there is still room for a\n> > focused contribution, particularly around regression tests for linked\n> > worktrees.\n> >\n> > Would this be a suitable microproject for Outreachy?\n> >\n> > Thank you,\n> >\n> > Immaculate Mecha\n> >\n>\n>\n> Hi Immaculate,\n>\n> I reproduced this on git 2.56.GIT. From inside a linked worktree, an\n> alias running `git -C <unrelated-repo> rev-parse --git-dir\n> --git-common-dir --show-toplevel` printed the worktree's git dir and\n> common dir, but a toplevel of the target. Running the same command\n> with `env -u GIT_DIR` gave the target repo for all three, so the\n> inherited GIT_DIR is the cause.\n>\n> Note that with the main repo as the target, --git-common-dir looks\n> correct either way, so an unrelated repo is the better test. The\n> correct --show-toplevel seems to be just the cwd after -C, since\n> GIT_DIR is set without GIT_WORK_TREE.\n>\n> handle_alias() in git.c has a comment, \"Aliases expect GIT_PREFIX,\n> GIT_DIR etc to be set\", so the export looks intentional. That makes\n> this more a design question than a microproject, and a test locking\n> in current behavior could age badly. I'm not a mentor, so I've added\n> them to Cc to say whether it fits.\n>\n> With the contribution period ending soon, a smaller microproject may\n> be the safer route, and you could still raise this one afterwards.\n>\n> Thanks,\n> Cynthia\n\n"}]}