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

[Junio C Hamano <gitster@pobox.com>]

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