From: Derrick Stolee <stolee@gmail•com>
To: Junio C Hamano <gitster@pobox•com>,
Derrick Stolee via GitGitGadget <gitgitgadget@gmail•com>
Cc: git@vger•kernel.org, "brian m. carlson" <sandals@crustytoothpaste•net>
Subject: Re: [PATCH 00/11] [RFC] config-batch: a new builtin for tools querying config
Date: Thu, 5 Feb 2026 09:10:55 -0500 [thread overview]
Message-ID: <36bae79b-576f-48f1-b31c-15c3a1f4bce7@gmail.com> (raw)
In-Reply-To: <xmqq5x8cnm93.fsf@gitster.g>
On 2/4/2026 6:04 PM, Junio C Hamano wrote:
> "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.
>> 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.
> 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
next prev parent reply other threads:[~2026-02-05 14:10 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-04 14:19 [PATCH 00/11] [RFC] config-batch: a new builtin for tools querying config Derrick Stolee via GitGitGadget
2026-02-04 14:19 ` [PATCH 01/11] config-batch: basic boilerplate of new builtin Derrick Stolee via GitGitGadget
2026-02-04 23:23 ` Junio C Hamano
2026-02-05 14:17 ` Derrick Stolee
2026-02-05 17:26 ` Kristoffer Haugsbakk
2026-02-05 17:29 ` Kristoffer Haugsbakk
2026-02-06 4:11 ` Jean-Noël Avila
2026-02-04 14:19 ` [PATCH 02/11] config-batch: create parse loop and unknown command Derrick Stolee via GitGitGadget
2026-02-04 23:26 ` Junio C Hamano
2026-02-05 17:30 ` Kristoffer Haugsbakk
2026-02-06 4:15 ` Jean-Noël Avila
2026-02-04 14:19 ` [PATCH 03/11] config-batch: implement get v1 Derrick Stolee via GitGitGadget
2026-02-06 4:41 ` Jean-Noël Avila
2026-02-04 14:19 ` [PATCH 04/11] config-batch: create 'help' command Derrick Stolee via GitGitGadget
2026-02-06 4:49 ` Jean-Noël Avila
2026-02-10 4:20 ` Derrick Stolee
2026-02-04 14:19 ` [PATCH 05/11] config-batch: add NUL-terminated I/O format Derrick Stolee via GitGitGadget
2026-02-05 17:44 ` Kristoffer Haugsbakk
2026-02-06 4:58 ` Jean-Noël Avila
2026-02-04 14:19 ` [PATCH 06/11] docs: add design doc for config-batch Derrick Stolee via GitGitGadget
2026-02-05 17:38 ` Kristoffer Haugsbakk
2026-02-10 4:22 ` Derrick Stolee
2026-02-04 14:19 ` [PATCH 07/11] config: extract location structs from builtin Derrick Stolee via GitGitGadget
2026-02-04 14:20 ` [PATCH 08/11] config-batch: pass prefix through commands Derrick Stolee via GitGitGadget
2026-02-04 14:20 ` [PATCH 09/11] config-batch: add 'set' v1 command Derrick Stolee via GitGitGadget
2026-02-05 17:21 ` Kristoffer Haugsbakk
2026-02-05 18:58 ` Kristoffer Haugsbakk
2026-02-05 19:01 ` Kristoffer Haugsbakk
2026-02-10 4:25 ` Derrick Stolee
2026-02-06 5:04 ` Jean-Noël Avila
2026-02-04 14:20 ` [PATCH 10/11] t1312: create read/write test Derrick Stolee via GitGitGadget
2026-02-04 14:20 ` [PATCH 11/11] config-batch: add unset v1 command Derrick Stolee via GitGitGadget
2026-02-05 17:36 ` Kristoffer Haugsbakk
2026-02-04 23:04 ` [PATCH 00/11] [RFC] config-batch: a new builtin for tools querying config Junio C Hamano
2026-02-05 14:10 ` Derrick Stolee [this message]
2026-02-05 0:04 ` brian m. carlson
2026-02-05 13:52 ` Derrick Stolee
2026-02-10 4:49 ` Derrick Stolee
2026-02-05 14:45 ` Phillip Wood
2026-02-05 17:20 ` Kristoffer Haugsbakk
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=36bae79b-576f-48f1-b31c-15c3a1f4bce7@gmail.com \
--to=stolee@gmail$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
--cc=gitgitgadget@gmail$(echo .)com \
--cc=gitster@pobox$(echo .)com \
--cc=sandals@crustytoothpaste$(echo .)net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox