Searching explanation of different diff algorithms

Searching explanation of different diff algorithms

[Thomas Koch]

Is there any explanation available of the different merrits and drawbacks of 
the diff algorithms that Git supports?

I'm not satisfied with the default diff but have enough processing power for a 
slower algorithm that might produce diffs that better show the intention of the 
edit.

Thank you, Thomas Koch

Re: Searching explanation of different diff algorithms

[Ondřej Bílka]

On Wed, Sep 25, 2013 at 09:24:15AM +0200, Thomas Koch wrote:
> Is there any explanation available of the different merrits and drawbacks of 
> the diff algorithms that Git supports?
> 
> I'm not satisfied with the default diff but have enough processing power for a 
> slower algorithm that might produce diffs that better show the intention of the 
> edit.
> 
It is not just question of algorithm, even definition how should most
readable diff look like is problematic, for example when large block is
rewritten and one line is unchanged then you get diff like

if (x){
- foo
+ bar
} else {
- foo
+ bar
}

but it is better to create following diff as it does not break flow of code.

if (x) {
- foo
-} else {
- foo
+ bar
+} else {
+ bar
}

Re: Searching explanation of different diff algorithms

[Peter Oberndorfer]

On 2013-09-25 10:55, Ondřej Bílka wrote:
> On Wed, Sep 25, 2013 at 09:24:15AM +0200, Thomas Koch wrote:
>> Is there any explanation available of the different merrits and drawbacks of 
>> the diff algorithms that Git supports?
>>
>> I'm not satisfied with the default diff but have enough processing power for a 
>> slower algorithm that might produce diffs that better show the intention of the 
>> edit.
>>
> It is not just question of algorithm, even definition how should most
> readable diff look like is problematic, for example when large block is
> rewritten and one line is unchanged then you get diff like
> 
> if (x){
> - foo
> + bar
> } else {
> - foo
> + bar
> }
> 
> but it is better to create following diff as it does not break flow of code.
> 
> if (x) {
> - foo
> -} else {
> - foo
> + bar
> +} else {
> + bar
> }

I already asked the list for such a feature in the past[1].
I might be able to provide a rough/unfinished hack
that does exactly this in a few days after cleaning it up a bit.

It works like this:
If 2 hunks are separated by less than a certain count of lines and
those lines are identified as containing no "interesting information"
like {, }, /*, */, <whitespace> then the 2 hunks are fused together.

The hack is mainly lacking the following things:
* A way to identify boring lines.
(a like a list of boring keywords?, per filetype?)
* Configuration/commandline options to turn it on/off
* Tests
* Cleanup the code

Greetings Peter

[1] http://article.gmane.org/gmane.comp.version-control.git/207239/