How to use --color-words with git add --patch?

Question

When diffing files, I prefer to use git diff --color-words. Is there a way to make this the default format for diffs when using git add --patch or

Answer 1

With git 2.9 (June 2016), you will have a new option: interactive.diffFilter.

See commit 0114384 (27 Feb 2016) by Jeff King (peff).
^{(Merged by Junio C Hamano -- gitster -- in commit 2052c52, 03 Apr 2016)}

add --interactive: allow custom diff highlighting programs

The patch hunk selector of add--interactive knows how ask git for colorized diffs, and correlate them with the uncolored diffs we apply. But there's not any way for somebody who uses a diff-filter tool like contrib's diff-highlight to see their normal highlighting.

This patch lets users define an arbitrary shell command to pipe the colorized diff through. The exact output shouldn't matter (since we just show the result to humans) as long as it is line-compatible with the original diff (so that hunk-splitting can split the colorized version, too).

You could then pipe that diff to a diff --color-words.

As commented by Andrew Dufresne, the GitHub blog post refers to the contrib script contrib/diff-highlight:

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.

The result puts an extra emphasis on the changed part of a line:

Regarding those diffs, "diff-highlight" filter (in contrib/) learned to undertand "git log --graph" output better.

See commit 4551fbb, commit 009a81e, commit fbcf99e, commit 7ce2f4c, commit e28ae50, commit 53ab9f0, commit 5013acc (21 Mar 2018) by Jeff King (peff).
^{(Merged by Junio C Hamano -- gitster -- in commit d19e556, 10 Apr 2018)}

See more in "diff-highlight: detect --graph by indent"

---

Note: before Git 2.17 (Q2 2018), The "interactive.diffFilter" used by "git add -i" must retain one-to-one correspondence between its input and output, but it was not enforced and caused end-user confusion.

We now at least make sure the filtered result has the same number of lines as its input to detect a broken filter.

See commit 42f7d45, commit af3570e (03 Mar 2018) by Jeff King (peff).
^{(Merged by Junio C Hamano -- gitster -- in commit c5e2df0, 14 Mar 2018)}