Re: [GSoC PATCH v5 5/5] repo: add the --format flag
From: Eric Sunshine <hidden>
Date: 2025-07-27 22:02:21
On Sun, Jul 27, 2025 at 2:02 PM Lucas Seiki Oshiro [off-list ref] wrote:
quoted hunk ↗ jump to hunk
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 <redacted> ---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?
quoted hunk ↗ jump to hunk
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