Re: rev-parse --show-toplevel broken during exec'ed rebase?

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Jul 19, 2018, 20:28 UTC
Message-ID: <nycvar.QRO.7.76.6.1807192225260.71@tvgsbejvaqbjf.bet>
In-Reply-To: <xmqqsh4jt5d0.fsf@gitster-ct.c.googlers.com>

Hi Junio,

On Mon, 16 Jul 2018, Junio C Hamano wrote:

Show 18 quoted lines

> Jeff King <peff@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