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

From: Jeff King <peff@peff.net>
Date: Jul 16, 2018, 18:39 UTC
Message-ID: <20180716183942.GB22298@sigill.intra.peff.net>
In-Reply-To: <xmqqsh4jt5d0.fsf@gitster-ct.c.googlers.com>

On Mon, Jul 16, 2018 at 11:14:51AM -0700, 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.

Yeah, that may be an option. I don't remember if this was discussed in this thread or elsewhere, but setting GIT_DIR is a regression for hooks, etc, which do:

  git -C /some/other/repo log

or similar. I'm not sure if that falls under "actual regression" or "just how it happened to work in the past". I'm not even sure it worked that way _consistently_ in the past.

The best practice if you're switching directories is to do:

  unset $(git rev-parse --local-env-vars)

though I highly doubt that most people bother.

-Peff