Hi Matt, On 26/04/2020 14:30, Matt Rogers wrote: >> Given the extra config environment settings, could/should the >> --show-scope (or complementary option) also show/clarify these >> environment variable settings? > I'm lukewarm either way on this one, I think it would be pretty trivial > to write something that did this, so that only leaves the question of > 'should' we do this, which I don't really have any particularly strong > feelings about. My thought was that in some cases folks will feel they 'know' where their system and global configs are located, but that 'git config' command isn't showing them those contents. > What would this even ultimately look like? perhaps > something like this for a command of `git config --show-scope`: > > system var=option (currently ignored due to GIT_CONFIG_NOSYSTEM) That's one option. The other, non-programmatic way, it to mention the environment variable in the 'git config' man page, at the --show-scope section, telling folk that if those env variables are set there won't be any scope to show! > > Which kind of begs the question of how many people set that variable > and then forget that they set it? The one that caught me was the test suit[1]. I was unable to replicate results when I set up a test. This can be bad on Windows where some settings need to be auto set (or are commonly set) and maybe result in conflicts. Often what doesn't know what's been done on ones behalf. There's plenty of spare configs to go round ;-) > Although I can totally see why it would > be nice to have some kind of config flag that's a big > "Just show me everything that's going on option" which considering these > variables would probably be a little bit more than the current next-best of > `git config --list --show-scope --show-origin`. Again though, I'm not > exactly sure how useful such an option would be. Mateusz's original problem was with discovery of these env variables, so ended up with an XY-problem of proposing a patch to redirect the ~/.gitconfig file, because relevant the env variables weren't (for him, and previously myself) discoverable. If we go with a 'No one reads the manuals' developer view, then the solution has to be more code... hence my wondering if there was an easy win inside the code, or if it needs to be a subjective update to the man pages (never 'easy'). The man page The GIT_CONFIG_NOSYSTEM only gets its 1 mention as a heading, while GIT_CONFIG has two (+ a heading). Maybe we need to spread the love for NOSYSTEM... > -- Philip [1] https://lore.kernel.org/git/8850d755-07ce-d8d2-6e5c-88393fce34de@xxxxxxx/
