RE: [BUG] Test Failure 2.52.0, t8020.16,19

From: rsbecker@nexbridge.com <rsbecker@nexbridge.com>
Date: Nov 26, 2025, 16:15 UTC
Message-ID: <037001dc5eef$eac29e50$c047daf0$@nexbridge.com>
In-Reply-To: <328687ed-7fe6-47a2-a76e-7c38932d3914@app.fastmail.com>

On November 21, 2025 8:36 AM, Kristoffer Haugsbakk wrote:

Show 45 quoted lines

>On Fri, Nov 21, 2025, at 14:18, rsbecker@nexbridge.com wrote:
>> On November 19, 2025 11:25 AM, Kristoffer Haugsbakk wrote:
>>>On Wed, Nov 19, 2025, at 16:50, rsbecker@nexbridge.com wrote:
>>>> The following two failures appeared on NonStop for the actual
>>>> release. I
>> did
>>>> not see them in -rc0 or after (doesn't mean they didn't happen after
>> rc0).
>>>> To my eyes, this looks like a real issue not just on NonStop. It is
>>>> 100% reproducible and is not transient. The build is with OpenSSL
>>>> 3.4, but
>> that
>>>> should not matter.
>>>>
>>>> expecting success of 8020.16 'cross merge boundaries in blaming':
>>>>         git checkout HEAD^0 &&
>>>>         git rm -rf . &&
>>>>         test_commit m1 &&
>>>>         git checkout HEAD^ &&
>>>>         git rm -rf . &&
>>>>         test_commit m2 &&
>>>>         git merge m1 &&
>>>>         check_last_modified <<-\EOF
>>>>         m2 m2.t
>>>>         m1 m1.t
>>>>         EOF
>>>>[snip]
>>>
>>>Also reported here
>>>https://lore.kernel.org/git/4dc4c8cd-c0cc-4784-8fcf-
>>>defa3a051087@mit.edu/
>>
>> As a packager for NonStop, my team and I are trying to determine
>> whether
>> 2.52.0
>> can actually be shipped. The concern is, is this a defect in the test
>> code or underlying git merge code, and if the latter, how big an
>> impact. If we hold off, how long will it take for a fix
>> (approximately). I do not know the merge code, so...
>
>See the email from Jeff King on that thread
>https://lore.kernel.org/git/20251120081611.GC1283645@coredump.intra.peff.n
>et/
>
>By the way your email client reflows lines so aggressively that it breaks

lines in the

>middle of URLs.

I tried the suggestion from Jeff King, but there are no problematic casts that I can see. One possible issue here is the use of & with enums vs. ints, like

if (data.commit->object.flags & BOUNDARY) {

If flags is an in and BOUNDARY causes a sign extension, this might be an issue on a big-endian platform, particularly if 0x8000000 is used as the value or if a sign extension is expected.

The SANITIZE option ends up causing -f to be supplied to c99, which is gcc specific.