mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Jeff King <>
To: "brian m. carlson" <>
Cc: Martin Langhoff <>,
	Git Mailing List <>
Subject: Re: Structured (ie: json) output for query commands?
Date: Thu, 1 Jul 2021 17:48:36 -0400	[thread overview]
Message-ID: <YN44NB3I/> (raw)
In-Reply-To: <>

On Thu, Jul 01, 2021 at 09:18:01PM +0000, brian m. carlson wrote:

> > I don't love the invalid-utf8-in-json thing in general. But I think it
> > may be the least-bad solution. I seem to recall that YAML has its own
> > complexities, and losing human-readability (even to base64) is a pretty
> > big downside. And the tooling for working with json seems more common
> > and mature (certainly over something like CBOR, but I think even YAML
> > doesn't have anything nearly as nice as jq).
> I'm not opposed to JSON as long as we don't write landmines.  We could
> URI-encode anything that contains a bag-of-bytes, which lets people have
> the niceties of JSON without the breakage when people don't write valid
> UTF-8.  Most things will still be human-readable.
> We could even have --json be an alias for --json=encoded (URI-encoding)
> and also have --json=strict for the situation where you assert
> everything is valid UTF-8 and explicitly said you wanted us to die() if
> we saw non-UTF-8.  I don't want us to say that something is JSON and
> then emit junk, since that's a bad user experience.
> Ideally, we'd have some generic serializer support for this case, so if
> people _do_ want to add YAML or CBOR output, it can be stuffed in.

Yep, I'd agree with all of that. I think we're on more-or-less the same

One annoying thing about JSON is that (to my knowledge) it doesn't have
a binary data type. So you have to encode things and shove them into
"string". I guess that is not too bad if you are using backslash or
percent-encoding, as only a minority of characters get encoded. But it
sure would be nice for readers if the values, once extracted from the
json, could be used without further munging. That's most of the benefit
of using json in the first place. But it may be the best we can do.


  reply	other threads:[~2021-07-01 21:48 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <>
2021-06-30 17:00 ` Structured (ie: json) output for query commands? Martin Langhoff
2021-06-30 17:59   ` Jeff King
2021-06-30 18:20     ` Martin Langhoff
2021-07-01 15:47       ` Jeff King
2021-06-30 20:19     ` brian m. carlson
2021-06-30 23:27       ` Martin Langhoff
2021-07-01 16:00       ` Jeff King
2021-07-01 21:18         ` brian m. carlson
2021-07-01 21:48           ` Jeff King [this message]
2021-07-02 13:13           ` Ævar Arnfjörð Bjarmason
2021-07-01  8:18   ` Han-Wen Nienhuys

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:

  List information:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YN44NB3I/ \ \ \ \ \

* 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.
Code repositories for project(s) associated with this public inbox

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).