Re: Confusing (maybe wrong?) conflict output with ort

> Hi,
> 
> On Thu, Dec 2, 2021 at 11:08 AM Alex Xu (Hello71) <alex_y_xu@yahoo.ca> wrote:
>>
>> Hi all,
>>
>> After upgrading to git 2.34.1, I tried to rebase [0] onto [1], but
>> encountered "strange" conflict results.
>>
>> git rebase -s recursive main produces [[RECURSIVE]]. It is roughly what
>> I expected to be output. If I take all the changes from the upper
>> section of the conflict, my changes will be effectively undone. If I
>> take all the changes from the lower section, then the upstream changes
>> will be undone.
> 
> In general, this does not work.  The only time it can work is if every
> region of the code considered by the three-way content merge ended up
> with conflicts.  (If any of those regions had automatically resolvable
> changes, then after taking just the upper section(s) or just the lower
> section(s) of each conflict would still result in a file that is a
> mixture of changes from both sides due to the automatically resolvable
> chunks that the merge already handled.)
> 
>> On the other hand, running git rebase -s ort main produces [[ORT]]. I am
>> unsure if it is wrong, strictly speaking, but it is certainly unexpected
>> and difficult for me to resolve. Selecting the upper section of the
>> conflict does erase my changes, as before, but selecting the lower
>> section results in syntactically incorrect code (foreach is ended by
>> endif). The diff3 output makes even less sense to me.
> 
> The output from using ort is identical to that obtained by
> 
>    git rebase -s recursive -Xdiff-algorithm=histogram ...
> 
> on your testcase; i.e. this is due to a difference between the
> histogram and myers diff algorithms.
> (recursive defaults to using myers diff; ort uses histogram diff.)