[PATCH 0/16] fix config-reading in non-repos

[Jeff King <peff@peff.net>]

The motivation for this series is to fix the regression in v2.9 where
core.logallrefupdates is sometimes not set properly in a newly
initialized repository, as described in this thread:

  http://public-inbox.org/git/c46d36ef-3c2e-374f-0f2e-ffe31104e023@gmx.de/T/#u

The root of the problem is that we are overly eager to read and use
config from ".git/config", even when we have not established that it is
part of a repository. This is especially bad for git-init, which would
not want to read anything until we've created the new repo.

So the two interesting parts of the fix are:

  1. We stop blindly reading ".git/config" when we don't know there's an
     actual git directory. This is in patch 14, and is actually enough
     to fix the v2.9 regression.

  2. We are more thorough about dropping any cached config values when
     we move into the new repository in git-init (patch 16).

     I didn't dig into when this was broken, but it was probably when we
     switched git_config() to use cached values in the v2.2.0
     time-frame.

Doing (1) required fixing up some builtins that depended on the blind
.git/config thing, as the tests demonstrated. But I think this is a sign
that we are moving in the right direction, because each one of those
programs could easily be demonstrated to be broken in scenarios only
slightly more exotic than the test scripts (e.g., see patch 3 for one of
the simplest cases).

So I think notwithstanding their use as prep for patch 14, patches 1-13
fix useful bugs.

I won't be surprised if there are other fallouts that were not caught by
the test suite (i.e., programs that expect to read config, don't do
RUN_SETUP, but aren't covered well by tests). I poked around the list of
builtins in git.c that do not use RUN_SETUP, and they seem to correctly
end up in setup_git_directory_gently() before reading config. But it's
possible I missed a case.

So this is definitely a bit larger than I'd hope for a regression-fix to
maint. But anything that doesn't address this issue at the config layer
is going to end up as a bit of a hack, and I'd rather not pile up hacks
if we can avoid it.

I have a few patches on top that go even further and disallow the
auto-fallback of looking in ".git" at all for non-repositories. I think
that's the right thing to do, and after years of chipping away at the
setup code, I think we're finally at a point to make that change (with a
few fixes of course). But that's an even riskier change and not fixing
an immediate regression. So I'll hold that back for now, and hopefully
it would become "master" material once this is sorted out.

I've cc'd Dennis, who helped investigate solutions in the thread
mentioned above, and Duy, because historically he has been the one most
willing and able to battle the dragon of our setup code. :)

  [01/16]: t1007: factor out repeated setup
  [02/16]: hash-object: always try to set up the git repository
  [03/16]: patch-id: use RUN_SETUP_GENTLY
  [04/16]: diff: skip implicit no-index check when given --no-index
  [05/16]: diff: handle --no-index prefixes consistently
  [06/16]: diff: always try to set up the repository
  [07/16]: pager: remove obsolete comment
  [08/16]: pager: stop loading git_default_config()
  [09/16]: pager: make pager_program a file-local static
  [10/16]: pager: use callbacks instead of configset
  [11/16]: pager: handle early config
  [12/16]: t1302: use "git -C"
  [13/16]: test-config: setup git directory
  [14/16]: config: only read .git/config from configured repos
  [15/16]: init: expand comments explaining config trickery
  [16/16]: init: reset cached config when entering new repo

-Peff