config-batch: a new builtin for tools querying config

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.

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.

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.

From: Derrick Stolee <[email protected]>

Later changes will document, implement, and test this new builtin. For now, this serves as the latest example of the minimum boilerplate to introduce a new builtin.

Recently, we updated the comment in builtin.h about how to create a new builtin, but failed to mention the required change to meson.build files for some CI builds to pass. Fix that oversight.

Signed-off-by Derrick Stolee <[email protected]>

---

+#define COMMAND_COUNT ((size_t)(sizeof(commands) / sizeof(*commands)))

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.

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.

This RFC adds git config-batch with a protocol over stdin/stdout for executing multiple config queries. The implementation has a limited set of potential queries, but also creates a model for compatibility for tools to automatically adapt to different Git versions.

I'm submitting this as an RFC before I've polished all of the details because I want to make sure I'm going down a good direction. Please focus feedback in these questions:

* Is this a worthwhile feature to add to Git?

Quoted 11 lines · Derrick Stolee via GitGitGadget

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.

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.

Quoted 1 line

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

If you need to set many keys, I'm curious as to why that is.

Quoted 4 lines · Derrick Stolee via GitGitGadget

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.

Quoted 6 lines

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?

Quoted 5 lines

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

Quoted 10 lines · Derrick Stolee via GitGitGadget

From: Derrick Stolee <[email protected]>

Later changes will document, implement, and test this new builtin. For now, this serves as the latest example of the minimum boilerplate to introduce a new builtin.

Recently, we updated the comment in builtin.h about how to create a new builtin, but failed to mention the required change to meson.build files for some CI builds to pass. Fix that oversight.

Quoted 2 lines

Signed-off-by Derrick Stolee <[email protected]>

---

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?

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

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.

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.

This RFC adds git config-batch with a protocol over stdin/stdout for executing multiple config queries. The implementation has a limited set of potential queries, but also creates a model for compatibility for tools to automatically adapt to different Git versions.

I'm submitting this as an RFC before I've polished all of the details because I want to make sure I'm going down a good direction. Please focus feedback in these questions:

* Is this a worthwhile feature to add to Git?

* Is this a reasonable protocol for stdin/stdout?

Each command has an associated version, in case we need to expand or alter the functionality in the future. This includes the potential to deprecate and remove certain versions that we no longer want to support, such as replacing set version 1 with a version 2 and making version 1 no longer available. I do hope that we will mostly be able to move with new command names, such as a set-all command including the options for git config set --all ... instead of increasing the version of the set command.

There is a -z option that changes the command interface to use NUL-terminated strings. Two NULs specify a command boundary, which promotes compatibility with a caller that sends an unknown command.

However, this
means that we cannot specify an empty string as a token within a command unless we add more data.

This format uses <N>:<string> to provide the
integer <N> which specifies the length of <string>. This is a little cumbersome, but the format is intended for tools, not humans.

I have a test integration with git-credential-manager available [1] for testing. This includes a model for interacting with git config-batch in a compatible way that will respond to certain features not being available:

1. If git config-batch fails immediately, then all queries are handled by git config.
2. If git config-batch starts without failure, then the first query is for the help command.
3. As queries come to the config system, the query is checked against the available commands advertised by git config-batch. If the appropriate command is available, then the query is made in that process. If not, then the query uses the existing git config command.

I have a few concerns with this implementation that I'd like to improve before submitting a version for full review. I list them here so you can see the flaws that I already see, but also so you can add to this list:

* The use of arg:<arg> to specify an optional argument creates the inability to submit a value that starts with arg:. Consider alternative ways to specify arguments or to specify that the remaining data in the command (including spaces) is a final positional argument.

* In general, I found myself implementing behavior based on the deprecated forms of git config that use the --get or --unset style arguments instead of git config (set|unset|get) subcommands. It's worth making sure that any references to equivalent git config commands use the new modes.
* I need to add an --[no-]includes option as a command-line argument that signals whether include sections should be followed. I don't believe this should be specified on a per-command basis, but I'm open to suggestions.
* I have an early draft of a technical document detailing the plan for this builtin. It has some lists of intended future commands that have not been implemented. This would also be a good place to document any parsing APIs built to help contributors adding to this builtin.

Thanks, -Stolee

Derrick Stolee (11):
config-batch: basic boilerplate of new builtin
config-batch: create parse loop and unknown command
config-batch: implement get v1
config-batch: create 'help' command
config-batch: add NUL-terminated I/O format
docs: add design doc for config-batch
config: extract location structs from builtin
config-batch: pass prefix through commands
config-batch: add 'set' v1 command
t1312: create read/write test
config-batch: add unset v1 command

  .gitignore                                |   1 +
  Documentation/git-config-batch.adoc       | 214 ++++++
  Documentation/meson.build                 |   1 +
  Documentation/technical/config-batch.adoc |  70 ++
  Makefile                                  |   1 +
  builtin.h                                 |   7 +
  builtin/config-batch.c                    | 772 ++++++++++++++++++++++
  builtin/config.c                          | 117 +---
  command-list.txt                          |   1 +
  config.c                                  | 116 ++++
  config.h                                  |  26 +
  git.c                                     |   1 +
  meson.build                               |   1 +
  t/meson.build                             |   1 +
  t/t1312-config-batch.sh                   | 372 +++++++++++
  15 files changed, 1592 insertions(+), 109 deletions(-)

create mode 100644 Documentation/git-config-batch.adoc create mode 100644 Documentation/technical/config-batch.adoc create mode 100644 builtin/config-batch.c
create mode 100755 t/t1312-config-batch.sh

base-commit: 83a69f19359e6d9bc980563caca38b2b5729808c
Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-2033%2Fderrickstolee%2Fbatched-config-v1
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-2033/derrickstolee/batched-config-v1
Pull-Request: https://github.com/gitgitgadget/git/pull/2033

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. [snip]

+'git config-batch' <options>

(quoted diff) +3 -0

+
+DESCRIPTION
+-----------
[snip]

Quoted 5 lines

Quoted 1 line

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

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.

Quoted 4 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.

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

+'git config-batch' <options>

Documentation/git-config-batch.adoc new file +3 -0

+
+DESCRIPTION
+-----------
[snip]

+
[snip]

From: Derrick Stolee <[email protected]>

Add a new 'unset' command with version 1 that mimics 'git config --unset' with optional regex pattern or '--fixed-value' arguments.

Signed-off-by Derrick Stolee <[email protected]>

---
 Documentation/git-config-batch.adoc | 28 ++++++++
 builtin/config-batch.c              | 99 +++++++++++++++++++++++++++++
 t/t1312-config-batch.sh             | 61 ++++++++++++++++--
 3 files changed, 181 insertions(+), 7 deletions(-)

Documentation/git-config-batch.adoc +6 -0

index feec85c4ef..bdfd872d65 100644
@@ -135,6 +135,34 @@ set 1 success <scope> <key> <value>
 set 1 failed <scope> <key> <value>
 ------------
 
+`unset` version 1::
+	The `unset` command removes a single value from a config file.
+	It specifies which file by a `<scope>` parameter from among
+	`system`, `global`, `local`, and `worktree`. The `<key>` is the
+	next positional argument. There could be two additional
+	arguments used to match specific config values, where the first

Documentation/git-config-batch.adoc +12 -0

+with the additional arguments of `<value-pattern>` if `arg:regex` is
+given or `--fixed-value <value>` if `arg:fixed-value` is given.
++
+The response of these commands will include a `success` message
+if matched values are found and removed as expected or `failed` if an
+unexpected failure occurs:
++
+------------
+unset 1 success <scope> <key>
+unset 1 failed <scope> <key>
+------------
+
 NUL-Terminated Format
 ~~~~~~~~~~~~~~~~~~~~~
 

builtin/config-batch.c +23 -0

index 373b0cad47..25a942ba61 100644
@@ -17,6 +17,7 @@ static int zformat = 0;
 #define HELP_COMMAND "help"
 #define GET_COMMAND "get"
 #define SET_COMMAND "set"
+#define UNSET_COMMAND "unset"
 #define COMMAND_PARSE_ERROR "command_parse_error"
 
 static void print_word(const char *word, int start)

@@ -445,6 +446,99 @@ cleanup:
 	return res;
 }
 
+/**
+ * 'unset' command, version 1.
+ *
+ * Positional arguments should be of the form:
+ *
+ * [0] scope ("system", "global", "local", or "worktree")
+ * [1] config key
+ * [2] config value
+ * [3*] match ("regex", "fixed-value")
+ * [4*] value regex OR value string
+ *
+ * [N*] indicates optional parameters that are not needed.
+ */
+static int unset_command_1(struct repository *repo,
+			 const char *prefix,
+			 char *data,
+			 size_t data_len)
+{
+	int res = 0, err = 0, flags = 0;
+	enum config_scope scope = CONFIG_SCOPE_UNKNOWN;
+	char *token = NULL, *key = NULL, *value_pattern = NULL;
+	size_t token_len;

builtin/config-batch.c +3 -0

+
+	if (!parse_token(&data, &data_len, &key, &err) || err)
+		goto parse_error;
[snip]

Documentation/technical/config-batch.adoc new file +8 -0

+
+`git config set [--<scope>] <key> <value>`::
+	It will be desirable to set a config key at a given scope as a
+	single value, replacing the current value at that scope, if it
+	exists and is a single value. A `set` command could satisfy this
+	purpose.
+
+`git config set --all [<value-pattern>|--fixed-value=<fixedvalue>]

<key> <value>`::

(quoted diff) +1 -0

+	When replacing multiple values, it may be necessary to have a

different

Documentation/technical/config-batch.adoc new file +7 -0

+	output describing the places those values were set, so it may need to
+	be implemented via a `set-all` command to differentiate from a `set`
+	command.
+
+`git config unset <key>`::
+
+`git config unset --all [<value-pattern>|--fixed-value=<fixedvalue>]

<key>`::

Documentation/technical/config-batch.adoc new file +6 -1

+
+`git config get --all --rexexp <key-pattern> [<value-options>]`::
+
+`--replace-all` option::
+
+`--type=<type>` option::
--

gitgitgadget

builtin/config-batch.c +5 -0

+		printf("%s", word);
+	else
+		printf(" %s", word);
+}
+
[snip]

Review

Quoted 13 lines · Derrick Stolee via GitGitGadget

[snip]

(quoted diff) +6 -0

+git-config-batch(1)
+===================
+
+NAME
+----
+git-config-batch - Get and set options using machine-parseable

interface

(quoted diff) +5 -0

+
+
+SYNOPSIS
+--------
+[verse]

There’s work lead by Jean-Noël Avila to use [synopsis] instead of [verse].[1] Would it make sense to start off with that?

† 1: E.g. acffc5e9 (doc: convert git-remote to synopsis style, 2025-12-20)

Review

Quoted 5 lines

+'git config-batch' <options>

(quoted diff) +3 -0

+
+DESCRIPTION
+-----------
[snip]

[snip]

config.c +13 -0

+int location_options_set_scope(struct config_location_options *opts,
+			       enum config_scope scope)
+{
+	switch (scope) {
+	case CONFIG_SCOPE_SYSTEM:
+		opts->use_system_config = 1;
+		break;
+
+	case CONFIG_SCOPE_GLOBAL:
+		opts->use_global_config = 1;
+		break;
+
+	case CONFIG_SCOPE_LOCAL:

config.c +4 -0

+
+	return 0;
+}
+
[snip]

From: Derrick Stolee <[email protected]>

Later changes will document, implement, and test this new builtin. For now, this serves as the latest example of the minimum boilerplate to introduce a new builtin.

Recently, we updated the comment in builtin.h about how to create a new builtin, but failed to mention the required change to meson.build files for some CI builds to pass. Fix that oversight.

Signed-off-by Derrick Stolee <[email protected]>

---
 .gitignore                          |  1 +
 Documentation/git-config-batch.adoc | 24 +++++++++++++++++++++++
 Documentation/meson.build           |  1 +
 Makefile                            |  1 +
 builtin.h                           |  7 +++++++
 builtin/config-batch.c              | 30 +++++++++++++++++++++++++++++
 command-list.txt                    |  1 +
 git.c                               |  1 +
 meson.build                         |  1 +
 t/meson.build                       |  1 +
 t/t1312-config-batch.sh             | 12 ++++++++++++
 11 files changed, 80 insertions(+)
 create mode 100644 Documentation/git-config-batch.adoc
 create mode 100644 builtin/config-batch.c
 create mode 100755 t/t1312-config-batch.sh

.gitignore +1 -0

index 78a45cb5be..42640b5e24 100644
@@ -44,6 +44,7 @@
 /git-commit-graph
 /git-commit-tree
 /git-config
+/git-config-batch
 /git-count-objects
 /git-credential
 /git-credential-cache

Documentation/git-config-batch.adoc new file +2 -0

new file mode 100644
index 0000000000..dfa0bd83e2
@@ -0,0 +1,24 @@
+git-config-batch(1)
+===================

From: Derrick Stolee <[email protected]>

As we build new features in the config-batch command, we define the plaintext protocol with line-by-line output and responses. To think to the future, we make sure that the protocol has a clear way to respond to an unknown command or an unknown version of that command.

As some commands will allow the final argument to contain spaces or even be able to parse "\ " as a non-split token, we only provide the remaining line as data.

Signed-off-by Derrick Stolee <[email protected]>

---
 Documentation/git-config-batch.adoc |  23 ++++-
 builtin/config-batch.c              | 133 +++++++++++++++++++++++++++-
 t/t1312-config-batch.sh             |  19 +++-
 3 files changed, 170 insertions(+), 5 deletions(-)

Documentation/git-config-batch.adoc +1 -1

index dfa0bd83e2..9ca04b0c1e 100644
@@ -13,7 +13,28 @@ SYNOPSIS
 
 DESCRIPTION
 -----------
-TODO
+Tools frequently need to change their behavior based on values stored in

From: Derrick Stolee <[email protected]>

The 'get' command for the 'git config-batch' builtin is the first command and is currently at version 1. It returns at most one value, the same as 'git config --get <key>' with optional value-based filtering.

The documentation and tests detail the specifics of how to format requests of this format and how to parse the results.

Future versions could consider multi-valued responses or regex-based key matching.

For the sake of incremental exploration of the potential in the 'git config-batch' command, this is the only implementation being presented in the first patch series.

Future extensions could include a '-z' parameter that uses NUL bytes in the command and output format to allow for spaces or newlines in the input or newlines in the output.

Signed-off-by Derrick Stolee <[email protected]>

---
 Documentation/git-config-batch.adoc |  53 +++++-
 builtin/config-batch.c              | 251 +++++++++++++++++++++++++++-
 config.h                            |   3 +
 t/t1312-config-batch.sh             | 101 +++++++++++
 4 files changed, 405 insertions(+), 3 deletions(-)

Documentation/git-config-batch.adoc +0 -0

index 9ca04b0c1e..31dd42f481 100644

Documentation/git-config-batch.adoc +5 -0

+pair in the standard config order by scope and sequence within each scope.
++
+If a key-value pair is found, then the following output is given:
++
+------------

From: Derrick Stolee <[email protected]>

Tools that use the 'git config-batch' tool will want to know which commands are available in the current Git version. Having a 'help' command assists greatly to give a clear set of available commands and their versions.

Signed-off-by Derrick Stolee <[email protected]>

---
 Documentation/git-config-batch.adoc | 17 +++++++++++++++
 builtin/config-batch.c              | 32 +++++++++++++++++++++++++++++
 t/t1312-config-batch.sh             | 13 ++++++++++++
 3 files changed, 62 insertions(+)

Documentation/git-config-batch.adoc +0 -0

index 31dd42f481..1fff68a13c 100644

Documentation/git-config-batch.adoc +7 -0

++
+------------
+help 1 count 2
+help 1 help 1
+help 1 get 1
+------------
+
 `get` version 1::
 	The `get` command searches the config key-value pairs within a
 	given `<scope>` for values that match the fixed `<key>` and

From: Derrick Stolee <[email protected]>

When using automated tools, it is critical to allow for input/output formats that include special characters such as spaces and newlines. While the existing protocol for 'git config-batch' is human-readable and has some capacity for some spaces in certain positions, it is not available for spaces in the config key or newlines in the config values.

Add the '-z' option to signal the use of NUL-terminated strings. To understand where commands end regardless of potential future formats, use two NUL bytes in a row to terminate a command. To allow for empty string values, each token is provided in a <length>:<value> format, making "0:" the empty string value.

Update the existing 'help' and 'get' commands to match this format. Create helper methods that make it easy to parse and print in both formats simultaneously.

Signed-off-by Derrick Stolee <[email protected]>

---
 Documentation/git-config-batch.adoc |  57 ++++++++-
 builtin/config-batch.c              | 188 +++++++++++++++++++++++++---
 t/t1312-config-batch.sh             |  69 ++++++++++
 3 files changed, 293 insertions(+), 21 deletions(-)

Documentation/git-config-batch.adoc +0 -0

index 1fff68a13c..3c9a3bb763 100644

Documentation/git-config-batch.adoc +4 -0

+	format instead of the space and newline format. This format is
+	useful when the strings involved may include spaces or newlines.
+	See PROTOCOL for more details.
+
 PROTOCOL
 --------
 By default, the protocol uses line feeds (`LF`) to signal the end of a

@@ -41,13 +50,13 @@ These are the commands that are currently understood:
 `help` version 1::
 	The `help` command lists the currently-available commands in
 	this version of Git. The output is multi-line, but the first

Documentation/git-config-batch.adoc +4 -0

 +
 ------------
 help 1 count 2

@@ -102,6 +111,48 @@ get 1 missing <key> [<value-pattern>|<value>]
 where `<value-pattern>` or `<value>` is only supplied if provided in
 the command.
 
+NUL-Terminated Format
+~~~~~~~~~~~~~~~~~~~~~
+
+When `-z` is given, the protocol changes in some structural ways.

Documentation/git-config-batch.adoc +28 -0

+imply that "`0:`" is the representation of an empty string, if relevant.
+
+The decimal representation must have at most five numerals, thus the
+maximum length of a string token can have 99999 characters.
+
+For example, the `get` command, version 1, could have any of the
+following forms:
+
+------------
+3:get NUL 1:1 NUL 5:local NUL 14:key.with space NUL NUL
+3:get NUL 1:1 NUL 9:inherit NUL 8:test.key NUL 9:arg:regex NUL 6:.*\ .* NUL NUL
+3:get NUL 1:1 NUL 6:global NUL 8:test.key NUL 15:arg:fixed-value NUL 3:a b NUL NUL
+------------
+
+The output is modified similarly, such as the following output examples,
+as if the input has a parse error, a valid `help` command, a `get`
+command that had a match, and a `get` command that did not match.
+
+------------
+15:unknown_command NUL NUL
+4:help NUL 1:1 NUL 5:count NUL 1:2 NUL NUL
+4:help NUL 1:1 NUL 4:help NUL 1:1 NUL NUL
+4:help NUL 1:1 NUL 3:get NUL 1:1 NUL NUL
+3:get NUL 1:1 NUL 5:found NUL 8:test.key NUL 5:value NUL NUL
+3:get NUL 1:1 NUL 7:missing NUL 8:test.key NUL NUL
+------------
+
+
 SEE ALSO
 --------
 linkgit:git-config[1]

From: Derrick Stolee <[email protected]>

This new command is intended for single-value assignments to a specific chosen scope. More complicated versions of the 'git config set' command will be incorporated into future commands.

Signed-off-by Derrick Stolee <[email protected]>

---
 Documentation/git-config-batch.adoc | 24 ++++++++
 builtin/config-batch.c              | 71 ++++++++++++++++++++++
 config.c                            | 27 +++++++++
 config.h                            |  3 +
 t/t1312-config-batch.sh             | 94 ++++++++++++++++++++++++++++-
 5 files changed, 217 insertions(+), 2 deletions(-)

Documentation/git-config-batch.adoc +0 -0

index 3c9a3bb763..feec85c4ef 100644

Documentation/git-config-batch.adoc +0 -0

 NUL-Terminated Format
 ~~~~~~~~~~~~~~~~~~~~~
 

Le 04/02/2026 à 15:19, Derrick Stolee via GitGitGadget a écrit :

Quoted 2 lines

++
+Here is the currentl output of the help text at the latest version:

It may not be wise to talk about the "latest version". If the manpages and the git command are out of sync (the user compiles her own git version, but does not update the man pages), this may be confusing.

Is this specification of version critical to the understanding?

Documentation/technical/config-batch.adoc line 48

Quoted 4 lines · Derrick Stolee via GitGitGadget

+git config list [--<scope>]::

Documentation/technical/config-batch.adoc new file +3 -0

+	Getting all values, regardless of config key, would require a
+	multi-valued output similar to the `help` command. This tool will
+	likely assume advanced options such as `--show-origin`.

What does it mean to assume options?

Documentation/git-config-batch.adoc get 1 missing <key> [<value-pattern>|<value>] · line 125

Quoted 13 lines · Derrick Stolee via GitGitGadget

[snip]
+set version 1::

Documentation/git-config-batch.adoc +11 -0

+	The `set` command writes a single key-value pair to a config
+	file. It specifies which file by a `<scope>` parameter from
+	among `system`, `global`, `local`, and `worktree`. The `<key>`
+	is the next positional argument. The remaining data in the line
+	is provided as the `<value>` to assign the config.
++
+------------
+set 1 <scope> <key> <value>
+------------
++
+These uses will match the behavior of `git config --set --<scope> <key>

--set doesn’t exist. I think you meant set.

Is there support for a user-provided file? (git config --file=...)

Quoted 4 lines · brian m. carlson

Quoted 1 line · Derrick Stolee via GitGitGadget

* Is this a worthwhile feature to add to Git?

Quoted 5 lines

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.