Re: [PATCH 00/11] [RFC] config-batch: a new builtin for tools querying config
From: Derrick Stolee <hidden>
Date: 2026-02-10 04:49:14
On 2/5/2026 8:52 AM, Derrick Stolee wrote:
On 2/4/2026 7:04 PM, brian m. carlson wrote:quoted
On 2026-02-04 at 14:19:52, Derrick Stolee via GitGitGadget wrote:
quoted
quoted
* 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/ (local) 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