On Thu, Apr 08, 2021 at 04:43:08PM -0700, Junio C Hamano wrote: > > Some other things to consider: > > > > - does setting GIT_CONFIG_GLOBAL override both the $HOME and > > $XDG_CONFIG_HOME? If the plan is to override them, that makes sense. > > But we do usually read from both of them, so conceivably you might > > want to override just one? That's probably over-engineering, though. > > I viewed this to be working at the more conceptual "here is the file > to read 'system' (or 'per-user') stuff from" level, and not at the > level of the individual file, as I consider that it is a mere > implementation detail that 'per-user' may read from multiple files. Yeah. I'm OK with that. I think it's conceptually simpler. I was going to also say "less flexible", but once you have pointed Git at the file of your choice, it is easy to [include] any other one if you want. > We may have to bite the bullet and make an official catalog of > really "structurely fundamental" configuration variables that must > appear in the per-repository file, and a mechanism to enforce that > by always reading these variables from "$GIT_DIR/config" and always > ignoring appearances of them in any other places. > > That alone would probably be a good thing to do regardless of the > GIT_CONFIG_NOGLOBAL issue, as I suspect you may be able to wreak > havoc by adding random configuration like [extension] in > $HOME/.gitconfig ;-) I think we've historically had some problems there, but I think these days it's not too bad. We look directly at $GIT_DIR/config with read_repository_format(), loading only stuff that check_repo_format() cares about: - core.repositoryformatversion - extensions.* - core.bare - core.worktree And those _should_ be ignored by the regular config-reading paths. So I think it would be OK to have a $GIT_CONFIG_LOCAL variable that overrides the location in do_git_config_sequence() only, and that would cover only the preferences parts. I do agree it wouldn't hurt to document which options are read in which context. I do wonder how useful such an option would be, though. I can see why you would want to redirect or disable system-level or user-level config once, and then use it for many invocations. But in a single repo, you might as well just set the repo config, or override it for a single invocation with "git -c", etc. I guess one possible use could be "I got a repository I do not trust as a tarball and want to investigate it without paying attention to its local config". But that's a pretty narrow case, and you'd probably be better off just vetting the config yourself anyway (since depending on what you want to do in the repo, you may need some of that config, like remote.*, etc). I dunno. -Peff
