setup_git_env: avoid blind fall-back to ".git"
authorJeff King <peff@peff.net>
Thu, 20 Oct 2016 06:24:31 +0000 (02:24 -0400)
committerJunio C Hamano <gitster@pobox.com>
Wed, 26 Oct 2016 20:30:51 +0000 (13:30 -0700)
commitb1ef400eece473f83f39980c54f67e3e7d202538
tree2a513b9782b489001075ea6a45fae22e798bcc82
parent4f03666ac69ec4799998f010d04916c12e38edf8
setup_git_env: avoid blind fall-back to ".git"

When we default to ".git" without having done any kind of
repository setup, the results quite often do what the user
expects.  But this has also historically been the cause of
some poorly behaved corner cases. These cases can be hard to
find, because they happen at the conjunction of two
relatively rare circumstances:

  1. We are running some code which assumes there's a
     repository present, but there isn't necessarily one
     (e.g., low-level diff code triggered by "git diff
     --no-index" might try to look at some repository data).

  2. We have an unusual setup, like being in a subdirectory
     of the working tree, or we have a .git file (rather
     than a directory), or we are running a tool like "init"
     or "clone" which may operate on a repository in a
     different directory.

Our test scripts often cover (1), but miss doing (2) at the
same time, and so the fallback appears to work but has
lurking bugs. We can flush these bugs out by refusing to do
the fallback entirely., This makes potential problems a lot
more obvious by complaining even for "usual" setups.

This passes the test suite (after the adjustments in the
previous patches), but there's a risk of regression for any
cases where the fallback usually works fine but the code
isn't exercised by the test suite.  So by itself, this
commit is a potential step backward, but lets us take two
steps forward once we've identified and fixed any such
instances.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
environment.c