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

From: Chris Torek <chris.torek@gmail.com>
Date: Feb 1, 2021, 11:33 UTC
Message-ID: <CAPx1Gvf92eCnSCZJLeqwyL-SprCxmnfi4w=d0-MHddY38DzADg@mail.gmail.com>
In-Reply-To: <20210201103429.GT623063@zira.vinc17.org>

Show 5 quoted lines

> 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