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