[Pdx-pm] diff_painter.pl

[Joshua Keroes]

A useful non-Perl offering from the Googles:
http://code.google.com/p/google-diff-match-patch/

• diff with efficiency (diff by block(?), word, or character)
• fuzzy matching
• patching

Caveat: not Perl.

On Thu, Apr 14, 2011 at 11:06 PM, Aristotle Pagaltzis <pagaltzis at gmx.de>wrote:

> * Matthew Wickline <m_pm_pdx at wickline.org> [2011-04-14 07:35]:
> > I've added some examples. If you diff -u the before and after
> > files you should get something like the png at
> >
> >
> https://github.com/wickline/diff_painter/blob/master/examples/painted_diff.png
> >
> > Note that the bottom two block edits didn't render as block
> > edits because a rows was added or inserted. The script does not
> > try to merge lines when presented with N minus lines followed
> > by other-than-N plus lines. It only wants to merge N minus
> > lines with N plus lines.
>
> Ahh. I see. That was the case I was hitting at least in several
> of the cases it seemed to not be doing anything.
>
> It finally worked fine on other diffs since, so it *is* working.
>
> > Another case you might be hitting is that if too many edits are
> > done in a line, it decides that it would look better to show
> > you "this whole line changed into this other whole line" rather
> > than trying to merge the two lines.
>
> No. But there was one case where I had a single-line change where
> into which I had inserted a short substring, that diff_painter
> was not rendering as I expected, even though it seemed that it
> should be able to. Unfortunately I didn’t write down the commit
> in question so I can’t re-check now.
>
> Was this possibly because `git diff` merged the one-line change
> into a single diff hunk together with another change where one
> line was split into three?
>
> In that case it means diff_painter would be able to sprinkle its
> magic on more of the diff if the context is reduced (`-U0` in the
> extreme) – right?
>
> If so then it would be better to split the diff hunks on its own
> (ie collect +/- stretches between unchanged lines) instead of
> only relying on the numbers in the hunk head, and then operate
> on these sub-hunks. (Otherwise it’s useless for complex changes
> best read using `-U999` to get a before/after of the whole file,
> where it could do the most to help the reader.)
>
> > As for input, basically anything that looks like diff or diff
> > -u. That would include svn diff and git diff and git log -p.
>
> Right, yes.
>
> --
> Aristotle Pagaltzis // <http://plasmasturm.org/>
> _______________________________________________
> Pdx-pm-list mailing list
> Pdx-pm-list at pm.org
> http://mail.pm.org/mailman/listinfo/pdx-pm-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.pm.org/pipermail/pdx-pm-list/attachments/20110421/d475728d/attachment.html>