Re: git rebase exec make -C in worktree confuses repo root dir

From: Eric Sunshine <sunshine@sunshineco.com>
Date: Oct 16, 2024, 21:12 UTC
Message-ID: <CAPig+cQmGXxDshTovdAYaZn5UMr3nvXHyH0q2HvAbaT_fhhiLQ@mail.gmail.com>
In-Reply-To: <1dc91aa7-04da-4023-bbd5-5b12539477ba@gmail.com>

On Wed, Oct 16, 2024 at 5:15 AM Phillip Wood <phillip.wood123@gmail.com> wrote:

Show 20 quoted lines

> On 15/10/2024 21:01, Eric Sunshine wrote:
> >> Den tis 15 okt. 2024 kl 09:11 skrev Eric Sunshine <sunshine@sunshineco.com>:
> >>> This looks like unintentional behavior; probably a bug. It seems to be
> >>> triggered by `git rebase -i` setting GIT_DIR. [...]
> >>>      % git -C dir rev-parse --show-toplevel
> >>>      /.../bar
> >>>      % GIT_DIR=../../foo/.git/worktrees/bar \
> >>>          git -C dir rev-parse --show-toplevel
> >>>      /.../bar/dir
> >>>
> >>> The `git rev-parse --show-toplevel` invocation with GIT_DIR set is
> >>> incorrectly returning `/.../bar/dir` rather than `/.../bar`.
>
> I'm about to go off the list until the 29th so I wont be working on it
> soon either but I think the problem is that git sets $GIT_DIR when it is
> run from a linked worktree. I've reproduced the commit message from
> ff5b7913f0a (sequencer, stash: fix running from worktree subdir,
> 2022-01-26) below which I think explains the problem we're seeing here.
> Unfortunately the approach of setting $GIT_WORK_TREE used in that commit
> won't work for exec commands as they may be run in a different worktree.

Maybe. Maybe not. exec'ing a command in a worktree other than the current worktree may be a "don't do it if it hurts" situation. The same shortcoming you describe would crop up when exec'ing a command in a foreign repository from the one in which `git rebase -i` is being run. If we look at it that way ("don't do it if it hurts"), then perhaps a documentation update is warranted; something along the lines [1] which gives explains that GIT_* environment variables should be cleared by a Git hook if it needs to peek into a foreign repository or other worktree. It's not a perfectly satisfactory answer, but would at least (somewhat?) allay your concern about `git rebase -i` setting GIT_WORK_TREE automatically.

[1]: https://lore.kernel.org/git/pull.1457.git.1673171924727.gitgitgadget@gmail.com/