Hi Junio, On Mon, 16 Jul 2018, Junio C Hamano wrote:
> Jeff King <p...@peff.net> writes: > > > None of which is too surprising. The root of the bug is in the > > conversion to rebase--helper, I think, when presumably we started > > setting GIT_DIR at all (but I didn't dig further). Then 09d7b6c6fa fixed > > _one_ fallout of that, which was relative paths, but didn't help the > > subdirectory case. > > > > Just reading over this thread, I suspect the simplest fix is to pass > > GIT_DIR and GIT_WORK_TREE together, which is almost always the right > > thing to do. > > Perhaps. Not exporting GIT_DIR (unless the end-user already did to > the environment before starting "git rebase"---it would be a bad > change to unexport it unconditionally) may probably be a way to make > rebase--helper conversion more faithful to the original scripted > Porcelain, but I suspect in practice always giving GIT_DIR and > GIT_WORK_TREE would work well for many existing hooks. Forgetting the code in git-sh-setup, are we? git_dir_init() rather specifically set GIT_DIR to the absolute path, and since that variable is already exported, the `exec` commands launched via `git-rebase--interactive` all saw it. That is the reason why the sequencer.c was taught to set GIT_DIR to an absolute path rathern than not setting it: for backwards compatibility. Ciao, Dscho
