Re: [PATCH 00/11] [RFC] config-batch: a new builtin for tools querying config

From: Derrick Stolee <stolee@gmail.com>
Date: Feb 5, 2026, 14:10 UTC
Message-ID: <36bae79b-576f-48f1-b31c-15c3a1f4bce7@gmail.com>
In-Reply-To: <xmqq5x8cnm93.fsf@gitster.g>

On 2/4/2026 6:04 PM, Junio C Hamano wrote:

Show 25 quoted lines

> "Derrick Stolee via GitGitGadget" <gitgitgadget@gmail.com> writes:
> 
>> This RFC explores a new git config-batch builtin that allows tools to
>> interact with Git's config data with multiple queries using a single
>> process. This is an orthogonal alternative to the effort to create a stable,
>> linkable config API. Both approaches have different strengths.
> 
> Just a few random thoughts before diving into the patches.
> 
>> My main motivation is the performance of git-credential-manager on Windows
>> platforms as it can call git config get dozens of times. At 150-200ms per
>> execution, that adds up significantly, leading to multiple seconds just to
>> load a credential that already exists. I believe that there are other
>> benefits to having this interface available, but I can't recall any
>> specifics at the moment.
> 
> So this would be "credential-manager gets started, and instead of
> having to spawn 'git config' many times, spawn a single instance of
> 'git config --batch' and talk with it".  Would it be beneficial to
> further think about a long-running 'git config --server' that can be
> contacted by a credential-manager (or other processes) whose lifetime
> is totally independent, possibly over local transport mechanisms
> like named pipes, or is it a key to keep the mechanism and design
> simple to limit the number of customer this service supports to only
> one at a time and we would prefer to keep it that way?

I could imagine a world where we have this approach, similar to the fsmonitor server. I should do more research and refresh my memory on that I/O model, if only to potentially reuse some of the parsing logic.

But this would be an interesting potential direction, saving the process start-up time entirely.

The one big difficulty that I see is that the config will need to be refreshed proactively by the server, potentially by watching the config files themselves (including any files included along the way) and also any changes to repo state, such as the current branch. Any repo state that could impact the 'includeIf' logic would need to be checked carefully.

Show 9 quoted lines

>> One thing that I think would be valuable to include is a reload command that
>> signals that the git config-batch process should reload the configset into
>> memory due to config manipulations in other processes, especially while git
>> config-batch doesn't have all capabilities from git config. I'll include
>> that in the first version for review, if this RFC leads to positive support.
> 
> Can "git config --batch" write/modify configuration, and if so, when
> does it make its modification available to the outside world?  Would
> we have a "flush" command, or it would pretty much be immediate?

The 'set' command in this series calls methods that reach into repo_config_set_multivar_in_file_gently() which updates the config file as part of that call, including using the .lock file technique to avoid concurrent writes. Looking closely, it appears we do the right thing by parsing the existing file so we only update the new values while allowing any concurrent writes to the file to be respected, even if they disagree with our current view of the config.

Such assignments also update our in-memory view _of those keys_ but it may be a good time to automatically refresh the entire set of config values.

> Can we do without an explicit "reload" command by noticing when
> the configuration files are updated and automatically reload?

This would be an interesting approach, especially for the server concept.

Show 7 quoted lines

> I am trying to figure out how more than one "git config --batch"
> processes can coordinate with each other with minimum overhead.  It
> is not a goal to have multiple such processes, but it would be a
> goal to support multiple clients each of which would benefit from
> having access to the configuration data service (which is why I
> brought up a single and shared long-running daemon as a possible
> alternative earlier).

You're right to bring up these concerns. While 'git config-batch' is intended to be relatively short-lived, users could build tools that keep it alive for a long time. Thus, it is important to consider these automatically-refreshing scenarios. And if we are automatically refreshing, then should we instead consider a client/server model?

I have some things to explore at the highest levels. I will likely start by exploring brian's 'git config -l -z' suggestion to see if that solves the short-term need. But I will consider these other ideas to see where they lead in terms of complexity and potential applications.

Thanks, -Stolee