On Mon, Dec 22, 2025 at 3:55 AM Matthew Hughes
[off-list ref] wrote:

quoted

I am not sure if singling out "maintenance" is the right approach to
solve that issue.  If we had a mechanism to have two per-user
configuration file, where one is read-only (as far as Git is
concerned) which is covered/overlayed with a separate read-write
file, not just "maintenance register/unregister" but all other
things that writes into "git config" would use that overlayed file
without touching the base configuration that is read-only.  Wouldn't
that be closer to what you want?

Indeed a read-only config as you described would be a more general solution,
and a better one than focusing on single commands like this change does. I'm
now curious if a similar idea has been discussed in the past? I'll go have a
look in the history of this mailing list.

That leads me to think my proposed change is too narrow in scope, and risks
dividing functionality: where some commands are taught to consider the separate
types of configuration, while others are not.

For background: I singled out "maintenance" only because it's the first git
command that I can remember seeing that was writing to my global config
(outside of "config" itself).

FWIW, I also include my gitconfig in version control, and the way I
manage this is with

    [include]
            path = ~/.gitconfig.local

If I run "git maintenance register", I then move the added
configuration lines to ~/.gitconfig.local. It's a bit of a hassle, but
not much (I don't frequently add new repos to the set).

-- 
D. Ben Knoble