From: rsbecker@nexbridge.com Date: Fri, 21 Nov 2025 13:58:30 GMT Subject: RE: [BUG] Test Failure 2.52.0, t8020.16,19 Message-ID: <014901dc5aee$ee435a60$caca0f20$@nexbridge.com> In-Reply-To: <328687ed-7fe6-47a2-a76e-7c38932d3914@app.fastmail.com> On November 21, 2025 8:36 AM, Kristoffer Haugsbakk wrote: >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. Yes, I'm using Outlook, which does not like bottom-tracked replies at all. I have to manually do everything and it breaks rational likes. Blame you know whom. In any event, "make SANITIZE=address,undefined" generates bad CFLAGS, so I cannot compile that way.