git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: "Derrick Stolee via GitGitGadget" <gitgitgadget@gmail.com>
Cc: git@vger.kernel.org,  Johannes.Schindelin@gmx.de,  ps@pks.im,
	james@jamesliu.io,  Derrick Stolee <stolee@gmail.com>
Subject: Re: [PATCH 0/7] [RFC] advice: refuse to output if stderr not TTY
Date: Wed, 21 Aug 2024 09:36:56 -0700	[thread overview]
Message-ID: <xmqqbk1l25p3.fsf@gitster.g> (raw)
In-Reply-To: <pull.1776.git.1724238152.gitgitgadget@gmail.com> (Derrick Stolee via GitGitGadget's message of "Wed, 21 Aug 2024 11:02:25 +0000")

"Derrick Stolee via GitGitGadget" <gitgitgadget@gmail.com> writes:

> Advice is supposed to be for humans, not machines. Why do we output it when
> stderr is not a terminal? Let's stop doing that.

Last night while skimming the series on my phone (read: not a real
review at all), I found it very annoying that GIT_ADVICE=1 had to be
sprinkled all over the place.  I wonder if we want to instead set
and export it in t/test-lib.sh and turn it off as needed?

The end-to-end tests we have are primarily to guarantee the
continuity of the end-user experience by humans, and ensuring that
an advice message is given when appropriate and it does not get
shown otherwise is very much inherent part of them.  An alternative
workaround to counteract the breakage this series causes of course
is to run everything under test_terminal and it probably is much
more kosher philosophically ;-), but compared to that, globally
disabling the "if (!isatty(2))" while running the tests, and
temporarily lifting that disabling during tests of the new feature
added by this series would be easier to reason about, I would
suspect.

> This series is motivated by an internal tool breaking due to the advice
> message added to Git 2.46.0 by 9479a31d603 (advice: warn when sparse index
> expands, 2024-07-08). This tool is assuming that any output to stderr is an
> error, and in this case is attempting to parse it to determine what kind of
> error (warning, error, or failure).

The "anything on stderr is an error" attitude needs to be fixed
regardless of where it comes from (tcl/tk scripts have, or at least
used to have, the tendency, which I found annoying), but regardless,
I thought we added a mechanism to squelch all advice messages for
this exact purpose at f0e21837 (Merge branch 'jl/git-no-advice',
2024-05-16).  Why isn't the tool using the mechanism that already
exists?

I would have supported the behaviour proposed by this series 100% if
it were on the table when we were introducing the advise mechanism,
but unfortunately nobody seemed have suggested it back then.  I am
willing to go with an "experiment" to change the behaviour,
deliberately breaking "backward compatibility", if we have a wide
support here during the review period.  FWIW, I think any scripts
that scrape the advice messages are already broken.



  parent reply	other threads:[~2024-08-21 16:37 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-08-21 11:02 [PATCH 0/7] [RFC] advice: refuse to output if stderr not TTY Derrick Stolee via GitGitGadget
2024-08-21 11:02 ` [PATCH 1/7] t1000-2000: add GIT_ADVICE=1 for advice tests Derrick Stolee via GitGitGadget
2024-08-21 11:02 ` [PATCH 2/7] t3000-4000: add GIT_ADVICE=1 to " Derrick Stolee via GitGitGadget
2024-08-21 11:02 ` [PATCH 3/7] t5000: " Derrick Stolee via GitGitGadget
2024-08-21 11:02 ` [PATCH 4/7] t6000: " Derrick Stolee via GitGitGadget
2024-08-21 11:02 ` [PATCH 5/7] t7000: " Derrick Stolee via GitGitGadget
2024-08-21 11:02 ` [PATCH 6/7] t7508/12: set GIT_ADVICE=1 across all tests Derrick Stolee via GitGitGadget
2024-08-21 11:02 ` [PATCH 7/7] advice: refuse to output if stderr not TTY Derrick Stolee via GitGitGadget
2024-08-21 15:40 ` [PATCH 0/7] [RFC] " Jeff King
2024-08-21 16:39   ` Junio C Hamano
2024-08-21 16:36 ` Junio C Hamano [this message]
2024-08-22  6:19   ` Patrick Steinhardt
2024-08-22  6:03 ` Gabor Gombas
2024-08-22 13:15 ` Derrick Stolee
2024-08-22 16:25   ` 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=xmqqbk1l25p3.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=james@jamesliu.io \
    --cc=ps@pks.im \
    --cc=stolee@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 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 NNTP newsgroup(s).