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.com \
--cc=git@vger.kernel.org \
--cc=lucasseikioshiro@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.