Re: Bug in merge-ort (rename detection can have collisions?)

[Elijah Newren <newren@gmail.com>]

On Fri, Jun 10, 2022 at 9:53 AM Junio C Hamano <gitster@pobox.com> wrote:
>
> Elijah Newren <newren@gmail.com> writes:
>
> > On Tue, Jun 7, 2022 at 5:11 PM Glen Choo <chooglen@google.com> wrote:
> >>
> >> (I'm not 100% what the bug _is_, only that there is one.)
> >>
> >> = Report
> >>
> >> At $DAYJOB, there was a report that "git merge" was failing on certain
> >> branches. Fortunately, the repo is publicly accessible, so I can share
> >> the full reproduction recipe:
> >> ...
> > Thanks for the detailed report; very cool.  Interestingly, if you
> > reverse the direction of the merge (checkout origin/upstream-master
> > and merge origin/master) then you get a different error:
> > ...
> > Anyway, long story short...I don't have a fix yet, but just thought
> > I'd mention I saw the email and spent some hours digging in.
>
> Thanks for continued support for the ort strategy.  From the very
> beginning, I was hesitant to make our tools try to be too clever
> with excessive heuristics, but at least we are not making a silent
> mismerge in this case, so it is probably OK, especially with "-s
> recursive" still left as an escape hatch.

I'm pretty sure the bug would still trigger even if we removed all the
heuristic differences that the ort strategy has relative to the
recursive one; I don't think those are related to this problem at all.

In fact, the more general problem area here appears to affect the
recursive strategy as well.  I'm glad the specific testcase reported
works under recursive and gave Glen (or his user) a workaround, but
that feels like luck rather than design because my minimal
reproduction testcase not only triggers the same issue he saw with the
ort strategy, but also triggers a previously unknown fatal bug in the
recursive strategy too.