From: Sean Allred <allred.sean@gmail•com>
To: "brian m. carlson" <sandals@crustytoothpaste•net>
Cc: Ron Ziroby Romero <ziroby@gmail•com>, git@vger•kernel.org
Subject: Re: Pretty output in JSON format
Date: Wed, 25 Sep 2024 13:45:54 -0500 [thread overview]
Message-ID: <m0r097mv19.fsf@epic96565.epic.com> (raw)
In-Reply-To: <ZvM39VNFptcfwMGk@tapette.crustytoothpaste.net> (brian m. carlson's message of "Tue, 24 Sep 2024 22:06:45 +0000")
"brian m. carlson" <sandals@crustytoothpaste•net> writes:
> On 2024-09-24 at 21:52:35, Ron Ziroby Romero wrote:
>> What do y'all think?
>
> I think this is ultimately a bad idea. JSON requires that the output be
> UTF-8, but Git processes a large amount of data, including file names,
> ref names, commit messages, author and committer identities, diff
> output, and other file contents, that are not restricted to UTF-8.
This strikes me with a little bit of 'perfect as the enemy of good'
here. I'm sure there are ways to signal an encoding failure. I would,
however, caution against trying to provide diff output in JSON. That
just seems... odd. Maybe base64 it first? (I don't know -- I just
struggle to see the use-case here.)
> However, if you were interested in CBOR output, which isn't
> human-readable but is capable of handling byte strings, then I don't
> see a problem. CBOR is used in FIDO2 and a variety of other protocols
> and is interoperable, so it should be a fine choice here.
CBOR would certainly solve the byte stream problem, but I think it would
primarily be only useful for 'serious' toolsmiths that need to handle
wildly unpredictable data. For most uses, JSON would get the job done.
>> What do y'all think?
As with all things, I'd suggest you draw up a more formal proposal of
exactly how this would work, and then that proposal can be discussed.
How would you use this option? What would its behavior be? What's in
scope? What's _not_ in scope? :-)
--
Sean Allred
next prev parent reply other threads:[~2024-09-25 18:45 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-24 21:52 Pretty output in JSON format Ron Ziroby Romero
2024-09-24 22:06 ` brian m. carlson
2024-09-25 18:45 ` Sean Allred [this message]
2024-09-26 21:04 ` brian m. carlson
2024-09-27 6:49 ` Ron Ziroby Romero
[not found] ` <CANgJU+Xs-sQgAOCPL-5skaZGq7eHmhg0MaFGDr8N57=CK67iog@mail.gmail.com>
[not found] ` <CAGW8g7=xK0S-i_Ekfwwo_NjMbngO_5m4LERtWRhSCgA0vf+ZAg@mail.gmail.com>
2025-07-31 20:19 ` Ron Ziroby Romero
2025-08-04 20:39 ` Ron Ziroby Romero
2025-08-04 21:19 ` Junio C Hamano
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=m0r097mv19.fsf@epic96565.epic.com \
--to=allred.sean@gmail$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
--cc=sandals@crustytoothpaste$(echo .)net \
--cc=ziroby@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