Re: [PATCH 01/11] config-batch: basic boilerplate of new builtin

From: Kristoffer Haugsbakk <kristofferhaugsbakk@fastmail.com>
Date: Feb 5, 2026, 17:26 UTC
Message-ID: <a1144600-1c94-447f-beaf-8972cd9bdf0f@app.fastmail.com>
In-Reply-To: <6c8b984e-feda-48c6-b67d-80a41343bfc0@gmail.com>

On Thu, Feb 5, 2026, at 15:17, Derrick Stolee wrote:

Show 8 quoted lines

>>>[snip]
>>
>> We have had a bad reputation for having too many commands; would it
>> be better to present it as a new mode of existing "git config"
>> command at the end-user level, I wonder?
>
> Interesting thought. I think we also have a bad reputation of commands
> that are overloaded with too many purposes.

I had a response to that in my head...

> In this case, though, I do think that the modern 'git config <subcommand>'
> model presents some clear boundaries for how the command should behave
> with the 'batch' (or 'server') subcommand. Grouping all config-related
> operations in the same builtin may be ideal.

Which turned out to be exactly about a subcommand. :)

I find the modern subcommand model very easy to navigate. And with much less downsides compared to having dozens of options for one command (or: one particular subcommand to git(1)).

Show 10 quoted lines

>
>> Also after reading patches for a few early steps, I do not quite see
>> "batch"-ness in this protocol; it is strictly "a single request is
>> met with a single response".
>
> The batch-ness is that multiple requests can eventually go to the same
> process. The client could collect multiple commands in a batch and send
> them all without processing the responses one-by-one. This is how it works
> in the tests: a single input file is prepared and all responses are
> scanned after-the-fact.

As a user that makes sense given the existing `--batch` and `--stdin` options.

Show 13 quoted lines

> The back-and-forth mechanism is how the git-credential-manager tool would
> use it, because it dynamically explores certain config keys. For example:
> it checks the deepest possible URL for a specific key then peels away the
> last segment of the URL to see if there is a directory-prefix match in a
> key. (This is the main reason that there are so many requests in this
> application.)
>
> I believe this is similar to how 'git cat-file --batch' or 'git cat-file
> --batch-check' work, which was my inspiration for this word. If we regret
> those names, then I'm happy to move towards a better name.
>
> Thanks,
> -Stolee