From: Junio C Hamano <gitster@pobox.com>
To: Jeff King <peff@peff.net>
Cc: Derrick Stolee via GitGitGadget <gitgitgadget@gmail.com>,
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:39:20 -0700 [thread overview]
Message-ID: <xmqq7cc925l3.fsf@gitster.g> (raw)
In-Reply-To: <20240821154001.GA506216@coredump.intra.peff.net> (Jeff King's message of "Wed, 21 Aug 2024 11:40:01 -0400")
Jeff King <peff@peff.net> writes:
> Playing devil's advocate for a moment: what about programs that read
> stderr but intend to relay the output to the user?
>
> For example, programs running on the server side of a push are spawned
> by receive-pack with their stderr fed into a muxer that ships it to the
> client, who then dumps it to the user's terminal. Would we ever want to
> see their advice?
>
> My guess is "conceivably yes", though I don't know of a specific example
> (and in fact, I've seen the "your hook was ignored because it's not
> executable" advice coming from a server, which was actually more of an
> annoyance on the client side).
Ah, I should have waited to think about the topic before reading
what you wrote. Yes, this is a huge downside.
> Looking over patch 7, I think the escape hatch for all of these cases
> would be setting GIT_ADVICE=1. Which isn't too bad, but it does require
> some action. I'm not sure if it is worth it (but then, I am not all that
> sympathetic to the script you mentioned that was trying to be too clever
> about parsing stderr).
This too.
next prev parent reply other threads:[~2024-08-21 16:39 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 [this message]
2024-08-21 16:36 ` Junio C Hamano
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=xmqq7cc925l3.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=peff@peff.net \
--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 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.