Re: git fails with a broken pipe when one quits the pager

[Chris Torek <chris.torek@gmail.com>]

> On 2021-01-31 21:49:49 +0100, Ævar Arnfjörð Bjarmason wrote:
> > ... That we're returning an exit code per getting a SIGHUP here
> > is a feature. Consider:
> >
> >     git -c core.pager=/bin/false log && echo showed you the output

This example has a minor flaw: it should use `git -c core.pager=/bin/true`,
probably.

On Mon, Feb 1, 2021 at 2:36 AM Vincent Lefevre <vincent@vinc17.net> wrote:
> If the pager exists with a non-zero exit status, it is normal to
> return a non-zero exit status. This was not the bug I reported.

That's the flaw in the example.  The key though is that the program
we ran as the pager—false, true, whatever—*did not read any of its input*.

> > Not being able to write "git log" output is a real SIGPIPE.

Worth noting: Linux has a pretty large pipe buffer.  POSIX requires
at least 4k here, as I recall, but Linux will buffer 64k or more, so that
if `git log` is able to write the entire log text (will be the case for small
repositories) *before* the program on the right side of the pager pipe
exits (this depends on many things), the pager's exit *won't* cause
a SIGPIPE.  You'll get the SIGPIPE if either the pager exits very
quickly, so that `git log` is unable to write much before the exit, or
if the repository is sufficiently large so that the pipe blocks first.

> Which is not the case here, because the full output has never been
> requested by the user.

The `git log` command *did* request the full output.

The problem that has come up is, if I understand correctly, that
some Linux distributions have come with misconfigured pagers
that don't bother reading their input, and silently exit zero.  This
causes all kinds of Git commands to *seem* to fail.  The Git commands
are just fine; the bug is that the pager doesn't read or write anything.

Unfortunately, the way that pipes work -- asynchronously -- means
that Git really *can't* catch all problems here.  But catching a SIGPIPE,
whether Git itself spawned the pager or not, does indicate that
something has gone wrong ... *unless* Git was piping to, e.g., less,
and the user read enough, and the user typed `q` at less, and less
exited without bothering to read the rest of the input.

There's no good way for Git to be able to tell which of these was
the case.

I'm not sure what this actually argues for. ;-)

Chris