Git development
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Patrick Steinhardt <ps@pks.im>
Cc: Todd Zullinger <tmz@pobox.com>,
	 git@vger.kernel.org,  Taylor Blau <me@ttaylorr.com>
Subject: Re: git-2.55.0-rc1 t4216 broken TAP failures on non-x86 arch
Date: Thu, 18 Jun 2026 15:10:47 -0700	[thread overview]
Message-ID: <xmqq4iizpkig.fsf@gitster.g> (raw)
In-Reply-To: <ajOP1IOjA3EYvRfm@pks.im> (Patrick Steinhardt's message of "Thu, 18 Jun 2026 08:27:32 +0200")

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?

> 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".


  reply	other threads:[~2026-06-18 22:10 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-17 22:03 git-2.55.0-rc1 t4216 broken TAP failures on non-x86 arch Todd Zullinger
2026-06-18  6:27 ` Patrick Steinhardt
2026-06-18 22:10   ` Junio C Hamano [this message]
2026-06-18 23:35     ` Jeff King
2026-06-19  0:36       ` Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqq4iizpkig.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=me@ttaylorr.com \
    --cc=ps@pks.im \
    --cc=tmz@pobox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox