> Hi,
> 
> Building git-2.55.0-rc1 today, all non-x86 architectures
> failed with:
> 
>     Test Summary Report
>     -------------------
>     t4216-log-bloom.sh                               (Wstat: 0 Tests: 167 Failed: 0)
>       Parse errors: Unknown TAP token: "--- highbit1/expect 2026-06-17 19:44:07.555797743 +0000"
> 		    Unknown TAP token: "+++ highbit1/actual 2026-06-17 19:44:07.563651478 +0000"
> 		    Unknown TAP token: "@@ -1 +1 @@"
> 		    Unknown TAP token: "-52a9"
> 		    Unknown TAP token: "+c01f"
>     Files=1047, Tests=34680, 1072 wallclock secs ( 7.61 usr  1.61 sys + 395.73 cusr 586.23 csys = 991.18 CPU)
>     Result: FAIL
> 
> The test output is:
> 
>     ok 148 - setup check value of version 1 changed-path
>     --- highbit1/expect     2026-06-17 19:44:07.555797743 +0000
>     +++ highbit1/actual     2026-06-17 19:44:07.563651478 +0000
>     @@ -1 +1 @@
>     -52a9
>     +c01f
>     ok 149 # SKIP check value of version 1 changed-path (missing SIGNED_CHAR_BY_DEFAULT)
> 
> This looks like it comes from the following chunk of code in
> the test:
> 
>     # expect will not match actual if char is unsigned by default. Write the test
>     # in this way, so that a user running this test script can still see if the two
>     # files match. (It will appear as an ordinary success if they match, and a skip
>     # if not.)
>     if test_cmp highbit1/expect highbit1/actual
>     then
> 	    test_set_prereq SIGNED_CHAR_BY_DEFAULT
>     fi
>     test_expect_success SIGNED_CHAR_BY_DEFAULT 'check value of version 1 changed-path' '
> 	    # Only the prereq matters for this test.
> 	    true
>     '
> 
> It seems like we could (and perhaps should) redirect the
> output from test_cmp to a file (or /dev/null).
> 
> But... are we expecting these tests to not pass the test_cmp
> on any non-x86 arch in the first place?  Or is this exposing
> something broken in the test setup (test-tool read-graph
> bloom-filters) or elsewhere?

>> Building git-2.55.0-rc1 today, all non-x86 architectures
>> failed with:
>>  ...
>> This looks like it comes from the following chunk of code in
>> the test:
>> 
>>     # expect will not match actual if char is unsigned by default. Write the test
>>     # in this way, so that a user running this test script can still see if the two
>>     # files match. (It will appear as an ordinary success if they match, and a skip
>>     # if not.)
>>     if test_cmp highbit1/expect highbit1/actual
>>     then
>> 	    test_set_prereq SIGNED_CHAR_BY_DEFAULT
>>     fi
>>     test_expect_success SIGNED_CHAR_BY_DEFAULT 'check value of version 1 changed-path' '
>> 	    # Only the prereq matters for this test.
>> 	    true
>>     '

> Hm, this thing is indeed somewhat puzzling to me. I assume the intent is
> to give the developer some information that their platform is using
> signed characters by default? Other than that it's not really doing
> anything, as the prereq is only used by the one test shown above. I hope
> that Taylor has some more insight here.
>
> There's two potential fixes:
>
>   - We can just drop this completely, as it ultimately doesn't even end
>     up doing anything.
>
>   - We can convert the call to `test_cmp` into a `test_lazy_prereq`,
>     like done in the below patch, which retains the current behaviour.

> Patrick Steinhardt <ps@pks.im> writes:
> 
> >> Building git-2.55.0-rc1 today, all non-x86 architectures
> >> failed with:
> >>  ...
> >> This looks like it comes from the following chunk of code in
> >> the test:
> >> 
> >>     # expect will not match actual if char is unsigned by default. Write the test
> >>     # in this way, so that a user running this test script can still see if the two
> >>     # files match. (It will appear as an ordinary success if they match, and a skip
> >>     # if not.)
> >>     if test_cmp highbit1/expect highbit1/actual
> >>     then
> >> 	    test_set_prereq SIGNED_CHAR_BY_DEFAULT
> >>     fi
> >>     test_expect_success SIGNED_CHAR_BY_DEFAULT 'check value of version 1 changed-path' '
> >> 	    # Only the prereq matters for this test.
> >> 	    true
> >>     '
> 
> The "problematic" part is from mid 2024, so it is not anything new
> in 2.55-rc1, is it?  Nobody built and ran tests for the past two
> years on non-x86 boxes?

> Jeff King <peff@peff.net> writes:
> 
> > ... But since 389c83025d (t:
> > let prove fail when parsing invalid TAP output, 2026-06-04) it will
> > cause a test failure.
> 
> Thanks.  That was the piece I was missing.