On Sun, Jul 27, 2025 at 2:02 PM Lucas Seiki Oshiro
<lucasseikioshiro@xxxxxxxxx> wrote:
> Add the --format flag to git-repo-info. By using this flag, the users
> can choose the format for obtaining the data they requested.
> [...]
> - keyvalue, where the retrieved data is printed one per line, using =
> for delimiting the key and the value. This is the default format,
> targeted for end users.
> - nul, where the retrieved data is separated by null characters, using
> the newline character for delimiting the key and the value. This
> format is targeted for being read by machines.
>
> Signed-off-by: Lucas Seiki Oshiro <lucasseikioshiro@xxxxxxxxx>
> ---
> diff --git a/Documentation/git-repo.adoc b/Documentation/git-repo.adoc
> @@ -18,10 +18,21 @@ THIS COMMAND IS EXPERIMENTAL. THE BEHAVIOR MAY CHANGE.
> +`info [--format=<format>] [<key>...]`::
> ++
> +The output format can be chosen through the flag `--format`. Two formats are
> +supported:
> ++
> +* `keyvalue`: output key-value pairs one per line using the `=` character as
> +the delimiter between the key and the value. This is the default.
> +
> +* `nul`: similar to `keyvalue`, but using a newline character as the delimiter
> +between the key and the value and using a null character after each value.
> +This format is better suited for being parsed by another applications than
> +`keyvalue`.
s/another/other/
I haven't been following the discussion around this series, but don't
we also usually provide a `-z` short option? Should that be added for
consistency with other commands and to avoid surprising users, or is
it too early to commit to that?
> diff --git a/t/t1900-repo.sh b/t/t1900-repo.sh
> @@ -20,11 +20,20 @@ test_repo_info () {
> + test_expect_success "null-terminated: $label" '
> + test_when_finished "rm -rf repo" &&
> + eval "$init_command" &&
> + echo "$expected_value" | lf_to_nul >expected &&
Simpler:
printf "$expected_value\0" >expected &&
> + git -C repo repo info --format=nul "$key" >output &&
> + tail -n 1 output >actual &&
> + test_cmp expected actual
> + '
How confident are we that `tail -n 1 output >actual` is going to
perform as expected across platforms and versions of those platforms?
It feels awfully fragile to me. Why slice and dice the output anyhow
rather than merely crafting the correct expected output in the first
place and comparing that directly against the actual output? In other
words, something like this:
printf "$key\n$expected_value\0" >expect &&
git -C repo repo info --format=nul "$key" >actual &&
test_cmp_bin expect actual
