Re: possible Improving diff algoritm

From: Junio C Hamano <gitster@pobox.com>
Date: Dec 13, 2012, 06:26 UTC
Message-ID: <7vzk1izcv6.fsf@alter.siamese.dyndns.org>
In-Reply-To: <B1564B28-9BB9-48A2-B59E-7D7C0B0DDECF@adacore.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.