From: Junio C Hamano Date: Thu, 18 Jun 2026 22:10:47 GMT Subject: Re: git-2.55.0-rc1 t4216 broken TAP failures on non-x86 arch Message-ID: In-Reply-To: Patrick Steinhardt 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? > 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. Yeah, unless Taylor can tell us something we are not seeing, I am inclined to say that we can just get rid of the whole thing. SIGNED_CHAR_BY_DEFAULT is not used anywhere else, and the only place it is used isd to run "true".