On Wed, Oct 16, 2024 at 5:15 AM Phillip Wood <phillip.wood123@xxxxxxxxx> wrote:
> On 15/10/2024 21:01, Eric Sunshine wrote:
> >> Den tis 15 okt. 2024 kl 09:11 skrev Eric Sunshine <sunshine@xxxxxxxxxxxxxx>:
> >>> 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@xxxxxxxxx/
