git/contrib/diff-highlight/README
Jeff King 34d9819e0a diff-highlight: match multi-line hunks
Currently we only bother highlighting single-line hunks. The
rationale was that the purpose of highlighting is to point
out small changes between two similar lines that are
otherwise hard to see. However, that meant we missed similar
cases where two lines were changed together, like:

   -foo(buf);
   -bar(buf);
   +foo(obj->buf);
   +bar(obj->buf);

Each of those changes is simple, and would benefit from
highlighting (the "obj->" parts in this case).

This patch considers whole hunks at a time. For now, we
consider only the case where the hunk has the same number of
removed and added lines, and assume that the lines from each
segment correspond one-to-one. While this is just a
heuristic, in practice it seems to generate sensible
results (especially because we now omit highlighting on
completely-changed lines, so when our heuristic is wrong, we
tend to avoid highlighting at all).

Based on an original idea and implementation by Michał
Kiedrowicz.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-02-13 15:57:06 -08:00

60 lines
2.6 KiB
Plaintext

diff-highlight
==============
Line oriented diffs are great for reviewing code, because for most
hunks, you want to see the old and the new segments of code next to each
other. Sometimes, though, when an old line and a new line are very
similar, it's hard to immediately see the difference.
You can use "--color-words" to highlight only the changed portions of
lines. However, this can often be hard to read for code, as it loses
the line structure, and you end up with oddly formatted bits.
Instead, this script post-processes the line-oriented diff, finds pairs
of lines, and highlights the differing segments. It's currently very
simple and stupid about doing these tasks. In particular:
1. It will only highlight hunks in which the number of removed and
added lines is the same, and it will pair lines within the hunk by
position (so the first removed line is compared to the first added
line, and so forth). This is simple and tends to work well in
practice. More complex changes don't highlight well, so we tend to
exclude them due to the "same number of removed and added lines"
restriction. Or even if we do try to highlight them, they end up
not highlighting because of our "don't highlight if the whole line
would be highlighted" rule.
2. It will find the common prefix and suffix of two lines, and
consider everything in the middle to be "different". It could
instead do a real diff of the characters between the two lines and
find common subsequences. However, the point of the highlight is to
call attention to a certain area. Even if some small subset of the
highlighted area actually didn't change, that's OK. In practice it
ends up being more readable to just have a single blob on the line
showing the interesting bit.
The goal of the script is therefore not to be exact about highlighting
changes, but to call attention to areas of interest without being
visually distracting. Non-diff lines and existing diff coloration is
preserved; the intent is that the output should look exactly the same as
the input, except for the occasional highlight.
Use
---
You can try out the diff-highlight program with:
---------------------------------------------
git log -p --color | /path/to/diff-highlight
---------------------------------------------
If you want to use it all the time, drop it in your $PATH and put the
following in your git configuration:
---------------------------------------------
[pager]
log = diff-highlight | less
show = diff-highlight | less
diff = diff-highlight | less
---------------------------------------------