Thread (38 messages) 38 messages, 5 authors, 2021-02-05

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

From: Vincent Lefevre <hidden>
Date: 2021-02-01 15:18:32

On 2021-02-01 04:53:03 -0800, Chris Torek wrote:
On Mon, Feb 1, 2021 at 4:36 AM Vincent Lefevre [off-list ref] wrote:
quoted
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.
The consistent behavior can be obtained by ignoring the broken pipe
(in the case where git starts the pager).
[me]
quoted
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. [...]
I agree.
[on various exit cases]
quoted
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.
No, Git can tell when the pager exited abnormally: it suffices to
check its exit status. Git currently doesn't do that, and this is
bad, because it can miss real issues, which cannot always be detected
by the user.

If the pager exits with exit code 0, this means normal termination,
whether the user has read the full output or not.
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. :-)
Well, my objection is based on the fact that it is possible to get
the information from the exit status of the pager (I originally
thought that Git was taking it into account).

BTW, another related thing I dislike about Git, and I think that this
should also be regarded as a bug, is that when doing a commit, Git
doesn't check the exit status of the editor for the commit message.
Say, for instance, if something on the system kills the editor, Git
applies the commit with an incorrect or incomplete log message though
the commit wasn't validated yet by the user. Fortunately, the user
can amend the commit, but IMHO, that's an incorrect behavior.

-- 
Vincent Lefèvre [off-list ref] - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help