From: Junio C Hamano <gitster@pobox•com>
To: Lucas Seiki Oshiro <lucasseikioshiro@gmail•com>
Cc: git@vger•kernel.org
Subject: Re: [PATCH] repo: add new flag --keys to git-repo-info
Date: Mon, 08 Dec 2025 07:14:00 +0900 [thread overview]
Message-ID: <xmqqqzt6kkif.fsf@gitster.g> (raw)
In-Reply-To: <20251207190532.67107-1-lucasseikioshiro@gmail.com> (Lucas Seiki Oshiro's message of "Sun, 7 Dec 2025 16:02:10 -0300")
Lucas Seiki Oshiro <lucasseikioshiro@gmail•com> writes:
> Currently, if the user wants to find what are the available keys,
> they need to either check the documentation or to ask to all the
> key-value pairs by using --all.
>
> Add a new flag --keys for listing only the available keys without
> listing the values.
We do not need to say "Currently," but other than that the above is
very well written. Easy to grok and to the point.
> [synopsis]
> git repo info [--format=(keyvalue|nul) | -z] [--all | <key>...]
> +git repo info --keys
> git repo structure [--format=(table|keyvalue|nul) | -z]
So "git repo info --keys --all" or "git repo info --keys --format=..."
is not supported. Does the implementation behave sensibly when given
such nonsense commands? Let's see.
> @@ -170,6 +181,7 @@ static int cmd_repo_info(int argc, const char **argv, const char *prefix,
> {
> enum output_format format = FORMAT_KEYVALUE;
> int all_keys = 0;
> + int show_keys = 0;
> struct option options[] = {
> OPT_CALLBACK_F(0, "format", &format, N_("format"),
> N_("output format"),
> @@ -179,10 +191,15 @@ static int cmd_repo_info(int argc, const char **argv, const char *prefix,
> PARSE_OPT_NONEG | PARSE_OPT_NOARG,
> parse_format_cb),
> OPT_BOOL(0, "all", &all_keys, N_("print all keys/values")),
> + OPT_BOOL(0, "keys", &show_keys, N_("show keys")),
> OPT_END()
> };
>
> argc = parse_options(argc, argv, prefix, options, repo_usage, 0);
> +
> + if (show_keys)
> + return print_keys();
> +
> if (format != FORMAT_KEYVALUE && format != FORMAT_NUL_TERMINATED)
> die(_("unsupported output format"));
OK, so it is:
"git repo info --all --keys" and "git repo info --keys layout.bare"
both behave as if "git repo --keys" was given, ignoring
everything else.
Shouldn't "--keys" be explicitly marked incompatible with "--all"
and remaining keys in argc/argv[]?
While there is no strong reason why anybody must use NUL-terminated
output format, simply because repo_info_fields[] contains no tokens
with strange byte values, but just as principle, shouldn't
"git repo info --keys -z"
do what is naturally expected?
Perhaps
if (format != ...)
die(_("unsupported output format"));
if (show_keys && (all_keys || argc))
die(_("--keys cannot be used with a <key> or --all"));
if (show_keys)
return print_keys(output_format);
with a trivial update to print_keys() to support NUL-terminated
records, instead of puts()?
next prev parent reply other threads:[~2025-12-07 22:14 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-07 19:02 [PATCH] repo: add new flag --keys to git-repo-info Lucas Seiki Oshiro
2025-12-07 22:14 ` Junio C Hamano [this message]
2025-12-08 16:33 ` Lucas Seiki Oshiro
2025-12-08 7:13 ` Patrick Steinhardt
2025-12-09 19:36 ` [PATCH v2 0/2] " Lucas Seiki Oshiro
2025-12-09 19:36 ` [PATCH v2 1/2] repo: add a default output format to enum output_format Lucas Seiki Oshiro
2026-01-05 14:18 ` Patrick Steinhardt
2026-01-07 21:28 ` Lucas Seiki Oshiro
2026-01-08 6:13 ` Patrick Steinhardt
2025-12-09 19:36 ` [PATCH v2 2/2] repo: add new flag --keys to git-repo-info Lucas Seiki Oshiro
2026-01-05 14:18 ` Patrick Steinhardt
2026-01-05 13:57 ` [PATCH v2 0/2] " Lucas Seiki Oshiro
2026-01-05 14:19 ` Patrick Steinhardt
2026-01-09 20:31 ` [PATCH v3 0/2] repo: add --format=default and --keys Lucas Seiki Oshiro
2026-01-10 6:48 ` Junio C Hamano
2026-01-10 7:02 ` Junio C Hamano
2026-01-09 20:31 ` [PATCH v3 1/2] repo: add a default output format to enum output_format Lucas Seiki Oshiro
2026-01-09 20:31 ` [PATCH v3 2/2] repo: add new flag --keys to git-repo-info Lucas Seiki Oshiro
2026-01-10 12:04 ` Jean-Noël AVILA
2026-01-10 22:00 ` Lucas Seiki Oshiro
2026-01-12 8:40 ` Patrick Steinhardt
2026-01-19 20:20 ` [PATCH v4 0/2] repo: add --format=default and --keys Lucas Seiki Oshiro
2026-01-19 20:20 ` [PATCH v4 1/2] repo: add a default output format to enum output_format Lucas Seiki Oshiro
2026-01-19 20:20 ` [PATCH v4 2/2] repo: add new flag --keys to git-repo-info Lucas Seiki Oshiro
2026-01-20 6:05 ` Patrick Steinhardt
2026-01-20 23:11 ` Lucas Seiki Oshiro
2026-01-21 7:19 ` Patrick Steinhardt
2026-01-21 14:38 ` Lucas Seiki Oshiro
2026-01-20 0:52 ` [PATCH v4 0/2] repo: add --format=default and --keys Junio C Hamano
2026-01-23 16:34 ` [PATCH v5 0/2] repo: add --keys and rename "keyvalue" to "lines" Lucas Seiki Oshiro
2026-01-23 16:34 ` [PATCH v5 1/2] repo: " Lucas Seiki Oshiro
2026-01-27 6:58 ` Patrick Steinhardt
2026-01-23 16:34 ` [PATCH v5 2/2] repo: add new flag --keys to git-repo-info Lucas Seiki Oshiro
2026-01-27 6:58 ` Patrick Steinhardt
2026-01-27 22:27 ` Lucas Seiki Oshiro
2026-02-14 0:35 ` [PATCH v6 0/2] repo: add --keys and rename "keyvalue" to "lines" Lucas Seiki Oshiro
2026-02-14 0:35 ` [PATCH v6 1/2] repo: rename the output format " Lucas Seiki Oshiro
2026-02-14 0:35 ` [PATCH v6 2/2] repo: add new flag --keys to git-repo-info Lucas Seiki Oshiro
2026-02-14 18:14 ` [PATCH v6 0/2] repo: add --keys and rename "keyvalue" to "lines" Junio C Hamano
2026-02-16 6:59 ` Patrick Steinhardt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqqzt6kkif.fsf@gitster.g \
--to=gitster@pobox$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
--cc=lucasseikioshiro@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox