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

From: Junio C Hamano <gitster@pobox.com>
Date: Nov 21, 2025, 16:28 UTC
Message-ID: <xmqqy0nz4afw.fsf@gitster.g>
In-Reply-To: <014801dc5ae9$543c73c0$fcb55b40$@nexbridge.com>

<rsbecker@nexbridge.com> writes:

Show 22 quoted lines

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