Re: diff wish

2011/6/15 Branko Čibej <brane_at_e-reka.si>:
> On 15.06.2011 15:38, Johan Corveleyn wrote:
>> 2011/6/15 Branko Čibej <brane_at_e-reka.si>:
>>> On 15.06.2011 14:11, Johan Corveleyn wrote:
>>>>> If you have a different definition of "mis-synchronizes", please explain.
>>>> No, I don't mean a broken diff. The diff should at all times be
>>>> *correct*. That was indeed never questioned.
>>>>
>>>> I mean something like the example Neels gave with his initial approach
>>>> for avoid the mis-matching empty line problem. With the naive
>>>> solution, he gave an example of where it's not nice:
>>> [...]
>>>
>>> But when would the current "minimal" diff be preferable to the nicest,
>>> albeit not minimal, diff we can produce? After all, the fix and/or
>>> patience diff result is not only nicer to look at, it also gives better
>>> results for blame, which is the other big diff consumer.
>> Please define "nicest".
>
> The "nicest" is the one that looks most natural to a human. We will
> never achieve that, but can certainly try.

I think we need something more machine-understandable / programmable
than "most natural to a human" :-).

>> Note that I gave an example where f.i. "patience diff" produces worse
>> results IMHO than the "minimal diff" (right below Neels' example):
>>
>> [[[
>> file a
>>
>> aaaaaa
>> aaaaaa
>> bbbbbb
>> bbbbbb
>> cccccc
>> cccccc
>> abc
>>
>> file b
>>
>> abc
>> aaaaaa
>> aaaaaa
>> bbbbbb
>> bbbbbb
>> cccccc
>> cccccc
>>
>> Patience diff will give:
>>
>> -aaaaaa
>> -aaaaaa
>> -bbbbbb
>> -bbbbbb
>> -cccccc
>> -cccccc
>> abc
>> +aaaaaa
>> +aaaaaa
>> +bbbbbb
>> +bbbbbb
>> +cccccc
>> +cccccc
>>
>> Minimal diff will give:
>>
>> +abc
>> aaaaaa
>> aaaaaa
>> bbbbbb
>> bbbbbb
>> cccccc
>> cccccc
>> -abc
>> ]]]
>>
>> Which one is the nicest?
>
> Clearly, patience diff gets that heuristic wrong. :)

I guess it depends. Maybe some humans are really focused on the
'abc'-line staying the same, and everything else being moved around
it.

> My point is this: If you start having options for specific diff
> algorithm in "svn diff", are you going to extend them to "svn blame" and
> "svn merge", too? Will different people get different blame results,
> based on which algorithm is the default?

Yes of course. Just like you can have different blame/merge results
with --ignore-space-change and --ignore-eol-style. But gut feeling: if
there is any sanity to both diff algorithms, blame will attribute the
most significant lines to the same person/revision in both cases.
That's just a guess though.

> [...]
>
>> But I don't like the hand-waving discussion that it will always be
>> superior, period. That's just not true. And it would be a big mistake,
>> IMHO, to only support a heuristic diff.
>
> I'm not selling patience diff as generally superior. Clearly it has its
> drawbacks, and there's no reason to assume those can't be fixed, whether
> in the patience algorithm itself, or in an adaptation of that and other
> ideas to "svn diff". I don't think there's a requirement to get from
> "what we have now" to "best possible" in one iteration, or even in one
> dot seven.
>
> Also please explain how "it would be a big mistake IMHO" is anything but
> hand-waving. :)

Yes, you're right. Sorry for the additional hand-waving :).

-- 
Johan