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

On Mon, Feb 1, 2021 at 4:36 AM Vincent Lefevre [off-list ref] wrote:

In general, repositories have more than 64k log.

Please don't focus on the exact size.  Some system might
have a multi-gigabyte pipe buffer, and some other system
might have a tiny one; we'd like consistent behavior no matter
what size the system uses.  Can we *get* consistent behavior?
I don't know.

[me]

quoted

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.

They are not misconfigured. This is how they work.

A pager that reads nothing and writes nothing does not seem
very useful to me.  (Perhaps we can disregard these cases
entirely.  It's not like we should expect Git to handle things if
someone builds a version of `less` that doesn't work.  The
fact is that on these Linux systems, running `$pager foo` on a
file `foo` does nothing at all, for some values of `$pager`.  I
believe I ran into this on a Docker setup at least once.  It's
not Git's fault and hence not something for it to correct.)

[on various exit cases]

quoted

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

In the case git spawns a pager, it knows that this is a pager
(as per documentation).

Again, this seems irrelevant.  If the pager exited correctly
while reading everything, or it exited correctly without reading
everything, or if it exited incorrectly with or without reading
everything, is not something *Git* can tell.  I'm therefore not
sure that Git should *try* to tell -- which is the point I'm trying
to make here.  The question is this: if we can only do a poor
job, should we try at all?  What *should* we do, given what
we *can* do?  All we get is SIGPIPE and an exit status, and
the SIGPIPE may or may not be meaningful.

That seems to be what you're arguing as well.  So I'm not sure
why you're objecting to what I'm pointing out. :-)

Chris