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

[Derrick Stolee <stolee@gmail.com>]

On 2/5/2026 8:52 AM, Derrick Stolee wrote:
> On 2/4/2026 7:04 PM, brian m. carlson wrote:
>> On 2026-02-04 at 14:19:52, Derrick Stolee via GitGitGadget wrote:

>>>  * Is this a worthwhile feature to add to Git?
>>
>> Git LFS has the same needs, but I believe it can use `git config -l -z`
>> to do that and parse the config options itself.  If this is just config
>> fetching, I'm not sure of the additional utility that such a feature
>> would add.  If that interface _almost_ meets your needs, could we add
>> functionality there instead of a new interface?
> 
> This is a good suggestion to look into as a potentially-easier solution.
After digging into this, I realized that GCM uses Git's --type=<X>
option, which doesn't work with 'git config list'!

Please see a new RFC [1] that adds that feature, though it is a
"breaking" change from previous behavior.

[1] https://lore.kernel.org/git/pull.2044.git.1770698579.gitgitgadget@gmail.com/

There's still some awkwardness in my GCM prototype, as it can
require three commands to query all the types (no type, path, and
book) that are needed. I found that the slowest queries are using
the path type, but only because they are the most frequent ones.

This awkwardness does make me think both of these things:

1. I can get performance boosts to GCM faster by the RFC in [1].

2. Using 'git config list' isn't sufficient to minimize multiple
   processes.

For now, I'll put _this_ RFC down for a little while to pursue
those easier gains. I'll come back again and consider all of the
big-picture considerations, including:

* Make this a subcommand of 'git config'.

* Make this a server that can serve multiple client processes.

* Ensure that all "complicated" options are accounted for.

Thanks,
-Stolee