Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> writes: >>> But yeah, we could patch git to handle this in the general case.... >> >> Sorry, but now you lost me. >> >> I was merely wondering if Denton's patch can become a small update >> on top of these, if we just made sure that the exit code of the >> pager noticed by wait_or_whine() is reported to the code where >> Denton makes the decision to say "let's not re-raise but simply exit >> with 0 return as what we got is SIGPIPE". I guess we could even >> make git exit with the pager's return code in that case, as the >> end-user observable result would be similar to "git log | less" >> where 'less' may be segfaulting or exiting cleanly. >> >> IOW, something like this on top of your three-patch series? >> >> pager.c | 8 +++++++- >> 1 file changed, 7 insertions(+), 1 deletion(-) >> ... > I sent a WIP start at something like this at the end of my v2, please > discard it when picking up the rest: > https://lore.kernel.org/git/20210202020001.31601-6-avarab@xxxxxxxxx/ > > As noted there it's going to be a lot more complex than this. Sorry, but you still have lost me---I do not see if/why we even care about atexit codepath. As far as the end users are concered, they are running "git" and observing the exit code from "git". There, reporting that "git" was killed by SIGPIPE, instead of exiting normally, is not something they want to hear about after quitting their pager, and that is why the signal reception codepath matters. Yes, I can see you are making it "a lot more complex" in your patch, but what I do not see is why we even need to. Thanks.
