Hi,
On Sat, 14 Feb 2009, Junio C Hamano wrote:
> I also noticed that the diff was impossible to read because it
> matched the lines with only an indented close brace or whitespace
> between the preimage and the postimage too aggressively. Your
> --patience did seem to help a little bit, at least it produced a
> different result, but not much (not that patience was meant to make
> this kind of change easier to read). It may have helped if we had
> that "do not match trivial lines too aggressively just to reduce the
> patch size" option.
Yeah, I think that your objections to my '--collapse-non-alnums' patch
show to be relevant especially with this patch: an '} else {' matches, but
actually disturbs readability.
So an option would be nice, indeed, which can merge a single matching line
(or a given maximal number of matching lines) between runs of a certain
minimal number of _non-matching_ lines.
But how to call it?
And how determine the ideal ratio between matching/non-matching lines
until which to consider the matching lines to be non-matches? Maybe a
simple fraction would be enough...
Or maybe an absolute number of matching lines? But it is obvious how to
construct a case where this breaks down.
Ciao,
Dscho
--
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
