Am 02.02.21 um 23:21 schrieb Junio C Hamano: > Johannes Sixt <j6t@xxxxxxxx> writes: > >>> Anyway, my opinion in the message you are responding to was that the >>> exit status of the pager subprocess wait_for_pager_atexit() finds >>> does not matter, and there is no reason to overly complicate the >>> implementation like the comments in Ævar's [v2 5/5] implies, and it >>> is sufficient to just hide the fact in wait_for_pager_signal() that >>> we got SIGPIPE. I am not sure if you are agreeing with me, or are >>> showing me where/why I was wrong. >> >> We are agreeing that the SIGPIPE should not be reported. >> >> We may be disagreeing whether it is good or bad that git's exit code is >> overridden by the pager's exit code, which Ævar wanted to implement, >> IIUC. I think that is reasonable and I base my opinion on the comparison >> with the pipeline `git log | less`, where git's exit code is ignored. > > I guess we are then in agreement---I do think it makes sense to send > the true exit code from the pager as the exit code from the pager to > the trace output, which is what the early part of Ævar's patch does, > but I do not think the exit code of the pager should affect the exit > code from "git log" as a whole. Then we do not agree. The exit code of `git log | less` is ignored, and I regard `git -p log` just as a short-hand for that. That said, I don't care a lot about the exit code. When a pager is in the game, we are talking about an interactive command invocation, and what the exit code of that is, is irrelevant in practice. The only thing I care is that git does not die due to a SIGPIPE when the pager is closed early. -- Hannes
