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/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html