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

["Ævar Arnfjörð Bjarmason" <avarab@gmail.com>]

On Fri, Jan 15 2021, Vincent Lefevre wrote:

> I had reported the following bug at
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=914896
>
> It still occurs with Git 2.30.0.
>
> Some git commands with a lot of output fail with a broken pipe when
> one quits the pager (without going to the end of the output).
>
> For instance, in zsh:
>
> cventin% setopt PRINT_EXIT_VALUE
> cventin% git log
> zsh: broken pipe  git log
> cventin% echo $?
> 141
> cventin% 
>
> This is annoying[...]

Yes it's annoying, but the annoying output is from zsh, not
git. Consider a smarter implementation like:

    case $__exit_status in
        0) __exit_emoji=😀;;
        1) __exit_emoji=☹️ ;;
        141) __exit_emoji=🤕 ;;
        [...]

Then put the $__exit_emoji in your $PS1 prompt, now when you 'q' in a
pager you know the difference between having quit at the full output
being emitted or not.

> And of course, I don't want to hide error messages by default, because
> this would hide *real* errors.

Isn't the solution to this that your shell stops reporting failures due
to SIGPIPE in such a prominent way then?

> The broken pipe is internally expected, thus should not be reported
> by git.
>
> Just to be clear: this broken pipe should be discarded only when git
> uses its builtin pager feature, not with a general pipe, where the
> error may be important.
>
> For instance,
>
> $ { git log ; echo "Exit status: $?" >&2 ; } | true
>
> should still output
>
> Exit status: 141

I don't get it, how is it less meaningful when git itself invokes the
pager?

In both cases the exit code means the same thing, that something in a
pipe wasn't fully consumed being signalled to calling processes is the
point of SIGPIPE.