Re: [PATCH 0/16] fix config-reading in non-repos
On Wed, Sep 14, 2016 at 12:55:41PM +0200, Dennis Kaarsemaker wrote: > > [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 > > Couldn't find anything to comment on, and I've tested that this does > indeed fix the symptoms we saw. > > Reviewed-by: Dennis Kaarsemaker Thanks. Based on our conversations earlier, I tried to dig around for other cases that might be broken, especially with the "reinit" cases. The result is the tests in patch 16. But let me know if you can think of anything else that might be broken. -Peff
Re: [PATCH 0/16] fix config-reading in non-repos
On ma, 2016-09-12 at 23:22 -0400, Jeff King wrote: > 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-ffe31104e...@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. Agreed with all of the above, this is much better than just fixing the symptom on the mailinglist thread that started this. > 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 Couldn't find anything to comment on, and I've tested that this does indeed fix the symptoms we saw. Reviewed-by: Dennis Kaarsemaker -- Dennis Kaarsemaker http://www.kaarsemaker.net
[PATCH 0/16] fix config-reading in non-repos
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-ffe31104e...@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
