Re: possible Improving diff algoritm

[Junio C Hamano <gitster@pobox.com>]

Geert Bosch <bosch@adacore.com> writes:

> It would seem that just looking at the line length (stripped) of
> the last line, might be sufficient for cost function to minimize.
> Here the some would be 3 vs 0. In case of ties, use the last
> possibility with minimum cost.

-- 8< --
#ifdef A

some stuff
about A

#endif
#ifdef Z

some more stuff
about Z

#endif
-- >8 --

If you insert a block for M following the existing formatting
convention in the middle, your heuristics will pick the blank line
after "about A" as having minimum cost, no?

You inherently have to know the nature of the payload, as your eyes
that judge the result use that knowledge when doing so, I am afraid.
I think your "define a function that gives a good score to lines
that are likely to be good breaking points" idea has merit, but I
think that should be tied to the content type, most likely via the
attribute mechanism.

In any case, I consider this as a low-impact (as Michael Haggerty
noted, it is impossible to introduce a bug that subtly break the
output; your result is either totally borked or is correct) and
low-hanging fruit (it can be done as a postprocessing phase after
the xdiff machinery has done the heavy-lifting of computing LCA), if
somebody wants to experiment and implement one.  As long as the new
heuristics is hidden behind an explicit command line option to avoid
other "consequences", I wouldn't discourage interested parties from
working on it.  It is not just my itch, though.