On Tue, Jul 09, 2013 at 01:49:21PM +0200, Thomas Rast wrote: > Rather, it's very strange that 'git config --file foo' tries to look at > any config file other than 'foo'. In a git repo: > > $ strace git config --file fooconfig test.var 2>&1 | grep 'open.*config' > open("/home/thomas/.gitconfig", O_RDONLY) = 3 > open(".git/config", O_RDONLY) = 3 > open("/home/thomas/.gitconfig", O_RDONLY) = 3 > open(".git/config", O_RDONLY) = 3 > open("fooconfig", O_RDONLY) = 3 > > I haven't looked into the code yet. Probably it's simply following the > usual code paths to discover a repo and read its config. However, with > the --file option, it shouldn't. I'm not so sure. It is (in theory) OK to read the usual config files to find out _how_ git-config should behave, but then return results from a specific file. The former should read the "normal" files, and the latter should read whatever is specified by the options ("--file", a specific level like "--global", or the usual set of files). There are probably not many config options that can affect git-config's behavior. The few I can think of are: 1. core.editor should affect "git config --edit" 2. pager.config would auto-start a pager. I am not sure if that is a sane thing to do or not. 3. In theory you could have advice.* affect git-config, but I do not think any currently do. 4. Currently git-config does not read objects, but there are patches proposed to do so. In that case, things like core.packedGitWindowSize might be important. So I think you could probably drop the config parsing, special-case (1), and ignore (2) as silly. But I think (3) and (4) show that it isn't the right thing to do; you will never know which config options affect git-config's behavior in the future. The real issue here is not the "extra" normal config parsing; it is that the normal parsing does not work in some cases. And that has already been fixed by Jonathan's 4698c8f (config: allow inaccessible configuration under $HOME, 2013-04-12). -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html