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

From: Junio C Hamano <gitster@pobox.com>
Date: Feb 4, 2026, 23:04 UTC
Message-ID: <xmqq5x8cnm93.fsf@gitster.g>
In-Reply-To: <pull.2033.git.1770214803.gitgitgadget@gmail.com>

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

Show 6 quoted lines

> 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?

Show 5 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?

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

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