Thread (2 messages) flat view 2 messages, 2 authors, 2016-06-15

RFC: git diff colorization idea

From: Wincent Colaiuta <hidden>
Date: 2016-06-15 22:46:00

Hi,

Lately I've been wishing that Git's diff output were colorized in a  
way that combines the standard line-by-line colorizing with the word- 
by-word colorizing you get with --color-words.

Pictures speak louder than words, so here are some to show what I mean:

http://www.flickr.com/photos/wincent-colaiuta/sets/72157612877491482/

There you'll find:

1. A couple of sample hunks colorized in the current, standard way

2. The same hunks colorized with "--color-words"

3. The same hunks as they would be colorized if you could take the  
standard colorization (1) and augment it with per-word highlighting  
from (2)

(that last hunk would probably look better with a different regex  
defining what a "word" is; in reality all that happened was that  
"rename|" got added to the line, so there's no need to highlight more  
than that).

This is not a new idea; it's something that I find myself wanting due  
to experience with colorization available in a number of different  
diff viewers. Here are some more sample shots showing how different  
viewers do it, with varying degrees of prettiness/ugliness:

- Meld: http://meld.sourceforge.net/meld_file1.png

- kdiff: http://kdiff3.sourceforge.net/doc/letter_by_letter.png

- Apple FileMerge: http://homepage.mac.com/kelleherk/iblog/C711669388/E464913847/Media/compare_db_filemerge.jpg

No doubt there are others, but you get the idea.

Would people be interested in seeing this feature go in? I've already  
started snooping around diff.c seeing what would need to be done. From  
what I can tell it would require a new command-line switch (seeing as  
"--color" plus "--color-words" already means something), and probably  
two new customizable color slots (such as color.diff.new.word,  
color.diff.old.word).

The approach I was thinking of taking was just grabbing the diff_words  
info produced when --color-words is passed and using it to augment  
specialized versions of emit_line() and emit_add_line().

I'm also thinking that perhaps a per-character approach might be  
useful here instead of a per-word one (it would make that last hunk  
look better in the mock-up screenshot that I posted); if I go the per- 
character route then that suggests that "--color-chars" might be the  
right option name, and the color slots would then be  
color.diff.new.char and color.diff.old.char.

Any feedback or suggestions before I get in too deep?

Cheers,
Wincent
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help