git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
To: Eric Sunshine <sunshine@sunshineco.com>
Cc: Jeff King <peff@peff.net>, Git List <git@vger.kernel.org>,
	Baruch Burstein <bmburstein@gmail.com>,
	Randall Becker <rsbecker@nexbridge.com>
Subject: "breaking" command output message parsing (was: [RFC PATCH] vreportf: ensure sensible ordering of normal and error output)
Date: Wed, 01 Dec 2021 14:51:11 +0100	[thread overview]
Message-ID: <211201.86h7bsbf4l.gmgdl@evledraar.gmail.com> (raw)
In-Reply-To: <CAPig+cS1ozLSJQgEJemDb+==NdB0ru5p4xknN11dkp6GJJM9iA@mail.gmail.com>


On Tue, Nov 30 2021, Eric Sunshine wrote:

> On Tue, Nov 30, 2021 at 9:05 AM Eric Sunshine <sunshine@sunshineco.com> wrote:
>> (2) With git-worktree being four or five years old, for
>> backward-compatibility concerns, I worry that "that ship has sailed",
>> where 'that' is the freedom to relocate those status-like messages
>> from stdout to stderr. I don't want to break tooling which exists
>> around git-worktree.
>>
>> I'd be happy to be wrong on the second point -- indeed, git-worktree
>> is still marked "experimental" in the man-page, but that may not mean
>> anything this late in the game -- and submit a patch which places
>> git-worktree's status-like messages on stderr instead of stdout.
>> Thoughts?
>
> If that ship has indeed sailed, then perhaps the best and safest thing
> to do is admit that git-worktree is an outlier in terms of sending
> status-like messages to stdout, and just sprinkle the necessary
> fflush(stdout) around in builtin/worktree.c and live with that
> localized ugliness. Thoughts?

I really don't think that ship has sailed at all. We're at full liberty
to change these error messages, and have even done so for some plumbing
in the past (being sensitive to what sort of messages, sometimes they
are important).

See e.g. my 9144ba4cf52 (remote: add meaningful exit code on
missing/existing, 2020-10-27), that was a case where we knew about a
in-the-wild parser of the output, and git-remote is in the (I suppose
"pseudo-plumbing?") "Ancillary Commands" category.

I think the one grey area here is as in 9144ba4cf52 where we'd expect
people to reasonably script around these commands, and parsing the
output was the only way to accomplish something reasonable. E.g. in that
case automation around adding remotes & the handling of failure
scenarios. The case of [1] for "git pull" is another potential recent
one. I.e. someone grepping "Everything up-to-date".

From some brief skimming of the worktree.c code that doesn't seem to
apply, i.e. it's just chattyness.

I doubt anyone cares if it's blathering about "preparing a worktree" or
whatever, it just matters if "git worktree add" and the like fail with
non-zero, but perhaps there's cases of conflated states, as in that case
of "git remote" and "git pull".

1. https://lore.kernel.org/git/211130.86a6hleo84.gmgdl@evledraar.gmail.com/

  reply	other threads:[~2021-12-01 13:59 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-30  4:39 [RFC PATCH] vreportf: ensure sensible ordering of normal and error output Eric Sunshine
2021-11-30  5:13 ` Junio C Hamano
2021-11-30  7:14   ` Jeff King
2021-11-30  7:23     ` Jeff King
2021-11-30 15:10       ` Ævar Arnfjörð Bjarmason
2021-11-30 20:52         ` Jeff King
2021-11-30 14:15     ` Eric Sunshine
2021-11-30  7:21 ` Jeff King
2021-11-30 14:05   ` Eric Sunshine
2021-11-30 14:57     ` Eric Sunshine
2021-12-01 13:51       ` Ævar Arnfjörð Bjarmason [this message]
2021-12-01 14:34         ` "breaking" command output message parsing (was: [RFC PATCH] vreportf: ensure sensible ordering of normal and error output) Eric Sunshine
2021-11-30 20:47     ` [RFC PATCH] vreportf: ensure sensible ordering of normal and error output Jeff King
2021-12-01  2:36       ` Eric Sunshine
2021-12-01  5:38         ` Eric Sunshine
2021-12-01 21:20       ` Ævar Arnfjörð Bjarmason
2021-12-02  0:43         ` 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

  List information: http://vger.kernel.org/majordomo-info.html

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

  git send-email \
    --in-reply-to=211201.86h7bsbf4l.gmgdl@evledraar.gmail.com \
    --to=avarab@gmail.com \
    --cc=bmburstein@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=peff@peff.net \
    --cc=rsbecker@nexbridge.com \
    --cc=sunshine@sunshineco.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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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).