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 a pair of lines if they are the only two

lines in a hunk. It could instead try to match up "before" and

"after" lines for a given hunk into pairs of similar lines.

However, this may end up visually distracting, as the paired

lines would have other highlighted lines in between them. And in

practice, the lines which most need attention called to their

small, hard-to-see changes are touching only a single line.

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

---------------------------------------------

my $HIGHLIGHT = "\x1b[7m";

my $UNHIGHLIGHT = "\x1b[27m";

my $COLOR = qr/\x1b\[[0-9;]*m/;

my @window;

while (<>) {

# We highlight only single-line changes, so we need

# a 4-line window to make a decision on whether

# to highlight.

push @window, $_;

next if @window < 4;

if ($window[0] =~ /^$COLOR*(\@| )/ &&

$window[1] =~ /^$COLOR*-/ &&

$window[2] =~ /^$COLOR*\+/ &&

$window[3] !~ /^$COLOR*\+/) {

print shift @window;

show_pair(shift @window, shift @window);

}

else {

print shift @window;

}

# Most of the time there is enough output to keep things streaming,

# but for something like "git log -Sfoo", you can get one early

# commit and then many seconds of nothing. We want to show

# that one commit as soon as possible.

#

# Since we can receive arbitrary input, there's no optimal

# place to flush. Flushing on a blank line is a heuristic that

# happens to match git-log output.

if (!length) {

local $| = 1;

}

}

if (@window == 3 &&

$window[0] =~ /^$COLOR*(\@| )/ &&

$window[1] =~ /^$COLOR*-/ &&

$window[2] =~ /^$COLOR*\+/) {

print shift @window;

show_pair(shift @window, shift @window);

}

while (@window) {

print shift @window;

}

exit 0;

sub show_pair {

my @a = split_line(shift);

my @b = split_line(shift);

# Find common prefix, taking care to skip any ansi

# color codes.

my $seen_plusminus;

my ($pa, $pb) = (0, 0);

while ($pa < @a && $pb < @b) {

if ($a[$pa] =~ /$COLOR/) {

$pa++;

}

elsif ($b[$pb] =~ /$COLOR/) {

$pb++;

}

elsif ($a[$pa] eq $b[$pb]) {

$pa++;

$pb++;

}

elsif (!$seen_plusminus && $a[$pa] eq '-' && $b[$pb] eq '+') {

$seen_plusminus = 1;

$pa++;

$pb++;

}

else {

last;

}

}

# Find common suffix, ignoring colors.

my ($sa, $sb) = ($#a, $#b);

while ($sa >= $pa && $sb >= $pb) {

if ($a[$sa] =~ /$COLOR/) {

$sa--;

}

elsif ($b[$sb] =~ /$COLOR/) {

$sb--;

}

elsif ($a[$sa] eq $b[$sb]) {

$sa--;

$sb--;

}

else {

last;

}

}

print highlight(\@a, $pa, $sa);

print highlight(\@b, $pb, $sb);

}

sub split_line {

local $_ = shift;

return map { /$COLOR/ ? $_ : (split //) }

split /($COLOR*)/;

}

sub highlight {

my ($line, $prefix, $suffix) = @_;

return join('',

@{$line}[0..($prefix-1)],

$HIGHLIGHT,

@{$line}[$prefix..$suffix],

$UNHIGHLIGHT,

@{$line}[($suffix+1)..$#$line]

);

}

git-jump

========

Git-jump is a script for helping you jump to "interesting" parts of your

project in your editor. It works by outputting a set of interesting

spots in the "quickfix" format, which editors like vim can use as a

queue of places to visit (this feature is usually used to jump to errors

produced by a compiler). For example, given a diff like this:

------------------------------------

diff --git a/foo.c b/foo.c

index a655540..5a59044 100644

--- a/foo.c

+++ b/foo.c

@@ -1,3 +1,3 @@

int main(void) {

- printf("hello word!\n");

+ printf("hello world!\n");

}

-----------------------------------

git-jump will feed this to the editor:

-----------------------------------

foo.c:2: printf("hello word!\n");

-----------------------------------

Obviously this trivial case isn't that interesting; you could just open

`foo.c` yourself. But when you have many changes scattered across a

project, you can use the editor's support to "jump" from point to point.

Git-jump can generate three types of interesting lists:

1. The beginning of any diff hunks.

2. The beginning of any merge conflict markers.

3. Any grep matches.

Using git-jump

--------------

To use it, just drop git-jump in your PATH, and then invoke it like

this:

--------------------------------------------------

# jump to changes not yet staged for commit

git jump diff

# jump to changes that are staged for commit; you can give

# arbitrary diff options

git jump diff --cached

# jump to merge conflicts

git jump merge

# jump to all instances of foo_bar

git jump grep foo_bar

# same as above, but case-insensitive; you can give

# arbitrary grep options

git jump grep -i foo_bar

--------------------------------------------------

Related Programs

----------------

You can accomplish some of the same things with individual tools. For

example, you can use `git mergetool` to start vimdiff on each unmerged

file. `git jump merge` is for the vim-wielding luddite who just wants to

jump straight to the conflict text with no fanfare.

As of git v1.7.2, `git grep` knows the `--open-files-in-pager` option,

which does something similar to `git jump grep`. However, it is limited

to positioning the cursor to the correct line in only the first file,

leaving you to locate subsequent hits in that file or other files using

the editor or pager. By contrast, git-jump provides the editor with a

complete list of files and line numbers for each match.

Limitations

-----------

This scripts was written and tested with vim. Given that the quickfix

format is the same as what gcc produces, I expect emacs users have a

similar feature for iterating through the list, but I know nothing about

how to activate it.

The shell snippets to generate the quickfix lines will almost certainly

choke on filenames with exotic characters (like newlines).

usage() {

cat <<\EOF

}

open_editor() {

editor=`git var GIT_EDITOR`

eval "$editor -q \$1"

}

mode_diff() {

git diff --relative "$@" |

perl -ne '

}

mode_merge() {

git ls-files -u |

perl -pe 's/^.*?\t//' |

sort -u |

while IFS= read fn; do

grep -Hn '^<<<<<<<' "$fn"

done

}

mode_grep() {

git grep -n "$@" |

perl -pe '

}

if test $# -lt 1; then

usage >&2

exit 1

mode=$1; shift

trap 'rm -f "$tmp"' 0 1 2 3 15

tmp=`mktemp -t git-jump.XXXXXX` || exit 1

type "mode_$mode" >/dev/null 2>&1 || { usage >&2; exit 1; }

"mode_$mode" "$@" >"$tmp"

test -s "$tmp" || exit 0

open_editor "$tmp"