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

"Derrick Stolee via GitGitGadget" [off-list ref] 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?

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