From: Junio C Hamano Date: Fri, 21 Nov 2025 16:28:19 GMT Subject: Re: [BUG] Test Failure 2.52.0, t8020.16,19 Message-ID: In-Reply-To: <014801dc5ae9$543c73c0$fcb55b40$@nexbridge.com> writes: >>> 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/ > > .... 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... But is this really about "merge"? The test is about how the "last-modified" command behaves given histories of various shapes prepared with the sequence of commands that comes before the "check_last_modified" line. You can probably take a snapshot of the resulting repository immediately after "git merge m1" from a test with both problematic version and older version and compare the two repositories, and I an reasonably certain that you wouldn't see any differences (no, I am not saying they should be bit-for-bit identical, but the set of objects and topology should be the same). Bisection by others pointing at a commit that changed how "last-modified" computes its result should be a strong enough hint as well that the problem is unlikely with "merge".