Re: [RFC PATCH 1/1] maintenance: add config option for config-file

From: Matthew Hughes <matthewhughes934@gmail.com>
Date: Dec 22, 2025, 08:26 UTC
Message-ID: <fmj4be365s6jczb6p2ccb6a6vh64bltgfl5neshu6g7hrabzeb@twzrzmprhotf>
In-Reply-To: <xmqqike2x4ei.fsf@gitster.g>

On Fri, Dec 19, 2025 at 05:27:33PM +0900, Junio C Hamano wrote:

Show 16 quoted lines

>  * maintenance.configFile specifies an additional file to which
>    maintenance.repo configuration items are written out when "git
>    maintenance register/unregister" works.  
> 
>  * "git config" is not affected, so "git config set --global
>    --append maintenance.repo foo" would still write into the
>    per-user configuration file.
> 
>  * Also, the general config API does not pay maintenance.configFile
>    at all, so setting it does not affect "git config list", for
>    example.
> 
>  * You'd need an extra "[include] path = maintenance.config" in the
>    configuration file because of the previous point.
> 
> Am I following you well so far?

 
Yep, this is a good summary of what my change looks to achieve. From Patrick's
response (https://lore.kernel.org/git/aUT8Vcevf8WiQgn0@pks.im/) I understand
the requirement of the extra "include.path" setting is likely not acceptable
for a usability point of view.

> Giving an explanation on your _intent_, along with the sample configuration,
> would help your readers, and I would expect something with a similar degree
> of detail as above in the log message.

Thanks for the feedback, I'll look to be clearer with my intent in the future.

Show 8 quoted lines

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