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

On Mon, Jul 20, 2026 at 11:34:02AM +0200, Hendrik Jaeger wrote:

> 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.

The behavior you're seeing is intended. Regarding "a specific scope", I
don't think that's an unreasonable way to think about it. But it's not
how Git thinks about it, and in particular back when --include was added
and this behavior was set, "--global" was literally a synonym for
"--file=$HOME/.gitconfig".

As for the rationale, it is a mix of backwards compatibility and
least-surprise. The include functionality was tacked on to the existing
config parser, and we did not want to surprise anybody who asked for a
specific file by showing them results for another file. This is
especially important for reading untrusted input like .gitmodules, but
also for writing.

> 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.

IMHO lbmk is wrong to be using "--global" in the first place. Looking at
the source, it is trying to check whether the user has set up their
identity. But it is not lbmk's business whether you did it in the
--global config file, or elsewhere! So it should probably just use a
straight "git config user.name", which will do the same resolution that
Git will do internally.

The "--global" was added in their 4a280c62 (.gitcheck: re-write
entirely. force global config., 2023-08-27), but I don't see any
rationale given.

Depending on what they are trying to check, it might be even better
still for it to use "git var GIT_AUTHOR_IDENT". That will give the
actual ident Git will derive, including things like checking $EMAIL in
the environment and so on.

So if the intent is "will Git come up with some ident", then that is the
most accurate way to check it. But if the intent is "did the user
specifically configure Git (because we are worried that values derived
from GECOS and $EMAIL might not be accurate)", then checking user.*
specifically is closer to that.

Though note there is one other hitch, which is that the user can set
author.* and committer.* as specific variables, since 39ab4d0951
(config: allow giving separate author and committer idents, 2019-02-04).
I suspect not many people do that, but that would also be something that
a config-specific check would have to handle (but "git var" would do
automatically).

So I think you might consider sending a bug report to lbmk. Feel free to
point at this thread, and I'm happy to discuss further with them.

-Peff