Searching explanation of different diff algorithms

Thomas Koch· Sep 25, 2013, 07:24 UTC · lore

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

Ondřej Bílka· Sep 25, 2013, 08:55 UTC · re: Thomas Koch · lore

Re: Searching explanation of different diff algorithms

On Wed, Sep 25, 2013 at 09:24:15AM +0200, Thomas Koch wrote:

Show 7 quoted lines

> 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
}

Peter Oberndorfer· Sep 25, 2013, 15:30 UTC · re: Ondřej Bílka · lore

Re: Searching explanation of different diff algorithms

On 2013-09-25 10:55, Ondřej Bílka wrote:

Show 30 quoted lines

> 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/