From: Patrick Steinhardt <ps@pks.im>
To: Lucas Seiki Oshiro <lucasseikioshiro@gmail.com>
Cc: git@vger.kernel.org, gitster@pobox.com, jltobler@gmail.com,
avila.jn@gmail.com
Subject: Re: [PATCH v5 1/2] repo: rename "keyvalue" to "lines"
Date: Tue, 27 Jan 2026 07:58:36 +0100 [thread overview]
Message-ID: <aXhiHAFNFxgsXa0S@pks.im> (raw)
In-Reply-To: <20260123164900.35092-2-lucasseikioshiro@gmail.com>
On Fri, Jan 23, 2026 at 01:34:53PM -0300, Lucas Seiki Oshiro wrote:
> The output format name "keyvalue" isn't so descriptive. Rename it to
> "lines", since it describes better the syntax of the output format and
> it isn't tied to key-value pairs.
I think this commit message is a bit hand-wavy. Most importantly, the
reader might wonder _why_ it isn't so descriptive, and why these
concerns are strong enough to change the accepted value now.
I would've written something like the following:
Both subcommands in git-repo(1) accept the "keyvalue" format. This
format is newline-delimited, where the key is separated from the
value with an equals sign.
The name of this option is suboptimal though, as it is both too
limiting while at the same time not really indicating what it
actually does:
- There is no mention of the format being newline-delimited, which
is the key differentiator to the "nul" format.
- Both "nul" and "keyvalue" have a key and a value, so the latter
is not exactly giving any hint what makes it so special.
- "keyvalue" requires there to be, well, a key and a value, but we
want to add additional output that is only going to be newline
delimited.
Taken together, "keyvalue" is kind of a bad name for this output
format.
Luckily, the git-repo(1) command is still rather new and marked as
experimental, so things aren't cast into stone yet. Rename the
format to "lines" instead to better indicate that the major
difference is that we'll get newline-delimited output. This new name
will also be a better fit for a subsequent extension in git-repo(1).
Please feel free to use this message or parts of it if you plan to
reroll.
I was also briefly wondering whether it would make sense to call the new
format "newlines" instead of "lines", but I'm not feeling strongly about
this in any way.
> diff --git a/builtin/repo.c b/builtin/repo.c
> index 0ea045abc1..4031612bc8 100644
> --- a/builtin/repo.c
> +++ b/builtin/repo.c
> @@ -26,7 +26,7 @@ typedef int get_value_fn(struct repository *repo, struct strbuf *buf);
>
> enum output_format {
> FORMAT_TABLE,
> - FORMAT_KEYVALUE,
> + FORMAT_LINES,
> FORMAT_NUL_TERMINATED,
> };
This feels a bit unbalanced to me, as `FORMAT_LINES` and
`FORMAT_NUL_TERMINATED` look so different from one another. Maybe it
would be better to call it `FORMAT_NEWLINE_TERMINATED`?
Patrick
next prev parent reply other threads:[~2026-01-27 6:58 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
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 [this message]
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=aXhiHAFNFxgsXa0S@pks.im \
--to=ps@pks.im \
--cc=avila.jn@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=jltobler@gmail.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox