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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
