"Randall S. Becker" <rsbecker@xxxxxxxxxxxxx> writes:
> On February 19, 2019 18:29, Junio C Hamano wrote:
>> A release candidate Git v2.21.0-rc2 is now available for testing at the usual
>> places. It is comprised of 474 non-merge commits since v2.20.0, contributed
>> by 61 people, 16 of which are new faces.
>
> Thanks. t5562 works properly on NonStop (3 tests under various
> loads). I am starting a full regression test now - see you in two
> days or so with a full report.
Thanks. In the end I ended up doing the following:
- kept most of your "feed NULs generated from a helper program via
pipe, instead of reading from /dev/zero" patch,
- replaced the helper program used in the above with the test-tool
one by Dscho,
- used Max's "do not reuse the output file---the background writer
about to die may still have it open when the next test starts",
- used Max's "when testing the program with overly large input
declared with content-length, do not have to feed from /dev/zero;
/dev/null suffices as a mistaken program attempting to read would
die when seeing EOF anyway" patch to reduce one mention of
/dev/zero (or one pipe from the helper output) further.
Hopefully Dscho's Azure thing would also be happy with one less use
of Perl script.
As I said earlier, a few places in t/ still mention /dev/zero and I
think it is a real bug on platforms without /dev/zero in t4153:
$ git grep -h dev/zero t/
test_must_fail test_terminal git am --3way </dev/zero &&
test_must_fail test_terminal git am --reject </dev/zero &&
Curiously, applying the attached patch and running the test on Linux
would notice that we do not have such a device file, and the use of
test_must_fail does *not* make it a-OK [*]. I am not sure why you
are not getting hit by the same issue.
Side note: test_must_fail is to ensure that the command
exits in a controlled way without segfault, so at the first
glance, replacing /dev/zero with something nonsensical and
nonexistent ought to make the command pass, but that is not
the case. The shell notices redirection failure and aborts
the &&-chain. This behaviour matches what we want, so I
won't complain ;-)
Another mention of /dev/zero appears in t/helper/test-sha1.sh (not
to be confused with t/helper/test-sha1.c). This seems to be run
only with an explicit "make -C t/helper check-sha1" request, so
perhaps nobody on your platform ran it to get hit by it. I wonder
if anybody runs this on any platform, to be honest, though. Duy
Cc'ed as the last person to touch that particular target---yes, I
know I was guilty of introducing it in b65bc21e ("Makefile: add
framework to verify and bench sha1 implementations.", 2006-06-24).
t/t4153-am-resume-override-opts.sh | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/t/t4153-am-resume-override-opts.sh b/t/t4153-am-resume-override-opts.sh
index 8ea22d1bcb..29ef22c94f 100755
--- a/t/t4153-am-resume-override-opts.sh
+++ b/t/t4153-am-resume-override-opts.sh
@@ -40,7 +40,7 @@ test_expect_success TTY '--3way overrides --no-3way' '
# Applying side1 with am --3way will succeed due to the threeway-merge.
# Applying side2 will fail as --3way does not apply to it.
- test_must_fail test_terminal git am --3way </dev/zero &&
+ test_must_fail test_terminal git am --3way </dev/zarro &&
test_path_is_dir .git/rebase-apply &&
test side1 = "$(cat file2)"
'
@@ -94,7 +94,7 @@ test_expect_success TTY '--reject overrides --no-reject' '
test_path_is_dir .git/rebase-apply &&
test_path_is_missing file.rej &&
- test_must_fail test_terminal git am --reject </dev/zero &&
+ test_must_fail test_terminal git am --reject </dev/zarro &&
test_path_is_dir .git/rebase-apply &&
test_path_is_file file.rej
'
