Thread (178 messages) 178 messages, 10 authors, 2025-08-16

Re: [GSoC RFC PATCH v4 2/4] repo: add the field references.format

From: Justin Tobler <hidden>
Date: 2025-07-17 16:11:59

On 25/07/17 03:03PM, Patrick Steinhardt wrote:
On Wed, Jul 16, 2025 at 09:04:40AM -0500, Justin Tobler wrote:
quoted
If we already plan to support additional output formats, they I agree we
should probably a `--format=<output-type>` flag from the start. I still
think it would be nice to have a `-z` flag that is shorthand for
`--format=nul` though as that is fairly common across other commands to
have such an option.

Out of curiousity, is there a reason we are interested in supporting a
JSON output format in addition to what is already proposed? From an
earlier conversation I had with Lucas, it didn't seem like there was any
particular reason for JSON.
I don't care much about the JSON output format. What I do care about is
to have a default format that we are free to iterate on, especially in
the context of `git repo size`. If we ever want to have output that is
as user friendly as git-sizer(1)'s we need to have that freedom.

From my perspective that necessitates two things:

  - That we are able to change formats with a proper `--format=` flag.
    `-z` alone doesn't fit that bill, as we are already talking about
    there formats: user friendly, key-value pairs, and key-value pairs
    with NUL termination.

    That being said I'm not opposed to also have `-z` as an alias as
    long as we also have `--format=`.

  - That the _default_ format is the user friendly format that we can
    iterate on, at least for `git repo size`. Otherwise we have already
    failed on our mission to supply a user-friendly alternative to
    git-sizer(1).
I was originally of the mindset that git-repo(1) would focus on being
more of a plumbing commmand and if we wanted to provide a more
user-friendly decorated format for something akin to git-sizer(1) info,
that would be better done through a separate command.

Thinking about this some more though, I agree with you that we should
probably just have git-repo(1) be the single stop and provide the
various output flavors for its subcommands. If this is the route we go
down, the default mode should be user-friendly.

I think a key attribute of this user-friendly mode is that it should be
free to change and be iterated on. If a user wants a stable output
format, they should request the key-value output form that is
line/nul-delimited.

So maybe we have three different output modes for `--format=<mode>`:
`user` (default), `keyvalue`, and `nul`? For `git repo info`, I'm not
entirely certain how the default user-friendly mode would/should differ
from the key-value one, but maybe that is not something we need to worry
about right now. For now, the two modes could match and over time update
the user mode as desired.

-Justin
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help