From: Junio C Hamano <gitster@pobox.com>
To: Phillip Wood <phillip.wood123@gmail.com>
Cc: Matheus Tavares Bernardino <matheus.tavb@gmail.com>,
git@vger.kernel.org, johannes.schindelin@gmx.de,
newren@gmail.com, ps@pks.im,
Lincoln Yuji <lincolnyuji@hotmail.com>,
Rodrigo Siqueira <siqueirajordao@riseup.net>
Subject: Re: [PATCH v2] rebase -x: don't print "Executing:" msgs with --quiet
Date: Mon, 19 Aug 2024 13:17:27 -0700 [thread overview]
Message-ID: <xmqqv7zwclns.fsf@gitster.g> (raw)
In-Reply-To: <08dc334a-e1d9-4aa1-945e-c543de549163@gmail.com> (Phillip Wood's message of "Mon, 19 Aug 2024 14:57:16 +0100")
Phillip Wood <phillip.wood123@gmail.com> writes:
> On 18/08/2024 14:03, Matheus Tavares Bernardino wrote:
>> ...
>> term_clean_line()", the correct approach would be to modify
>> "term_clean_line()" to return earlier "if (!isatty(1))". What do you
>> think?
>
> On the face of it that sounds like a good idea but I haven't thought
> too much about it. These messages are all going to stderr rather than
> stdout. If we do go that way we'll need to adjust
> launch_specified_editor() in editor.c to either suppress the hint or
> terminate it with '\n' if stderr is not a terminal.
Right.
The true reason why I brought it up was because (1) it looked really
funny to avoid doing that term_clean_line() under "--verbose" as
well as under "--quiet" and the code should explain what reasoning
backs such decision but it did not, and (2) that unexplained funny
pattern repeated, which probably was a sign that it needed to become
a small helper function with descriptive name to encapsulate the
logic to decide when to call and when not to call the clean-line,
which as a bonus would give a central place for us to explain the
reason behind not cleaning the line under "--verbose" and the same
for "--quiet" (as I suspect that these two want to omit the call for
different reasons).
Thanks.
next prev parent reply other threads:[~2024-08-19 20:17 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-16 3:26 [PATCH] rebase -x: don't print "Executing:" msgs with --quiet Matheus Tavares
2024-08-16 6:20 ` Elijah Newren
2024-08-16 8:26 ` Patrick Steinhardt
2024-08-16 17:34 ` Junio C Hamano
2024-08-16 22:48 ` [PATCH v2] " Matheus Tavares
2024-08-17 11:22 ` Junio C Hamano
2024-08-18 13:03 ` Matheus Tavares Bernardino
2024-08-19 13:57 ` Phillip Wood
2024-08-19 20:17 ` Junio C Hamano [this message]
2024-08-20 22:23 ` Matheus Tavares Bernardino
2024-08-19 15:41 ` Junio C Hamano
2024-08-21 1:31 ` [PATCH v3] rebase --exec: respect --quiet Matheus Tavares
2024-08-21 16:00 ` 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=xmqqv7zwclns.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=johannes.schindelin@gmx.de \
--cc=lincolnyuji@hotmail.com \
--cc=matheus.tavb@gmail.com \
--cc=newren@gmail.com \
--cc=phillip.wood123@gmail.com \
--cc=ps@pks.im \
--cc=siqueirajordao@riseup.net \
/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.