From: Junio C Hamano <gitster@pobox.com>
To: Johannes Sixt <j6t@kdbg.org>
Cc: "Rubén Justo" <rjusto@gmail.com>,
"Git List" <git@vger.kernel.org>, "Jeff King" <peff@peff.net>
Subject: Re: [PATCH] pager: die when paging to non-existing command
Date: Thu, 20 Jun 2024 15:35:46 -0700 [thread overview]
Message-ID: <xmqqplsbqm2l.fsf@gitster.g> (raw)
In-Reply-To: <ba5965c2-9f1c-4dd2-a2c5-e1bde832766c@kdbg.org> (Johannes Sixt's message of "Fri, 21 Jun 2024 00:17:22 +0200")
Johannes Sixt <j6t@kdbg.org> writes:
> Am 20.06.24 um 21:04 schrieb Junio C Hamano:
>> Just in case there is a reason why we should instead silently return
>> on MinGW, I'll Cc the author of bfdd9ffd, though.
>
> I don't think there is a reason. IIRC, originally on Windows, failing to
> start a pager would still let Git operate normally, just without paged
> output. I might have regarded this as better than to fail the operation.
The "better keep going than to fail" is what Rubén finds worse, so
both sides are quite understandable.
It is unlikely that real-world users are taking advantage of the
fact. If they do not want their invocation of Git command paged,
"GIT_PAGER=cat git foo" is just as easy as "GIT_PAGER=no git foo",
and if it was done by mistake to configure a non-working pager
(e.g., configure core.pager to the program xyzzy and then
uninstalling xyzzy without realizing you still have users), fixing
it would be a one-time operation either way (you update core.pager
or you reinstall xyzzy), so I would say that it is better to make
the failure more stand out.
Thanks for a quick response.
next prev parent reply other threads:[~2024-06-20 22:35 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-20 17:25 [PATCH] pager: die when paging to non-existing command Rubén Justo
2024-06-20 19:04 ` Junio C Hamano
2024-06-20 20:22 ` Rubén Justo
2024-06-20 21:03 ` Junio C Hamano
2024-06-20 22:17 ` Johannes Sixt
2024-06-20 22:35 ` Junio C Hamano [this message]
2024-06-21 6:51 ` Jeff King
2024-06-21 17:11 ` Dragan Simic
2024-06-24 7:35 ` Johannes Schindelin
2024-06-21 11:28 ` Phillip Wood
2024-06-21 23:21 ` Junio C Hamano
2024-06-21 6:40 ` Jeff King
2024-06-21 21:11 ` Rubén Justo
2024-06-21 21:29 ` [PATCH v2] " Rubén Justo
2024-06-21 23:31 ` [PATCH v3] " Rubén Justo
2024-06-22 7:08 ` Johannes Sixt
2024-06-23 7:09 ` [PATCH v4] " Rubén Justo
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=xmqqplsbqm2l.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=j6t@kdbg.org \
--cc=peff@peff.net \
--cc=rjusto@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).