RFC: git diff colorization idea

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux