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

[Junio C Hamano <gitster@pobox.com>]

"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?

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