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

From: Jeff King <peff@peff.net>
Date: Jul 13, 2018, 20:19 UTC
Message-ID: <20180713201949.GA17670@sigill.intra.peff.net>
In-Reply-To: <20180713184732.GC968742@genre.crustytoothpaste.net>

On Fri, Jul 13, 2018 at 06:47:32PM +0000, brian m. carlson wrote:

Show 12 quoted lines

> > >> git rebase 18404434bf406f6a6f892ed73320c5cf9cc187dd -x "(cd xdiff; git rev-parse --show-toplevel)"
> > > ... path to git repository/xdiff !!!
> > >
> > > This seems like incorrect behaviour to me since it's a weird
> > > inconsistency (even with other rebase contexts) & the documentation
> > > says "Show the absolute path of the top-level directory." with no
> > > caveats.
> > 
> > Does it reproduce with older rebase (say from v2.10 days), too?
> 
> It appears to work correctly on the CentOS SCL Git 2.9.3.  We print the
> top level of the repository there.

Bisecting is tricky, because there are actually three distinct behaviors.

The command above prints the correct top-level until 18633e1a22 (rebase -i: use the rebase--helper builtin, 2017-02-09). After that, rev-parse prints "Not a git repository".

That goes on until 09d7b6c6fa (sequencer: pass absolute GIT_DIR to exec commands, 2017-10-31).

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.

-Peff