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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 2021-02-01 04:53:03 -0800, Chris Torek wrote:
> On Mon, Feb 1, 2021 at 4:36 AM Vincent Lefevre <vincent@xxxxxxxxxx> 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).

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

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

> 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@xxxxxxxxxx> - 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)



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux