Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> writes: > -test_expect_success !MINGW 'a constipated git dies with SIGPIPE' ' > +test_expect_success !MINGW,!BASH_SET_O_PIPEFAIL 'a constipated git dies with SIGPIPE' ' > OUT=$( ((large_git; echo $? 1>&3) | :) 3>&1 ) && > test_match_signal 13 "$OUT" > ' > > -test_expect_success !MINGW 'a constipated git dies with SIGPIPE even if parent ignores it' ' > +test_expect_success !MINGW,!BASH_SET_O_PIPEFAIL 'a constipated git dies with SIGPIPE even if parent ignores it' ' > OUT=$( ((trap "" PIPE; large_git; echo $? 1>&3) | :) 3>&1 ) && > test_match_signal 13 "$OUT" > ' The above have already !MINGW > diff --git a/t/t3600-rm.sh b/t/t3600-rm.sh > index 4f7e62d05c..7b5d92add5 100755 > --- a/t/t3600-rm.sh > +++ b/t/t3600-rm.sh > @@ -251,7 +251,10 @@ test_expect_success 'choking "git rm" should not let it die with cruft' ' > i=$(( $i + 1 )) > done | git update-index --index-info && > OUT=$( ((trap "" PIPE; git rm -n "some-file-*"; echo $? 1>&3) | :) 3>&1 ) && > - test_match_signal 13 "$OUT" && > + if ! test_have_prereq BASH_SET_O_PIPEFAIL > + then > + test_match_signal 13 "$OUT" > + fi && > test_path_is_missing .git/index.lock > ' but this one does not. Yet, we've been using test_match_signal on 13 without issues, it appears. And somehow with the lazy prereq on SET_O_PIPEFAIL, this part starts to break, like so: https://github.com/git/git/runs/1752687552?check_suite_focus=true#step:7:37042 The output captured in OUT is 0 as we can see on #37032 in the test log. I am tempted to eject 11/11 and probably 10/11 out of the topic, as the earlier patches before them look more or less uncontroversial cleanups, and 11/11 seems to be more trouble than it is worth at this moment. It's not like this would allow us to loosen the rule that we shouldn't put a "git" invocation of the git subcommand being tested on the upstream side of a pipe---not everybody is running bash, and it is unrealistic to tell our developers "if you want to make sure your tests are good, you must install and use this patched bash". Thanks.
