All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Ron Ziroby Romero <ziroby@gmail.com>
Cc: demerphq <demerphq@gmail.com>,
	 "brian m. carlson" <sandals@crustytoothpaste.net>,
	 Sean Allred <allred.sean@gmail.com>,
	git@vger.kernel.org
Subject: Re: Pretty output in JSON format
Date: Mon, 04 Aug 2025 14:19:08 -0700	[thread overview]
Message-ID: <xmqqldny4wfn.fsf@gitster.g> (raw)
In-Reply-To: <CAGW8g7kMVqsi6+JkdjDS-czKJQ=01ULUz36sZrGom+QPVtRF3A@mail.gmail.com> (Ron Ziroby Romero's message of "Mon, 4 Aug 2025 21:39:02 +0100")

Ron Ziroby Romero <ziroby@gmail.com> writes:

> First, I'm questioning my approach of hacking pretty.c with a series
> of 'if json' blocks. Would it be better to make a new file,
> json-log.c, and divorce myself from the pretty flow entirely?

The same question to the other thread applies: why json?

If the objective is to give a parseable output for machines to
robustly read, then I do not think you want to use any of the
infrastructure laid by and for the pretty_print_commit() function,
whose purpose is quite the opposite, like squeezing inter paragraph
spaces, trimming trailing whitespaces, indenting even an empty line
by 4 spaces, etc., etc.

> Second, I see that someone is adding a --json flag to git status[1]. I
> figure that argues for git log to use the --json flag. I don't think
> that affects me other than making the case for this JSON output.

Please don't.

That other thread is getting discouraged from introducing a new
option just for a single new format.  Unfortunately "status" does
not have the --format={short,long,...} so we need to add one new
option to allow new formats to be added in a more generic way, but
once that is done, the next new format would not have to add a new
option.  Compared to it, "log" already has --pretty={...}, so we do
not have to add --json just for this single format, which makes us
luckier than the other thread.

      reply	other threads:[~2025-08-04 21:19 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
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 [this message]

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=xmqqldny4wfn.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=allred.sean@gmail.com \
    --cc=demerphq@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=sandals@crustytoothpaste.net \
    --cc=ziroby@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.