From: Dragan Simic Date: Fri, 21 Jun 2024 17:11:59 GMT Subject: Re: [PATCH] pager: die when paging to non-existing command Message-ID: In-Reply-To: On 2024-06-21 00:35, Junio C Hamano wrote: > Johannes Sixt 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. To me, failing when the configured pager cannot be executed is the way to go. Basically, if an invalid pager is configured, we're actually obliged to produce a failure, simply because we have to follow and apply the configuration strictly. This also applies to (partially) invalid configurations.