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

> > >> 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

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.


Reply via email to