Phillip Wood <phillip.wood@xxxxxxxxxxxx> writes: > Just clearing GIT_DIR does not match the behavior of the shell version > (tested by passing -p to avoid rebase--helper) as that passes GIT_DIR to > exec commands if it has been explicitly set. I think that users that set > GIT_DIR on the command line would expect it to be propagated to exec > commands. > > $ git rebase -px'echo $GIT_DIR' @ > > Merge commit > '7c2f1abd64' into phil > Executing: echo $GIT_DIR > > Successfully rebased and updated refs/heads/phil. > > $ env GIT_DIR=.git git rebase -px'echo $GIT_DIR' @ > > Merge commit > '7c2f1abd64' into phil > Executing: echo $GIT_DIR > /home/phil/Documents/src/git/.git/worktrees/git-next > Successfully rebased and updated refs/heads/phil. Hmmm, I do not mess with GIT_DIR at all in my workflow, so I am having a bit of hard time judging if this regression is serious enough to be a release blocker. I'd prefer to avoid reverting the whole js/rebase-i-final topic from 'master' this late in the game, even though I do not expect we would see the remainder of the system gets broken due to hidden dependency on the topic, because the changes on the topic are relatively well isolated. 570676e011 d1114d87c7 2f0e14e649 5f3108b7b6
