Skip to content
Open
Show file tree
Hide file tree
Changes from 2 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions .gitignore
Original file line number Diff line number Diff line change
Expand Up @@ -44,6 +44,7 @@
/git-commit-graph
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Junio C Hamano wrote on the Git mailing list (how to reply to this email):

"Derrick Stolee via GitGitGadget" <gitgitgadget@gmail.com> writes:

> From: Derrick Stolee <stolee@gmail.com>
>
> 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 <stolee@gmail.com>
> ---

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

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Derrick Stolee wrote on the Git mailing list (how to reply to this email):

On 2/4/2026 6:23 PM, Junio C Hamano wrote:
> "Derrick Stolee via GitGitGadget" <gitgitgadget@gmail.com> writes:
> 
>> From: Derrick Stolee <stolee@gmail.com>
>>
>> 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 <stolee@gmail.com>
>> ---
> 
> 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. 

> 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

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"Kristoffer Haugsbakk" wrote on the Git mailing list (how to reply to this email):

On Thu, Feb 5, 2026, at 15:17, Derrick Stolee wrote:
>>>[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)).

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

> 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

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"Kristoffer Haugsbakk" wrote on the Git mailing list (how to reply to this email):

On Wed, Feb 4, 2026, at 15:19, Derrick Stolee via GitGitGadget wrote:
>[snip]
> +git-config-batch(1)
> +===================
> +
> +NAME
> +----
> +git-config-batch - Get and set options using machine-parseable
> interface
> +
> +
> +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)

> +'git config-batch' <options>
> +
> +DESCRIPTION
> +-----------
>[snip]

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Jean-Noël Avila wrote on the Git mailing list (how to reply to this email):

Le 04/02/2026 à 15:19, Derrick Stolee via GitGitGadget a écrit :
> From: Derrick Stolee <stolee@gmail.com>
> 
> 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 <stolee@gmail.com>
> ---
>  .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
> 
> diff --git a/.gitignore b/.gitignore
> index 78a45cb5be..42640b5e24 100644
> --- a/.gitignore
> +++ b/.gitignore
> @@ -44,6 +44,7 @@
>  /git-commit-graph
>  /git-commit-tree
>  /git-config
> +/git-config-batch
>  /git-count-objects
>  /git-credential
>  /git-credential-cache
> diff --git a/Documentation/git-config-batch.adoc b/Documentation/git-config-batch.adoc
> new file mode 100644
> index 0000000000..dfa0bd83e2
> --- /dev/null
> +++ b/Documentation/git-config-batch.adoc
> @@ -0,0 +1,24 @@
> +git-config-batch(1)
> +===================
> +
> +NAME
> +----
> +git-config-batch - Get and set options using machine-parseable interface
> +
> +
> +SYNOPSIS
> +--------
> +[verse]
> +'git config-batch' <options>

For this new manual page, please use the synopsis style:

[synopsis]
git config-batch <options>

Thanks

/git-commit-tree
/git-config
/git-config-batch
/git-count-objects
/git-credential
/git-credential-cache
Expand Down
45 changes: 45 additions & 0 deletions Documentation/git-config-batch.adoc
Original file line number Diff line number Diff line change
@@ -0,0 +1,45 @@
git-config-batch(1)
===================

NAME
----
git-config-batch - Get and set options using machine-parseable interface


SYNOPSIS
--------
[verse]
'git config-batch' <options>

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Junio C Hamano wrote on the Git mailing list (how to reply to this email):

"Derrick Stolee via GitGitGadget" <gitgitgadget@gmail.com> writes:

> +static struct command commands[] = {
> +	/* unknown_command must be last. */
> +	{
> +		.name = "",
> +		.fn   = unknown_command,
> +	},
> +};

A useful trick is to deliberately omit the trailing comma after the
element that MUST be last.  You did that for the __NR enum element
in a later step.

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

Isn't this ARRAY_SIZE(commands)?


> +	while (!(res = process_command(repo)));

Please write an empty statement on its own line, i.e.

	while (!(res = process_command(repo)))
		;

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"Kristoffer Haugsbakk" wrote on the Git mailing list (how to reply to this email):

On Wed, Feb 4, 2026, at 15:19, Derrick Stolee via GitGitGadget wrote:
>[snip]
>  DESCRIPTION
>  -----------
> -TODO
> +Tools frequently need to change their behavior based on values stored in
> +Git's configuration files. These files may have complicated conditions
> +for including extra files, so it is difficult to produce an independent
> +parser. To avoid executing multiple processes to discover or modify
> +multiple configuration values, the `git config-batch` command allows a
> +single process to handle multiple requests using a machine-parseable
> +interface across `stdin` and `stdout`.

I really like that the doc itself motivates the command. Many man pages
on git(1) just tells you what it does as if you would already know why
you need it.

> +
>[snip]

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Jean-Noël Avila wrote on the Git mailing list (how to reply to this email):

Le 04/02/2026 à 15:19, Derrick Stolee via GitGitGadget a écrit :
> From: Derrick Stolee <stolee@gmail.com>
> 
> 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 <stolee@gmail.com>
> ---
>  Documentation/git-config-batch.adoc |  23 ++++-
>  builtin/config-batch.c              | 133 +++++++++++++++++++++++++++-
>  t/t1312-config-batch.sh             |  19 +++-
>  3 files changed, 170 insertions(+), 5 deletions(-)
> 
> diff --git a/Documentation/git-config-batch.adoc b/Documentation/git-config-batch.adoc
> index dfa0bd83e2..9ca04b0c1e 100644
> --- a/Documentation/git-config-batch.adoc
> +++ b/Documentation/git-config-batch.adoc
> @@ -13,7 +13,28 @@ SYNOPSIS
>  
>  DESCRIPTION
>  -----------
> -TODO
> +Tools frequently need to change their behavior based on values stored in
> +Git's configuration files. These files may have complicated conditions
> +for including extra files, so it is difficult to produce an independent
> +parser. To avoid executing multiple processes to discover or modify
> +multiple configuration values, the `git config-batch` command allows a
> +single process to handle multiple requests using a machine-parseable
> +interface across `stdin` and `stdout`.
> +
> +PROTOCOL
> +--------
> +By default, the protocol uses line feeds (`LF`) to signal the end of a

Characters are typefaced as placeholders: _LF_

> +command over `stdin` or a response over `stdout`.
> +
> +The protocol will be extended in the future, and consumers should be
> +resilient to older Git versions not understanding the latest command
> +set. Thus, if the Git version includes the `git config-batch` builtin
> +but doesn't understand an input command, it will return a single line
> +response:
> +
> +```
> +unknown_command LF> +```
>  
This is Markdown. For Asciidoc, use code block:

----
unknown_command LF
----




DESCRIPTION
-----------
Tools frequently need to change their behavior based on values stored in
Git's configuration files. These files may have complicated conditions
for including extra files, so it is difficult to produce an independent
parser. To avoid executing multiple processes to discover or modify
multiple configuration values, the `git config-batch` command allows a
single process to handle multiple requests using a machine-parseable
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"Kristoffer Haugsbakk" wrote on the Git mailing list (how to reply to this email):

On Wed, Feb 4, 2026, at 15:19, Derrick Stolee via GitGitGadget wrote:
> From: Derrick Stolee <stolee@gmail.com>
>[snip]
> +OPTIONS
> +-------
> +
> +`-z`::
> +	If specified, then use the NUL-terminated input and output

It seems to me that using the imperative mood for options might be
preferred now. Like:

    Use NUL-terminated input and output...

See: https://lore.kernel.org/git/bcd6fcd1190fe21c667b5253a4a33b833e658609.1769462744.git.gitgitgadget@gmail.com/

>[snip]
> -	line provides the count of possible commands via `help count <N>`.
> -	The next `<N>` lines are of the form `help <command> <version>`
> +	line provides the count of possible commands via `help 1 count <N>`.
> +	The next `<N>` lines are of the form `help 1 <command> <version>`
>  	to state that this Git version supports that `<command>` at
>  	version `<version>`. Note that the same command may have multiple
>  	available versions.
>  +
> -Here is the currentl output of the help text at the latest version:
> +Here is the current output of the help text at the latest version:

Innocent intra-series typofix.

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

It might flow better with “Option `-z` changes the protocol...” ?

I don’t know how usual it is to say “Option <x>”.

>[snip]
> +static void print_word(const char *word, int start)
> +{
> +	if (zformat) {
> +		printf("%"PRIu32":%s", (uint32_t)strlen(word), word);
> +		fputc(0, stdout);
> +	} else if (start)

All of the arms should get braces here.

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

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Jean-Noël Avila wrote on the Git mailing list (how to reply to this email):

Le 04/02/2026 à 15:19, Derrick Stolee via GitGitGadget a écrit :
> From: Derrick Stolee <stolee@gmail.com>
> 
> 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 <stolee@gmail.com>
> ---
>  Documentation/git-config-batch.adoc |  57 ++++++++-
>  builtin/config-batch.c              | 188 +++++++++++++++++++++++++---
>  t/t1312-config-batch.sh             |  69 ++++++++++
>  3 files changed, 293 insertions(+), 21 deletions(-)
> 
> diff --git a/Documentation/git-config-batch.adoc b/Documentation/git-config-batch.adoc
> index 1fff68a13c..3c9a3bb763 100644
> --- a/Documentation/git-config-batch.adoc
> +++ b/Documentation/git-config-batch.adoc
> @@ -21,6 +21,15 @@ multiple configuration values, the `git config-batch` command allows a
>  single process to handle multiple requests using a machine-parseable
>  interface across `stdin` and `stdout`.
>  
> +OPTIONS
> +-------
> +
> +`-z`::
> +	If specified, then use the NUL-terminated input and output

This boilerplate preliminary does not convey information, it is simpler
to just jump to the action performed by the option:

Use the _NUL_-terminated input and output…

> +	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
> -	line provides the count of possible commands via `help count <N>`.
> -	The next `<N>` lines are of the form `help <command> <version>`
> +	line provides the count of possible commands via `help 1 count <N>`.
> +	The next `<N>` lines are of the form `help 1 <command> <version>`
>  	to state that this Git version supports that `<command>` at
>  	version `<version>`. Note that the same command may have multiple
>  	available versions.
>  +
> -Here is the currentl output of the help text at the latest version:
> +Here is the current output of the help text at the latest version:

OK, the typo was fixed here.

>  +
>  ------------
>  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.
> +
> +First, each command is terminated with two NUL bytes, providing a clear
> +boundary between commands regardless of future possibilities of new
> +command formats.
> +
> +Second, any time that a space _would_ be used to partition tokens in a
> +command, a NUL byte is used instead. Further, each token is prefixed
> +with `<N>:` where `<N>` is a decimal representation of the length of
> +the string between the `:` and the next NUL byte. Any disagreement in
> +these lengths is treated as a parsing error. This use of a length does

I thought this length encoding was used to allow _NUL_ in the config
values. But here it is considered a parse error.

> +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]

interface across `stdin` and `stdout`.

PROTOCOL
--------
By default, the protocol uses line feeds (`LF`) to signal the end of a
command over `stdin` or a response over `stdout`.

The protocol will be extended in the future, and consumers should be
resilient to older Git versions not understanding the latest command
set. Thus, if the Git version includes the `git config-batch` builtin
but doesn't understand an input command, it will return a single line
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Jean-Noël Avila wrote on the Git mailing list (how to reply to this email):

Le 04/02/2026 à 15:19, Derrick Stolee via GitGitGadget a écrit :
> From: Derrick Stolee <stolee@gmail.com>
> 
> 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 <stolee@gmail.com>
> ---
>  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(-)
> 
> diff --git a/Documentation/git-config-batch.adoc b/Documentation/git-config-batch.adoc
> index 9ca04b0c1e..31dd42f481 100644
> --- a/Documentation/git-config-batch.adoc
> +++ b/Documentation/git-config-batch.adoc
> @@ -32,9 +32,58 @@ set. Thus, if the Git version includes the `git config-batch` builtin
>  but doesn't understand an input command, it will return a single line
>  response:
>  
> -```
> +------------
>  unknown_command LF
> -```
> +------------
> +

OK, the change to Asciidoc code block is done here. Would it be possible
to push it up at the introduction of these lines?

> +These are the commands that are currently understood:
> +
> +`get` version 1::
> +	The `get` command searches the config key-value pairs within a
> +	given `<scope>` for values that match the fixed `<key>` and

The rendering of these is correct due to the synopsis formatter, but we
usually prefer to use the direct formatting for placeholders: _<scope>_,
_<key>_,…

> +	filters the resulting value based on an optional `<value-filter>`.
> +	This can either be a regex or a fixed value. The command format
> +	is one of the following formats:
> ++
> +------------
> +get 1 <scope> <key>
> +get 1 <scope> <key> arg:regex <value-pattern>
> +get 1 <scope> <key> arg:fixed-value <value>
> +------------
> ++

If you are using synopsis style in the block, with the upcoming change
of synopsis style block[1], you can format it:

[synopsis]
------------
get 1 <scope> <key>
get 1 <scope> <key> arg:regex <value-pattern>
get 1 <scope> <key> arg:fixed-value <value>
------------

> +The `<scope>` value can be one of `inherited`, `system`, `global`,
> +`local`, `worktree`, `submodule`, or `command`. If `inherited`, then all
> +config key-value pairs will be considered regardless of scope. Otherwise,
> +only the given scope will be considered.
> ++
> +If no optional arguments are given, then the value will not be filtered
> +by any pattern matching. If `arg:regex` is specified, then the rest of
> +the line is considered a single string, `<value-pattern>`, and is
> +interpreted as a regular expression for matching against stored values,
> +similar to specifying a value to `get config --get <key> "<value-pattern>"`.
> +If `arg:fixed-value` is specified, then the rest of the line is
> +considered a single string, `<value>`, and is checked for an exact
> +match against the key-value pairs, simmilar to `git config --get <key>

similar

> +--fixed-value "<value>"`.
> ++

Here I would use a sub definition list for each matching type, instead
of long running description paragraph.

optional arguments can be specified:

no optional arguments;;
the value will not be filteredby any pattern matching.
`arg:regex <value-pattern>`;;
`<value-pattern>` is interpreted as a regular expression for matching
against stored values, similar to specifying a value to `get config
--get <key> "<value-pattern>"`.
`arg:fixed-value <value>`;;
`<value>` is checked for an exact match against the key-value pairs,
similar to `git config --get <key>`.

> +At mmost one key-value pair is returned, that being the last key-value

At most

> +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:
> ++
> +------------
> +get 1 found <key> <scope> <value>
> +------------
> ++
> +If no matching key-value pair is found, then the following output is
> +given:
> ++
> +------------
> +get 1 missing <key> [<value-pattern>|<value>]
> +------------
> ++

Please also apply synopsis block style.

> +where `<value-pattern>` or `<value>` is only supplied if provided in
> +the command.
>  
>  SEE ALSO
>  --------

[1]:
https://lore.kernel.org/git/6a2b94e720862fa07fe9463ebf7f7beaa9a1ccd4.1770351146.git.gitgitgadget@gmail.com/T/#u

response:

```
unknown_command LF
```

SEE ALSO
--------
linkgit:git-config[1]

GIT
---
Part of the linkgit:git[1] suite
1 change: 1 addition & 0 deletions Documentation/meson.build
Original file line number Diff line number Diff line change
Expand Up @@ -29,6 +29,7 @@ manpages = {
'git-commit-tree.adoc' : 1,
'git-commit.adoc' : 1,
'git-config.adoc' : 1,
'git-config-batch.adoc' : 1,
'git-count-objects.adoc' : 1,
'git-credential-cache--daemon.adoc' : 1,
'git-credential-cache.adoc' : 1,
Expand Down
1 change: 1 addition & 0 deletions Makefile
Original file line number Diff line number Diff line change
Expand Up @@ -1390,6 +1390,7 @@ BUILTIN_OBJS += builtin/commit-graph.o
BUILTIN_OBJS += builtin/commit-tree.o
BUILTIN_OBJS += builtin/commit.o
BUILTIN_OBJS += builtin/config.o
BUILTIN_OBJS += builtin/config-batch.o
BUILTIN_OBJS += builtin/count-objects.o
BUILTIN_OBJS += builtin/credential-cache--daemon.o
BUILTIN_OBJS += builtin/credential-cache.o
Expand Down
7 changes: 7 additions & 0 deletions builtin.h
Original file line number Diff line number Diff line change
Expand Up @@ -68,12 +68,18 @@
*
* . Add `builtin/foo.o` to `BUILTIN_OBJS` in `Makefile`.
*
* . Add 'builtin/foo.c' to the 'builtin_sources' array in 'meson.build'.
*
* Additionally, if `foo` is a new command, there are 4 more things to do:
*
* . Add tests to `t/` directory.
*
* . Add the test script to 'integration_tests' in 't/meson.build'.
*
* . Write documentation in `Documentation/git-foo.adoc`.
*
* . Add 'git-foo.adoc' to the manpages list in 'Documentation/meson.build'.
*
* . Add an entry for `git-foo` to `command-list.txt`.
*
* . Add an entry for `/git-foo` to `.gitignore`.
Expand Down Expand Up @@ -167,6 +173,7 @@ int cmd_commit(int argc, const char **argv, const char *prefix, struct repositor
int cmd_commit_graph(int argc, const char **argv, const char *prefix, struct repository *repo);
int cmd_commit_tree(int argc, const char **argv, const char *prefix, struct repository *repo);
int cmd_config(int argc, const char **argv, const char *prefix, struct repository *repo);
int cmd_config_batch(int argc, const char **argv, const char *prefix, struct repository *repo);
int cmd_count_objects(int argc, const char **argv, const char *prefix, struct repository *repo);
int cmd_credential(int argc, const char **argv, const char *prefix, struct repository *repo);
int cmd_credential_cache(int argc, const char **argv, const char *prefix, struct repository *repo);
Expand Down
161 changes: 161 additions & 0 deletions builtin/config-batch.c
Original file line number Diff line number Diff line change
@@ -0,0 +1,161 @@
#define USE_THE_REPOSITORY_VARIABLE
#include "builtin.h"
#include "config.h"
#include "environment.h"
#include "parse-options.h"
#include "strbuf.h"
#include "string-list.h"

static const char *const builtin_config_batch_usage[] = {
N_("git config-batch <options>"),
NULL
};

#define UNKNOWN_COMMAND "unknown_command"

static int emit_response(const char *response, ...)
{
va_list params;
const char *token;

printf("%s", response);

va_start(params, response);
while ((token = va_arg(params, const char *)))
printf(" %s", token);
va_end(params);

printf("\n");
fflush(stdout);
return 0;
}

/**
* A function pointer type for defining a command. The function is
* responsible for handling different versions of the command name.
*
* Provides the remaining 'data' for the command, to be parsed by
* the function as needed according to its parsing rules.
*
* These functions should only return a negative value if they result
* in such a catastrophic failure that the process should end.
*
* Return 0 on success.
*/
typedef int (*command_fn)(struct repository *repo,
char *data, size_t data_len);

static int unknown_command(struct repository *repo UNUSED,
char *data UNUSED, size_t data_len UNUSED)
{
return emit_response(UNKNOWN_COMMAND, NULL);
}

struct command {
const char *name;
command_fn fn;
int version;
};

static struct command commands[] = {
/* unknown_command must be last. */
{
.name = "",
.fn = unknown_command,
},
};

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

/**
* Process a single line from stdin and process the command.
*
* Returns 0 on successful processing of command, including the
* unknown_command output.
*
* Returns 1 on natural exit due to exist signal of empty line.
*
* Returns negative value on other catastrophic error.
*/
static int process_command(struct repository *repo)
{
static struct strbuf line = STRBUF_INIT;
struct string_list tokens = STRING_LIST_INIT_NODUP;
const char *command;
int version;
char *data = NULL;
size_t data_len = 0;
int res = 0;

strbuf_getline(&line, stdin);

if (!line.len)
return 1;

/* Parse out the first two tokens, command and version. */
string_list_split_in_place(&tokens, line.buf, " ", 2);

if (tokens.nr < 2) {
res = error(_("expected at least 2 tokens, got %"PRIu32),
(uint32_t)tokens.nr);
goto cleanup;
}

command = tokens.items[0].string;

if (!git_parse_int(tokens.items[1].string, &version)) {
res = error(_("unable to parse '%s' to integer"),
tokens.items[1].string);
goto cleanup;
}

if (tokens.nr >= 3) {
data = tokens.items[2].string;
data_len = strlen(tokens.items[2].string);
}

for (size_t i = 0; i < COMMAND_COUNT; i++) {
/*
* Run the ith command if we have hit the unknown
* command or if the name and version match.
*/
if (!commands[i].name[0] ||
(!strcmp(command, commands[i].name) &&
commands[i].version == version)) {
res = commands[i].fn(repo, data, data_len);
goto cleanup;
}
}

BUG(_("scanned to end of command list, including 'unknown_command'"));

cleanup:
strbuf_reset(&line);
string_list_clear(&tokens, 0);
return res;
}

int cmd_config_batch(int argc,
const char **argv,
const char *prefix,
struct repository *repo)
{
int res = 0;
struct option options[] = {
OPT_END(),
};

show_usage_with_options_if_asked(argc, argv,
builtin_config_batch_usage, options);

argc = parse_options(argc, argv, prefix, options, builtin_config_batch_usage,
0);

repo_config(repo, git_default_config, NULL);

while (!(res = process_command(repo)));

if (res == 1)
return 0;
die(_("an unrecoverable error occurred during command execution"));
}
1 change: 1 addition & 0 deletions command-list.txt
Original file line number Diff line number Diff line change
Expand Up @@ -83,6 +83,7 @@ git-commit mainporcelain history
git-commit-graph plumbingmanipulators
git-commit-tree plumbingmanipulators
git-config ancillarymanipulators complete
git-config-batch plumbinginterrogators
git-count-objects ancillaryinterrogators
git-credential purehelpers
git-credential-cache purehelpers
Expand Down
1 change: 1 addition & 0 deletions git.c
Original file line number Diff line number Diff line change
Expand Up @@ -557,6 +557,7 @@ static struct cmd_struct commands[] = {
{ "commit-graph", cmd_commit_graph, RUN_SETUP },
{ "commit-tree", cmd_commit_tree, RUN_SETUP },
{ "config", cmd_config, RUN_SETUP_GENTLY | DELAY_PAGER_CONFIG },
{ "config-batch", cmd_config_batch, RUN_SETUP_GENTLY },
{ "count-objects", cmd_count_objects, RUN_SETUP },
{ "credential", cmd_credential, RUN_SETUP_GENTLY | NO_PARSEOPT },
{ "credential-cache", cmd_credential_cache },
Expand Down
1 change: 1 addition & 0 deletions meson.build
Original file line number Diff line number Diff line change
Expand Up @@ -582,6 +582,7 @@ builtin_sources = [
'builtin/commit-tree.c',
'builtin/commit.c',
'builtin/config.c',
'builtin/config-batch.c',
'builtin/count-objects.c',
'builtin/credential-cache--daemon.c',
'builtin/credential-cache.c',
Expand Down
1 change: 1 addition & 0 deletions t/meson.build
Original file line number Diff line number Diff line change
Expand Up @@ -186,6 +186,7 @@ integration_tests = [
't1309-early-config.sh',
't1310-config-default.sh',
't1311-config-optional.sh',
't1312-config-batch.sh',
't1350-config-hooks-path.sh',
't1400-update-ref.sh',
't1401-symbolic-ref.sh',
Expand Down
25 changes: 25 additions & 0 deletions t/t1312-config-batch.sh
Original file line number Diff line number Diff line change
@@ -0,0 +1,25 @@
#!/bin/sh

test_description='Test git config-batch'

. ./test-lib.sh

test_expect_success 'no commands' '
echo | git config-batch >out &&
test_must_be_empty out
'

test_expect_success 'unknown_command' '
echo unknown_command >expect &&
echo "bogus 1 line of tokens" >in &&
git config-batch >out <in &&
test_cmp expect out
'

test_expect_success 'failed to parse version' '
echo "bogus BAD_VERSION line of tokens" >in &&
test_must_fail git config-batch 2>err <in &&
test_grep BAD_VERSION err
'

test_done