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

Hendrik Jaeger <[email protected]> Tue, 21 Jul 2026 13:53:17 +0200
Newsgroups	org.kernel.vger.git
Message-ID	<[email protected]>
Hi Jeff

Thanks for your email!

> As for the rationale, it is a mix of backwards compatibility and least-surprise.

To be honest, this reminds me of the XKCD comic with the title "workflow": https://xkcd.com/1172/
The behaviour may be “least-surprise” for the initiated. For everyone new to this, I’d expect it to be as “most-surprising” as it was for me.

Best regards

henk


On Mon, 20 Jul 2026 08:51:45 -0400
Jeff King <[email protected]> wrote:

> 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
signature.asc (application/pgp-signature, 833 B)