sharp edges in Git configuration files

(let's try this again and see if gmail html-izes AGAIN on me...)

This isn't any kind of serious bug, but I have been playing with Git configuration files to determine a lot of precise details about behavior when reading or changing them, both with "git config" and with the implicit changes made by "git branch", "git remote", and other internal operations.

Anyway, one edge case that causes problems occurs if a user manually edits a ".git/config" file to add include directives. For instance, it's possible to take one or more [remote] or [branch] sections out into a separate file. The following "ed" command will do this (not very safely, don't do it on any repo you care about, just in case):

ed - .git/config <<'END'
/^\[remote /,$w .git/inc-remote
/^\[remote /,$d
a
[include]
        path = inc-remote
.
w
q
END

after which some "git remote" operations that try to update the remotes just fail bizarrely.

(Note: gmail may have whacked white space above, I've set it to send plain text but gmail is...what it is.)

The obvious thing with "doctor it hurts when I do this" is of course "well don't do that", and nobody should be splitting their .git/config into multiple included sub-config-files. But, in the spirit of robust software (and perhaps just as leftover bits?), it might be wise to make Git ignore include lines in config files that are intended to be Git-managed directly, such as .git/config.

Chris

On 2026-10-31 at 02:56:44, Chris Torek wrote:

I actually believe we're using includes for `.git/config` in some cases at work and I'm pretty sure my colleagues do want them to continue to work.

I don't know exactly why they're doing that, since I'm not intimately involved with that project, but I will point out that our fork of Git has a checksum that includes the `config` file (but not included files) and that must be in sync across replicas, so they may be doing so to test out a config setting on a particular host during development. In any event, I'd say that while it may seem bizarre, some people might want to do this for other reasons[0], so we probably shouldn't break it.

[0] One reason I can imagine is personal configuration (via `path=~/...`) in large shared repositories. Yes, people shouldn't be doing that, but we know they do.