git config: unintuitive behaviour with --global and --no-includes

Hendrik Jaeger <[email protected]> Mon, 20 Jul 2026 11:34:02 +0200
Newsgroups	org.kernel.vger.git
Message-ID	<[email protected]>
Hi

I ran into a problem working with lbmk (https://codeberg.org/libreboot/lbmk).
To see whether git is correctly configured, it runs `git config --global user.name` and that failed for my setup.
The reason is that I have user.name and user.email not directly in the normal git config file but in an included file and when given a scope like --global `git config` does not by default check included files.

I tried to create a commented minimal example showing the problem with that:

```
# no config exists
~ % cat .gitconfig
cat: .gitconfig: No such file or directory
~ % cat .gitconfig_personal
cat: .gitconfig_personal: No such file or directory
~ % ls ~/.config/git
ls: cannot access '/home/resu/.config/git': No such file or directory

# config var is not set
~ % git config --show-scope --show-origin user.name

# set user.name
~ % git config --global user.name "Hendrik Jäger"

# check if it is set
~ % cat .gitconfig
[user]
        name = Hendrik Jäger

# check where it is set
~ % git config --show-scope --show-origin user.name
global  file:/home/resu/.gitconfig      Hendrik Jäger

# check whether we can still retrieve it when explicitly giving the scope
~ % git config --show-scope --show-origin --global user.name
global  file:/home/resu/.gitconfig      Hendrik Jäger

# move setting to non-standard file
~ % cat .gitconfig > .gitconfig_personal

# include that non-standard file
~ % echo '[include]\npath = .gitconfig_personal' >| .gitconfig

# check config status
~ % cat .gitconfig
[include]
path = .gitconfig_personal
~ % cat .gitconfig_personal
[user]
        name = Hendrik Jäger

# check whether git still finds that setting
~ % git config --show-scope --show-origin user.name
global  file:/home/resu/.gitconfig_personal     Hendrik Jäger

# check whether git still finds that setting in the scope it is in
~ % git config --show-scope --show-origin --global user.name

# set it again in the global scope
~ % git config --global user.name "Henk Hunter"

# check again
~ % git config --show-scope --show-origin user.name
global  file:/home/resu/.gitconfig      Henk Hunter

# check again with specific scope
~ % git config --show-scope --show-origin --global user.name
global  file:/home/resu/.gitconfig      Henk Hunter

# reset git config and check if the setting is really gone
~ % rm .gitconfig
~ % git config --show-scope --show-origin user.name

# set it again in global scope with different value
~ % git config --global user.name "Henk Hunter"

# check whether setting it was successful
~ % git config --show-scope --show-origin user.name
global  file:/home/resu/.gitconfig      Henk Hunter

# check again with specific scope
~ % git config --show-scope --show-origin --global user.name
global  file:/home/resu/.gitconfig      Henk Hunter

# add the include back
~ % echo '[include]\npath = .gitconfig_personal' >> .gitconfig

# check config status
~ % cat .gitconfig
[user]
        name = Henk Hunter
[include]
path = .gitconfig_personal

# check the value and from which scope it comes
~ % git config --show-scope --show-origin user.name
global  file:/home/resu/.gitconfig_personal     Hendrik Jäger

# check again with specific scope
~ % git config --show-scope --show-origin --global user.name
global  file:/home/resu/.gitconfig      Henk Hunter

# check again while allowing includes
~ % git config --show-scope --show-origin --includes user.name
global  file:/home/resu/.gitconfig_personal     Hendrik Jäger
~ % git config --show-scope --show-origin --global --includes user.name
global  file:/home/resu/.gitconfig_personal     Hendrik Jäger
```

The manpage says:
> Respect include.*  directives in config files when looking up values. Defaults to off when a specific file is given (e.g., using --file, --global, etc) and on when searching all config files.

IMHO it makes sense the way it is phrased “when a specific file is given” but then seems to turn into non-sense when --global is given as an example. Giving --global is not “giving a specific file” but “restricting to a specific scope”, which may `include` other files.
The results seem inconsistent and counterintuitive to me.

Am I misunderstanding anything here?
Is this behaviour intended?
If it is intended, can someone please explain the rationale behind it? I don’t get it, it seems wrong to me.

Regarding the initial issue: I just added --includes to the call in lbmk and it works just fine, so there is no need to address this. I only mentioned it for context to how I got to looking into this behaviour.
If any relevant information is missing in this bugreport, I’ll be happy to add it, please let me know!

Thank you very much

henk
signature.asc (application/pgp-signature, 833 B)