From: Joseph Jenne <hidden> Date: 2021-08-02 17:47:06
What did you do before the bug happened? (Steps to reproduce your issue)
used `git log`, exiting the viewer (`less`) before reading the entire
commit history of the project
What did you expect to happen? (Expected behavior)
normal exit with status code 0
What happened instead? (Actual behavior)
git log dies to SIGPIPE after `less` exits
What's different between what you expected and what actually happened?
git does not exit normally as would be expected
Anything else you want to add:
[System Info]
git version:
git version 2.30.2
cpu: x86_64
no commit associated with this build
sizeof-long: 8
sizeof-size_t: 8
shell-path: /bin/sh
uname: Linux 5.10.0-8-amd64 #1 SMP Debian 5.10.46-2 (2021-07-20) x86_64
compiler info: gnuc: 10.2
libc info: glibc: 2.31
$SHELL (typically, interactive shell): /bin/zsh
From: Jeff King <hidden> Date: 2021-08-02 18:08:58
On Mon, Aug 02, 2021 at 10:46:53AM -0700, Joseph Jenne wrote:
What did you do before the bug happened? (Steps to reproduce your issue)
used `git log`, exiting the viewer (`less`) before reading the entire
commit history of the project
What did you expect to happen? (Expected behavior)
normal exit with status code 0
What happened instead? (Actual behavior)
git log dies to SIGPIPE after `less` exits
What's different between what you expected and what actually happened?
git does not exit normally as would be expected
From: Joseph Jenne <hidden> Date: 2021-08-02 18:16:28
Thanks, I'll check it out.
On Mon, Aug 2, 2021 at 11:08 AM Jeff King [off-list ref] wrote:
On Mon, Aug 02, 2021 at 10:46:53AM -0700, Joseph Jenne wrote:
quoted
What did you do before the bug happened? (Steps to reproduce your issue)
used `git log`, exiting the viewer (`less`) before reading the entire
commit history of the project
What did you expect to happen? (Expected behavior)
normal exit with status code 0
What happened instead? (Actual behavior)
git log dies to SIGPIPE after `less` exits
What's different between what you expected and what actually happened?
git does not exit normally as would be expected
From: ZheNing Hu <hidden> Date: 2021-09-26 13:23:49
Joseph Jenne [off-list ref] 于2021年8月3日周二 上午1:47写道:
What did you do before the bug happened? (Steps to reproduce your issue)
used `git log`, exiting the viewer (`less`) before reading the entire
commit history of the project
What did you expect to happen? (Expected behavior)
normal exit with status code 0
What happened instead? (Actual behavior)
git log dies to SIGPIPE after `less` exits
What's different between what you expected and what actually happened?
git does not exit normally as would be expected
Anything else you want to add:
[System Info]
git version:
git version 2.30.2
cpu: x86_64
no commit associated with this build
sizeof-long: 8
sizeof-size_t: 8
shell-path: /bin/sh
uname: Linux 5.10.0-8-amd64 #1 SMP Debian 5.10.46-2 (2021-07-20) x86_64
compiler info: gnuc: 10.2
libc info: glibc: 2.31
$SHELL (typically, interactive shell): /bin/zsh
I may be a little unresponsive, I also saw this bug today, and there
is no such bug
in a small repository, it only appears in a large repository.
I now know that it comes from outside git, this is really bad.
--
ZheNing Hu
Joseph Jenne [off-list ref] 于2021年8月3日周二 上午1:47写道:
quoted
What did you do before the bug happened? (Steps to reproduce your issue)
used `git log`, exiting the viewer (`less`) before reading the entire
commit history of the project
What did you expect to happen? (Expected behavior)
normal exit with status code 0
What happened instead? (Actual behavior)
git log dies to SIGPIPE after `less` exits
What's different between what you expected and what actually happened?
git does not exit normally as would be expected
Anything else you want to add:
[System Info]
git version:
git version 2.30.2
cpu: x86_64
no commit associated with this build
sizeof-long: 8
sizeof-size_t: 8
shell-path: /bin/sh
uname: Linux 5.10.0-8-amd64 #1 SMP Debian 5.10.46-2 (2021-07-20) x86_64
compiler info: gnuc: 10.2
libc info: glibc: 2.31
$SHELL (typically, interactive shell): /bin/zsh
I may be a little unresponsive, I also saw this bug today, and there
is no such bug
in a small repository, it only appears in a large repository.
I now know that it comes from outside git, this is really bad.