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