{"thread":{"id":"64511","subject":"[BUG] Test Failure 2.52.0, t8020.16,19","startedAt":"2025-11-19T15:58:50Z","lastAt":"2025-11-26T19:18:14Z","messageCount":9,"participants":["rsbecker@nexbridge.com","Kristoffer Haugsbakk","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"530993","messageId":"003901dc596c$40bfbd80$c23f3880$@nexbridge.com","threadId":"64511","inReplyTo":null,"subject":"[BUG] Test Failure 2.52.0, t8020.16,19","fromName":"","fromEmail":"rsbecker@nexbridge.com","sentAt":"2025-11-19T15:50:33Z","receivedAt":"2025-11-19T15:58:50Z","isPatch":false,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"The following two failures appeared on NonStop for the actual release. I did\nnot see them in -rc0 or after (doesn't mean they didn't happen after rc0).\nTo my eyes, this looks like a real issue not just on NonStop. It is 100%\nreproducible and is not transient. The build is with OpenSSL 3.4, but that\nshould not matter.\n\nexpecting success of 8020.16 'cross merge boundaries in blaming':\n git checkout HEAD^0 &&\n git rm -rf . &&\n test_commit m1 &&\n git checkout HEAD^ &&\n git rm -rf . &&\n test_commit m2 &&\n git merge m1 &&\n check_last_modified <<-\\EOF\n m2 m2.t\n m1 m1.t\n EOF\n\n++ git checkout 'HEAD^0'\nNote: switching to 'HEAD^0'.\n\nYou are in 'detached HEAD' state. You can look around, make experimental\nchanges and commit them, and you can discard any commits you make in this\nstate without impacting any branches by switching back to a branch.\n\nIf you want to create a new branch to retain commits you create, you may\ndo so (now or later) by using -c with the switch command. Example:\n\n git switch -c \n\nOr undo this operation with:\n\n git switch -\n\nTurn off this advice by setting config variable advice.detachedHead to false\n\nHEAD is now at 08525b6 remove a\n++ git rm -rf .\nrm 'file'\n++ test_commit m1\n++ local notick=\n++ local echo=echo\n++ local append=\n++ local author=\n++ local signoff=\n++ local indir=\n++ local tag=light\n++ test 1 '!=' 0\n++ case \"$1\" in\n++ break\n++ indir=\n++ local file=m1.t\n++ test -n ''\n++ echo m1\n++ git add -- m1.t\n++ test -z ''\n++ test_tick\n++ test -z set\n++ test_tick=1112912173\n++ GIT_COMMITTER_DATE='1112912173 -0700'\n++ GIT_AUTHOR_DATE='1112912173 -0700'\n++ export GIT_COMMITTER_DATE GIT_AUTHOR_DATE\n++ git commit -m m1\n[detached HEAD 53e7187] m1\n Author: A U Thor \n 2 files changed, 1 insertion(+), 1 deletion(-)\n delete mode 100644 file\n create mode 100644 m1.t\n++ case \"$tag\" in\n++ git tag m1\n++ git checkout 'HEAD^'\nPrevious HEAD position was 53e7187 m1\nHEAD is now at 08525b6 remove a\n++ git rm -rf .\nrm 'file'\n++ test_commit m2\n++ local notick=\n++ local echo=echo\n++ local append=\n++ local author=\n++ local signoff=\n++ local indir=\n++ local tag=light\n++ test 1 '!=' 0\n++ case \"$1\" in\n++ break\n++ indir=\n++ local file=m2.t\n++ test -n ''\n++ echo m2\n++ git add -- m2.t\n++ test -z ''\n++ test_tick\n++ test -z set\n++ test_tick=1112912233\n++ GIT_COMMITTER_DATE='1112912233 -0700'\n++ GIT_AUTHOR_DATE='1112912233 -0700'\n++ export GIT_COMMITTER_DATE GIT_AUTHOR_DATE\n++ git commit -m m2\n[detached HEAD 9b81a41] m2\n Author: A U Thor \n 2 files changed, 1 insertion(+), 1 deletion(-)\n delete mode 100644 file\n create mode 100644 m2.t\n++ case \"$tag\" in\n++ git tag m2\n++ git merge m1\nMerge made by the 'ort' strategy.\n m1.t | 1 +\n 1 file changed, 1 insertion(+)\n create mode 100644 m1.t\n++ check_last_modified\n++ local indir=\n++ test 0 '!=' 0\n++ cat\n++ git last-modified\n++ git name-rev --annotate-stdin --name-only --tags\n++ tr '\\t' ' '\n++ test_cmp expect actual\n++ test 2 -ne 2\n++ eval 'diff -u' '\"$@\"'\n+++ diff -u expect actual\n--- expect 2025-11-19 15:43:34 +0000\n+++ actual 2025-11-19 15:43:34 +0000\n@@ -1,2 +1,2 @@\n+ac29b6e974b49803f1c6ec5a705d1bf7dbfa7d2f m1.t\n m2 m2.t\n-m1 m1.t\nerror: last command exited with $?=1\nnot ok 16 - cross merge boundaries in blaming\n\n\n\nexpecting success of 8020.19 'last-modified merge undoes changes':\n git checkout HEAD^0 &&\n git rm -rf . &&\n test_commit b1 file A &&\n test_commit b2 file B &&\n test_commit b3 file C &&\n test_commit b4 file D &&\n git checkout b2 &&\n test_commit b5 file2 2 &&\n git checkout b4 &&\n git merge --no-commit --no-ff b5 &&\n git checkout b2 -- file &&\n git merge --continue &&\n check_last_modified <<-\\EOF\n b5 file2\n b2 file\n EOF\n\n++ git checkout 'HEAD^0'\nHEAD is now at 7b0602a Merge tag 'a4' into HEAD\n++ git rm -rf .\nrm 'file'\n++ test_commit b1 file A\n++ local notick=\n++ local echo=echo\n++ local append=\n++ local author=\n++ local signoff=\n++ local indir=\n++ local tag=light\n++ test 3 '!=' 0\n++ case \"$1\" in\n++ break\n++ indir=\n++ local file=file\n++ test -n ''\n++ echo A\n++ git add -- file\n++ test -z ''\n++ test_tick\n++ test -z set\n++ test_tick=1112912713\n++ GIT_COMMITTER_DATE='1112912713 -0700'\n++ GIT_AUTHOR_DATE='1112912713 -0700'\n++ export GIT_COMMITTER_DATE GIT_AUTHOR_DATE\n++ git commit -m b1\n[detached HEAD c48d0f6] b1\n Author: A U Thor \n 1 file changed, 1 insertion(+), 1 deletion(-)\n++ case \"$tag\" in\n++ git tag b1\n++ test_commit b2 file B\n++ local notick=\n++ local echo=echo\n++ local append=\n++ local author=\n++ local signoff=\n++ local indir=\n++ local tag=light\n++ test 3 '!=' 0\n++ case \"$1\" in\n++ break\n++ indir=\n++ local file=file\n++ test -n ''\n++ echo B\n++ git add -- file\n++ test -z ''\n++ test_tick\n++ test -z set\n++ test_tick=1112912773\n++ GIT_COMMITTER_DATE='1112912773 -0700'\n++ GIT_AUTHOR_DATE='1112912773 -0700'\n++ export GIT_COMMITTER_DATE GIT_AUTHOR_DATE\n++ git commit -m b2\n[detached HEAD ee27b37] b2\n Author: A U Thor \n 1 file changed, 1 insertion(+), 1 deletion(-)\n++ case \"$tag\" in\n++ git tag b2\n++ test_commit b3 file C\n++ local notick=\n++ local echo=echo\n++ local append=\n++ local author=\n++ local signoff=\n++ local indir=\n++ local tag=light\n++ test 3 '!=' 0\n++ case \"$1\" in\n++ break\n++ indir=\n++ local file=file\n++ test -n ''\n++ echo C\n++ git add -- file\n++ test -z ''\n++ test_tick\n++ test -z set\n++ test_tick=1112912833\n++ GIT_COMMITTER_DATE='1112912833 -0700'\n++ GIT_AUTHOR_DATE='1112912833 -0700'\n++ export GIT_COMMITTER_DATE GIT_AUTHOR_DATE\n++ git commit -m b3\n[detached HEAD c90ce7d] b3\n Author: A U Thor \n 1 file changed, 1 insertion(+), 1 deletion(-)\n++ case \"$tag\" in\n++ git tag b3\n++ test_commit b4 file D\n++ local notick=\n++ local echo=echo\n++ local append=\n++ local author=\n++ local signoff=\n++ local indir=\n++ local tag=light\n++ test 3 '!=' 0\n++ case \"$1\" in\n++ break\n++ indir=\n++ local file=file\n++ test -n ''\n++ echo D\n++ git add -- file\n++ test -z ''\n++ test_tick\n++ test -z set\n++ test_tick=1112912893\n++ GIT_COMMITTER_DATE='1112912893 -0700'\n++ GIT_AUTHOR_DATE='1112912893 -0700'\n++ export GIT_COMMITTER_DATE GIT_AUTHOR_DATE\n++ git commit -m b4\n[detached HEAD 317a439] b4\n Author: A U Thor \n 1 file changed, 1 insertion(+), 1 deletion(-)\n++ case \"$tag\" in\n++ git tag b4\n++ git checkout b2\nPrevious HEAD position was 317a439 b4\nHEAD is now at ee27b37 b2\n++ test_commit b5 file2 2\n++ local notick=\n++ local echo=echo\n++ local append=\n++ local author=\n++ local signoff=\n++ local indir=\n++ local tag=light\n++ test 3 '!=' 0\n++ case \"$1\" in\n++ break\n++ indir=\n++ local file=file2\n++ test -n ''\n++ echo 2\n++ git add -- file2\n++ test -z ''\n++ test_tick\n++ test -z set\n++ test_tick=1112912953\n++ GIT_COMMITTER_DATE='1112912953 -0700'\n++ GIT_AUTHOR_DATE='1112912953 -0700'\n++ export GIT_COMMITTER_DATE GIT_AUTHOR_DATE\n++ git commit -m b5\n[detached HEAD 5526d49] b5\n Author: A U Thor \n 1 file changed, 1 insertion(+)\n create mode 100644 file2\n++ case \"$tag\" in\n++ git tag b5\n++ git checkout b4\nPrevious HEAD position was 5526d49 b5\nHEAD is now at 317a439 b4\n++ git merge --no-commit --no-ff b5\nAutomatic merge went well; stopped before committing as requested\n++ git checkout b2 -- file\n++ git merge --continue\n[detached HEAD da1857e] Merge tag 'b5' into HEAD\n Author: A U Thor \n++ check_last_modified\n++ local indir=\n++ test 0 '!=' 0\n++ cat\n++ git last-modified\n++ git name-rev --annotate-stdin --name-only --tags\n++ tr '\\t' ' '\n++ test_cmp expect actual\n++ test 2 -ne 2\n++ eval 'diff -u' '\"$@\"'\n+++ diff -u expect actual\n--- expect 2025-11-19 15:43:57 +0000\n+++ actual 2025-11-19 15:43:57 +0000\n@@ -1,2 +1,2 @@\n-b5 file2\n-b2 file\n+da1857e0652b6f264c0038d684ddecddc273e506 file2\n+da1857e0652b6f264c0038d684ddecddc273e506 file\nerror: last command exited with $?=1\nnot ok 19 - last-modified merge undoes changes\n\n\n--\nBrief whoami: NonStop&UNIX developer since approximately\nUNIX(421664400)\nNonStop(211288444200000000)\n-- In real life, I talk too much.\n\n\n\n"},{"id":"530995","messageId":"94d81164-5af5-471e-a403-f2d544796d18@app.fastmail.com","threadId":"64511","inReplyTo":"003901dc596c$40bfbd80$c23f3880$@nexbridge.com","subject":"Re: [BUG] Test Failure 2.52.0, t8020.16,19","fromName":"Kristoffer Haugsbakk","fromEmail":"kristofferhaugsbakk@fastmail.com","sentAt":"2025-11-19T16:25:10Z","receivedAt":"2025-11-19T16:25:41Z","isPatch":false,"sender":{"key":"kristofferhaugsbakk@fastmail.com","avatar":null},"body":"On Wed, Nov 19, 2025, at 16:50, rsbecker@nexbridge.com wrote:\n> The following two failures appeared on NonStop for the actual release. I did\n> not see them in -rc0 or after (doesn't mean they didn't happen after rc0).\n> To my eyes, this looks like a real issue not just on NonStop. It is 100%\n> reproducible and is not transient. The build is with OpenSSL 3.4, but that\n> should not matter.\n>\n> expecting success of 8020.16 'cross merge boundaries in blaming':\n> git checkout HEAD^0 &&\n> git rm -rf . &&\n> test_commit m1 &&\n> git checkout HEAD^ &&\n> git rm -rf . &&\n> test_commit m2 &&\n> git merge m1 &&\n> check_last_modified <<-\\EOF\n> m2 m2.t\n> m1 m1.t\n> EOF\n>[snip]\n\nAlso reported here https://lore.kernel.org/git/4dc4c8cd-c0cc-4784-8fcf-defa3a051087@mit.edu/\n"},{"id":"530998","messageId":"004c01dc5972$c145e780$43d1b680$@nexbridge.com","threadId":"64511","inReplyTo":"94d81164-5af5-471e-a403-f2d544796d18@app.fastmail.com","subject":"RE: [BUG] Test Failure 2.52.0, t8020.16,19","fromName":"","fromEmail":"rsbecker@nexbridge.com","sentAt":"2025-11-19T16:37:05Z","receivedAt":"2025-11-19T16:37:15Z","isPatch":false,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"On November 19, 2025 11:25 AM, Kristoffer Haugsbakk wrote\n>To: rsbecker ; git@vger.kernel.org\n>Subject: Re: [BUG] Test Failure 2.52.0, t8020.16,19\n>\n>On Wed, Nov 19, 2025, at 16:50, rsbecker@nexbridge.com wrote:\n>> The following two failures appeared on NonStop for the actual release.\n>> I did not see them in -rc0 or after (doesn't mean they didn't happen after rc0).\n>> To my eyes, this looks like a real issue not just on NonStop. It is\n>> 100% reproducible and is not transient. The build is with OpenSSL 3.4,\n>> but that should not matter.\n>>\n>> expecting success of 8020.16 'cross merge boundaries in blaming':\n>> git checkout HEAD^0 &&\n>> git rm -rf . &&\n>> test_commit m1 &&\n>> git checkout HEAD^ &&\n>> git rm -rf . &&\n>> test_commit m2 &&\n>> git merge m1 &&\n>> check_last_modified <<-\\EOF\n>> m2 m2.t\n>> m1 m1.t\n>> EOF\n>>[snip]\n>\n>Also reported here https://lore.kernel.org/git/4dc4c8cd-c0cc-4784-8fcf-\n>defa3a051087@mit.edu/\n\nThanks. Like ships passing in the wind 😉 \n\n"},{"id":"531139","messageId":"014801dc5ae9$543c73c0$fcb55b40$@nexbridge.com","threadId":"64511","inReplyTo":"94d81164-5af5-471e-a403-f2d544796d18@app.fastmail.com","subject":"RE: [BUG] Test Failure 2.52.0, t8020.16,19","fromName":"","fromEmail":"rsbecker@nexbridge.com","sentAt":"2025-11-21T13:18:24Z","receivedAt":"2025-11-21T13:18:34Z","isPatch":false,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"On November 19, 2025 11:25 AM, Kristoffer Haugsbakk wrote:\n>On Wed, Nov 19, 2025, at 16:50, rsbecker@nexbridge.com wrote:\n>> The following two failures appeared on NonStop for the actual release. I\ndid\n>> not see them in -rc0 or after (doesn't mean they didn't happen after\nrc0).\n>> To my eyes, this looks like a real issue not just on NonStop. It is 100%\n>> reproducible and is not transient. The build is with OpenSSL 3.4, but\nthat\n>> should not matter.\n>>\n>> expecting success of 8020.16 'cross merge boundaries in blaming':\n>> git checkout HEAD^0 &&\n>> git rm -rf . &&\n>> test_commit m1 &&\n>> git checkout HEAD^ &&\n>> git rm -rf . &&\n>> test_commit m2 &&\n>> git merge m1 &&\n>> check_last_modified <<-\\EOF\n>> m2 m2.t\n>> m1 m1.t\n>> EOF\n>>[snip]\n>\n>Also reported here https://lore.kernel.org/git/4dc4c8cd-c0cc-4784-8fcf-\n>defa3a051087@mit.edu/\n\nAs a packager for NonStop, my team and I are trying to determine whether\n2.52.0\ncan actually be shipped. The concern is, is this a defect in the test code\nor underlying\ngit merge code, and if the latter, how big an impact. If we hold off, how\nlong will it\ntake for a fix (approximately). I do not know the merge code, so... \n\n"},{"id":"531140","messageId":"328687ed-7fe6-47a2-a76e-7c38932d3914@app.fastmail.com","threadId":"64511","inReplyTo":"014801dc5ae9$543c73c0$fcb55b40$@nexbridge.com","subject":"Re: [BUG] Test Failure 2.52.0, t8020.16,19","fromName":"Kristoffer Haugsbakk","fromEmail":"kristofferhaugsbakk@fastmail.com","sentAt":"2025-11-21T13:36:25Z","receivedAt":"2025-11-21T13:36:47Z","isPatch":false,"sender":{"key":"kristofferhaugsbakk@fastmail.com","avatar":null},"body":"On Fri, Nov 21, 2025, at 14:18, rsbecker@nexbridge.com wrote:\n> On November 19, 2025 11:25 AM, Kristoffer Haugsbakk wrote:\n>>On Wed, Nov 19, 2025, at 16:50, rsbecker@nexbridge.com wrote:\n>>> The following two failures appeared on NonStop for the actual release. I\n> did\n>>> not see them in -rc0 or after (doesn't mean they didn't happen after\n> rc0).\n>>> To my eyes, this looks like a real issue not just on NonStop. It is 100%\n>>> reproducible and is not transient. The build is with OpenSSL 3.4, but\n> that\n>>> should not matter.\n>>>\n>>> expecting success of 8020.16 'cross merge boundaries in blaming':\n>>> git checkout HEAD^0 &&\n>>> git rm -rf . &&\n>>> test_commit m1 &&\n>>> git checkout HEAD^ &&\n>>> git rm -rf . &&\n>>> test_commit m2 &&\n>>> git merge m1 &&\n>>> check_last_modified <<-\\EOF\n>>> m2 m2.t\n>>> m1 m1.t\n>>> EOF\n>>>[snip]\n>>\n>>Also reported here https://lore.kernel.org/git/4dc4c8cd-c0cc-4784-8fcf-\n>>defa3a051087@mit.edu/\n>\n> As a packager for NonStop, my team and I are trying to determine whether\n> 2.52.0\n> can actually be shipped. The concern is, is this a defect in the test code\n> or underlying\n> git merge code, and if the latter, how big an impact. If we hold off, how\n> long will it\n> take for a fix (approximately). I do not know the merge code, so...\n\nSee the email from Jeff King on that thread https://lore.kernel.org/git/20251120081611.GC1283645@coredump.intra.peff.net/\n\nBy the way your email client reflows lines so aggressively that it\nbreaks lines in the middle of URLs.\n"},{"id":"531142","messageId":"014901dc5aee$ee435a60$caca0f20$@nexbridge.com","threadId":"64511","inReplyTo":"328687ed-7fe6-47a2-a76e-7c38932d3914@app.fastmail.com","subject":"RE: [BUG] Test Failure 2.52.0, t8020.16,19","fromName":"","fromEmail":"rsbecker@nexbridge.com","sentAt":"2025-11-21T13:58:30Z","receivedAt":"2025-11-21T13:58:38Z","isPatch":false,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"On November 21, 2025 8:36 AM, Kristoffer Haugsbakk wrote:\n>On Fri, Nov 21, 2025, at 14:18, rsbecker@nexbridge.com wrote:\n>> On November 19, 2025 11:25 AM, Kristoffer Haugsbakk wrote:\n>>>On Wed, Nov 19, 2025, at 16:50, rsbecker@nexbridge.com wrote:\n>>>> The following two failures appeared on NonStop for the actual\n>>>> release. I\n>> did\n>>>> not see them in -rc0 or after (doesn't mean they didn't happen after\n>> rc0).\n>>>> To my eyes, this looks like a real issue not just on NonStop. It is\n>>>> 100% reproducible and is not transient. The build is with OpenSSL\n>>>> 3.4, but\n>> that\n>>>> should not matter.\n>>>>\n>>>> expecting success of 8020.16 'cross merge boundaries in blaming':\n>>>> git checkout HEAD^0 &&\n>>>> git rm -rf . &&\n>>>> test_commit m1 &&\n>>>> git checkout HEAD^ &&\n>>>> git rm -rf . &&\n>>>> test_commit m2 &&\n>>>> git merge m1 &&\n>>>> check_last_modified <<-\\EOF\n>>>> m2 m2.t\n>>>> m1 m1.t\n>>>> EOF\n>>>>[snip]\n>>>\n>>>Also reported here\n>>>https://lore.kernel.org/git/4dc4c8cd-c0cc-4784-8fcf-\n>>>defa3a051087@mit.edu/\n>>\n>> As a packager for NonStop, my team and I are trying to determine\n>> whether\n>> 2.52.0\n>> can actually be shipped. The concern is, is this a defect in the test\n>> code or underlying git merge code, and if the latter, how big an\n>> impact. If we hold off, how long will it take for a fix\n>> (approximately). I do not know the merge code, so...\n>\n>See the email from Jeff King on that thread\n>https://lore.kernel.org/git/20251120081611.GC1283645@coredump.intra.peff.n\n>et/\n>\n>By the way your email client reflows lines so aggressively that it breaks\nlines in the\n>middle of URLs.\n\nYes, I'm using Outlook, which does not like bottom-tracked replies at all. I\nhave to manually do everything and it breaks rational likes. Blame you know\nwhom.\n\nIn any event, \"make SANITIZE=address,undefined\" generates bad CFLAGS, so I\ncannot compile that way.\n\n"},{"id":"531149","messageId":"xmqqy0nz4afw.fsf@gitster.g","threadId":"64511","inReplyTo":"014801dc5ae9$543c73c0$fcb55b40$@nexbridge.com","subject":"Re: [BUG] Test Failure 2.52.0, t8020.16,19","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-11-21T16:28:19Z","receivedAt":"2025-11-21T16:28:21Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":" writes:\n\n>>> expecting success of 8020.16 'cross merge boundaries in blaming':\n>>> git checkout HEAD^0 &&\n>>> git rm -rf . &&\n>>> test_commit m1 &&\n>>> git checkout HEAD^ &&\n>>> git rm -rf . &&\n>>> test_commit m2 &&\n>>> git merge m1 &&\n>>> check_last_modified <<-\\EOF\n>>> m2 m2.t\n>>> m1 m1.t\n>>> EOF\n>>>[snip]\n>>\n>>Also reported here https://lore.kernel.org/git/4dc4c8cd-c0cc-4784-8fcf-\n>>defa3a051087@mit.edu/\n>\n> .... The concern is, is this a defect in the test code\n> or underlying\n> git merge code, and if the latter, how big an impact. If we hold off, how\n> long will it\n> take for a fix (approximately). I do not know the merge code, so... \n\nBut is this really about \"merge\"?\n\nThe test is about how the \"last-modified\" command behaves given\nhistories of various shapes prepared with the sequence of commands\nthat comes before the \"check_last_modified\" line.\n\nYou can probably take a snapshot of the resulting repository\nimmediately after \"git merge m1\" from a test with both problematic\nversion and older version and compare the two repositories, and I an\nreasonably certain that you wouldn't see any differences (no, I am\nnot saying they should be bit-for-bit identical, but the set of\nobjects and topology should be the same). Bisection by others\npointing at a commit that changed how \"last-modified\" computes its\nresult should be a strong enough hint as well that the problem is\nunlikely with \"merge\".\n"},{"id":"531308","messageId":"037001dc5eef$eac29e50$c047daf0$@nexbridge.com","threadId":"64511","inReplyTo":"328687ed-7fe6-47a2-a76e-7c38932d3914@app.fastmail.com","subject":"RE: [BUG] Test Failure 2.52.0, t8020.16,19","fromName":"","fromEmail":"rsbecker@nexbridge.com","sentAt":"2025-11-26T16:15:38Z","receivedAt":"2025-11-26T16:15:53Z","isPatch":false,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"On November 21, 2025 8:36 AM, Kristoffer Haugsbakk wrote:\n>On Fri, Nov 21, 2025, at 14:18, rsbecker@nexbridge.com wrote:\n>> On November 19, 2025 11:25 AM, Kristoffer Haugsbakk wrote:\n>>>On Wed, Nov 19, 2025, at 16:50, rsbecker@nexbridge.com wrote:\n>>>> The following two failures appeared on NonStop for the actual\n>>>> release. I\n>> did\n>>>> not see them in -rc0 or after (doesn't mean they didn't happen after\n>> rc0).\n>>>> To my eyes, this looks like a real issue not just on NonStop. It is\n>>>> 100% reproducible and is not transient. The build is with OpenSSL\n>>>> 3.4, but\n>> that\n>>>> should not matter.\n>>>>\n>>>> expecting success of 8020.16 'cross merge boundaries in blaming':\n>>>> git checkout HEAD^0 &&\n>>>> git rm -rf . &&\n>>>> test_commit m1 &&\n>>>> git checkout HEAD^ &&\n>>>> git rm -rf . &&\n>>>> test_commit m2 &&\n>>>> git merge m1 &&\n>>>> check_last_modified <<-\\EOF\n>>>> m2 m2.t\n>>>> m1 m1.t\n>>>> EOF\n>>>>[snip]\n>>>\n>>>Also reported here\n>>>https://lore.kernel.org/git/4dc4c8cd-c0cc-4784-8fcf-\n>>>defa3a051087@mit.edu/\n>>\n>> As a packager for NonStop, my team and I are trying to determine\n>> whether\n>> 2.52.0\n>> can actually be shipped. The concern is, is this a defect in the test\n>> code or underlying git merge code, and if the latter, how big an\n>> impact. If we hold off, how long will it take for a fix\n>> (approximately). I do not know the merge code, so...\n>\n>See the email from Jeff King on that thread\n>https://lore.kernel.org/git/20251120081611.GC1283645@coredump.intra.peff.n\n>et/\n>\n>By the way your email client reflows lines so aggressively that it breaks\nlines in the\n>middle of URLs.\n\nI tried the suggestion from Jeff King, but there are no problematic casts\nthat I can see.\nOne possible issue here is the use of & with enums vs. ints, like\n\nif (data.commit->object.flags & BOUNDARY) {\n\nIf flags is an in and BOUNDARY causes a sign extension, this might be an\nissue on a\nbig-endian platform, particularly if 0x8000000 is used as the value or if a\nsign\nextension is expected.\n\nThe SANITIZE option ends up causing -f to be supplied to c99, which is gcc\nspecific.\n\n"},{"id":"531323","messageId":"038001dc5f09$674bfd90$35e3f8b0$@nexbridge.com","threadId":"64511","inReplyTo":"328687ed-7fe6-47a2-a76e-7c38932d3914@app.fastmail.com","subject":"RE: [BUG] Test Failure 2.52.0, t8020.16,19","fromName":"","fromEmail":"rsbecker@nexbridge.com","sentAt":"2025-11-26T19:18:04Z","receivedAt":"2025-11-26T19:18:14Z","isPatch":false,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"On November 26, 2025 11:16 AM, I wrote:\n>On November 21, 2025 8:36 AM, Kristoffer Haugsbakk wrote:\n>>On Fri, Nov 21, 2025, at 14:18, rsbecker@nexbridge.com wrote:\n>>> On November 19, 2025 11:25 AM, Kristoffer Haugsbakk wrote:\n>>>>On Wed, Nov 19, 2025, at 16:50, rsbecker@nexbridge.com wrote:\n>>>>> The following two failures appeared on NonStop for the actual\n>>>>> release. I\n>>> did\n>>>>> not see them in -rc0 or after (doesn't mean they didn't happen\n>>>>> after\n>>> rc0).\n>>>>> To my eyes, this looks like a real issue not just on NonStop. It is\n>>>>> 100% reproducible and is not transient. The build is with OpenSSL\n>>>>> 3.4, but\n>>> that\n>>>>> should not matter.\n>>>>>\n>>>>> expecting success of 8020.16 'cross merge boundaries in blaming':\n>>>>> git checkout HEAD^0 &&\n>>>>> git rm -rf . &&\n>>>>> test_commit m1 &&\n>>>>> git checkout HEAD^ &&\n>>>>> git rm -rf . &&\n>>>>> test_commit m2 &&\n>>>>> git merge m1 &&\n>>>>> check_last_modified <<-\\EOF\n>>>>> m2 m2.t\n>>>>> m1 m1.t\n>>>>> EOF\n>>>>>[snip]\n>>>>\n>>>>Also reported here\n>>>>https://lore.kernel.org/git/4dc4c8cd-c0cc-4784-8fcf-\n>>>>defa3a051087@mit.edu/\n>>>\n>>> As a packager for NonStop, my team and I are trying to determine\n>>> whether\n>>> 2.52.0\n>>> can actually be shipped. The concern is, is this a defect in the test\n>>> code or underlying git merge code, and if the latter, how big an\n>>> impact. If we hold off, how long will it take for a fix\n>>> (approximately). I do not know the merge code, so...\n>>\n>>See the email from Jeff King on that thread\n>>https://lore.kernel.org/git/20251120081611.GC1283645@coredump.intra.pef\n>>f.n\n>>et/\n>>\n>>By the way your email client reflows lines so aggressively that it\n>>breaks lines in the middle of URLs.\n>\n>I tried the suggestion from Jeff King, but there are no problematic casts\nthat I can\n>see.\n>One possible issue here is the use of & with enums vs. ints, like\n>\n>if (data.commit->object.flags & BOUNDARY) {\n>\n>If flags is an in and BOUNDARY causes a sign extension, this might be an\nissue on a\n>big-endian platform, particularly if 0x8000000 is used as the value or if a\nsign\n>extension is expected.\n>\n>The SANITIZE option ends up causing -f to be supplied to c99, which is gcc\nspecific.\n\nNot the issue with BOUNDARY. I am considering a potential compiler issue but\nneed to see whether this is try or not. There have been issues in the\ndistant past with unsigned flag:28 (bigger than 16 bits) on 32-bit builds,\nwhich mine must be for now. I doubt this is the issue, but I need to verify\none way or another based on what is expected for t8020.16 or 19. I can use\ngdb to verify one of the casts or calculations but I'm sorry but I cannot\nfollow what the code is doing well enough to know for certain. Is there a\nspecific line with results I can verify/dispute in builtin/last-modified.c\nthat will show an issue, please? A little help would be appreciated. My team\nhas decided that 2.52.0 is potentially problematic on NonStop ia64 and x86\nbecause of this problem.\n\n"}]}