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

From: Vincent Lefevre <vincent@vinc17.net>
Date: Feb 1, 2021, 15:17 UTC
Message-ID: <20210201151703.GC24560@zira.vinc17.org>
In-Reply-To: <CAPx1Gverh2E2h5JOSOfJ7JYvbhjv8hJNLE8y4VA2fNv0La8Rtw@mail.gmail.com>

On 2021-02-01 04:53:03 -0800, Chris Torek wrote:

Show 8 quoted lines

> On Mon, Feb 1, 2021 at 4:36 AM Vincent Lefevre <vincent@vinc17.net> 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.

The consistent behavior can be obtained by ignoring the broken pipe (in the case where git starts the pager).

Show 9 quoted lines

> [me]
> > > 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.

Show 11 quoted lines

> [on various exit cases]
> > > 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.

Show 8 quoted lines

> 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 <vincent@vinc17.net> - 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)