Diff So Fancy: make Git diffs look good

There's no easy install methods for small simple scripts that doesn't involve multiple manual steps, have an automated upgrade path, is cross platform and is consistent+familiar to a large subset of developers.

Of the options out there for the above, npm - while hassle if you don't have it already installed - is probably the closest balance of maintainer and end-developer convenience.

phinnaeus2• 10 years ago

Thanks for the explanation! I went ahead and installed npm to use this, I think it's a pretty nifty little utility and worth it.

hobarrera4• 10 years ago

make install?

pierrebeaucamp2• 10 years ago

I know he gave credit in the README, but why does this ~30 line shell script need its own repo? Seems more like a cheap grab for Github Stars rather than to provide actual value.

Edit: Even the screenshot is from Paul...

paulirish3• 10 years ago

A bit ago, I had indicated this script should be more accessible than copying two separate files out of my dotfiles repo: https://github.com/paulirish/dotfiles/blob/master/bin/diff-s...

Steve took the initiative to put this in it's own repo. Seems okay; I was being rather slow to ship it for real.

pierrebeaucamp2• 10 years ago

All good then ;)

ceejayoz• 10 years ago

Sheesh. The repo allows the stuff like installing it via `npm install -g diff-so-fancy`. It's not like a public repo costs anything, and Github stars don't get you anything either.

stevemao3• 10 years ago

I think it makes it easier to add contributors. Git doesn't allow a user partially access a repo so Paul would add a few people only contributing on one script. I added some really talented contributors :) The repo under my name doesn't mean it belongs to me. In fact it belongs to the public. Everyone can contribute to it so everyone is the "owner". That's how I see open source projects. I don't mind giving it back to Paul. I did it only because I needed it. I believe a lot of people would want it more accessible too.

jrochkind1• 10 years ago

Why doesn't any code you are using need it's own repo, to track history, what does it matter how short it is?

chaitanya• 10 years ago

Might be better to link to the source directly: https://github.com/paulirish/dotfiles/blob/master/bin/diff-s...

izolate• 10 years ago

Remove contextual +/- in favour of colour highlights? As a person with red-green colourblindness all I can say is: Lol. Nope.

scrollaway• 10 years ago

You know you can customize the diff colors, yes?

From the git book itself: `git config --global color.diff.meta "blue black bold"`

brokentone• 10 years ago

That's a helpful perspective, but hopefully you already have workarounds on the color issue. This is simply making diff pieces easier to copy / pasta -- which I for one have needed to do. Change my mind on a refactor midstream, need to restore part of the file, etc.

tomjakubowski2• 10 years ago

You might investigate the tools your editor of choice provides for working with diffs. You might be surprised at how easy it can be!

(In Emacs, if you're using git, magit is an amazing package. You can select a commit from the logs, dive into the diff for a file caused by that commit, highlight a region of the diff and revert the change in your working copy. It's wonderful.)

jimrandomh• 10 years ago

A personal pet peeve of mine when reading diffs, is when a file has some functions and you insert one and instead of looking like this:

     int someOldFunction()
     {
         // Function body
     }
    +
    +int newFunction()
    +{
    +    // New function body
    +}

It looks like this:

     int someOldFunction()
     {
         // Function body
    +}
    +
    +int newFunction()
    +{
    +    // New function body
     }

It's a small thing, but given that these diffs are equivalent, the one that balances the curly braces within added blocks should be favored. But diff utilities seem to get this pretty consistently wrong.

stormbrew• 10 years ago

    git diff --patience

might give you better results? I've seen this pattern too, but I can't find a reproduction of normal git diff giving it to me at the moment.

stock_toaster• 10 years ago

I use this in my ~/.gitconfig

   [diff]
   algorithm = patience

paulirish3• 10 years ago

I've experimented with patience diff, but not seen it deliver reliably superior results than myers (the current default).

FaceKicker• 10 years ago

I tried GP's example, and in this particular case both --patience and the default (Myers) work the same, both doing the thing you want them to. Which perplexes me, because I know I've seen the bad case too, but can't seem to find a minimal example of it (I tried a couple variations on the example; they all did the 'right' thing).

Klathmon• 10 years ago

It is a small thing, but it throws me off everytime i see it, and then it takes a few seconds of looking around before it dawns on me what happened.

The "user" in me would love a language aware diffing (and merging) system, but the developer in me is already groaning about how much work that would end up taking for arguably not that much benefit.

alexvoda• 10 years ago

Maybe this will help: https://www.semanticmerge.com/

skybrian• 10 years ago

I don't think it has to be truly language aware. A diff tool that looks for matched braces, quotes, and indents to figure out where the blocks are would do better most of the time.

digikata• 10 years ago

I think it might be easier to get to a syntax-aware diff if one approached it reusing the language specific syntax highlighting specs used in various editors. I've almost sat down to start that myself a few times.

cyphar• 10 years ago

diff --patience uses a different algorithm that works to optimise the diffed number of lines (it's less efficient though), which will probably solve your issue (the way the standard algorithm works is to essentially find common features on a first-come-first-served basis.

masklinn• 10 years ago

The two diffs have exactly the same number of lines here, the difference is which lines are selected as part of the insertion.

whalesalad• 10 years ago

Clojure (lisp) is even more fucky because adding a single outer form can re-indent (and therefore modify) an entire huge block of code.

At least on GitHub we have the ?w=1 URL parameter on PRs which helps a bit.

wldlyinaccurate• 10 years ago

Protip: ?w=1 on GitHub is synonymous with git-diff's -w flag.

piyush_soni• 10 years ago

I find Araxis Merge especially useful in these times. This application has a feature to "set the synchronization link" at any place you want in the code. It is not automatic (or language aware), but once you realize the difference, you can 'fix' the diff in real time. That helped me a lot for big diff files (unfortunately in my current company we don't use Araxis :( )

DannyBee• 10 years ago

That's because they all use greedy O(ND) algorithms or equivalent.

But conceptually, no matter what the algorithm, the greediness is usually a requirement to maintaining the theoretical time bound of LCS based algorithms.

Patience trades the time bound for "better" results (patience is worst case O(ND^2).

Histogram is a neatly engineered and extended version of patience with an O(ND) timebound (and in fact, is faster than both myers and patience while providing good patience-like output).

finnn• 10 years ago

So, the whole npm thing seems weird to me, then it occurred to me that it could be for malicious purposes. Would it be possible to upload a separate package.json to npm that had eg a post-install script? I don't know much about how npm works from the package publication side of things, but I assumed it was similar to pypi where the code in the git repo doesn't have to be at all related to the code in the package

merb• 10 years ago

this doesn't look useful. the left one is just fine. for everything else you wouldn't need a cli diff tool...

nqzero3• 10 years ago

when one or 2 words change in a long or dense line, it's nice to have the specific changes highlighted

imagine a for loop in which a variable (used on every line) was renamed, and buried in the loop an assignment changed slightly (eg, + became -). with a standard diff, it's really hard (for me) to pick up the minor change. with word by word diffs, it's pretty easy

(i use netbeans diff, not this tool, but they appear similar)

djur• 10 years ago

git has built-in word diffing with --word-diff, though. --word-diff=color does almost exactly the same thing.

timtadh• 10 years ago

    git diff --word-diff=color

provides a really nice word diff with coloring similar to this project. Just setup an alias in your global gitconfig:

    [alias]
            cdiff = diff --word-diff=color

mrinterweb• 10 years ago

Vim's fugitive plugin also gives a similar split diff view. The command is "Gdiff".

ilikepi• 10 years ago

Even without the plugin, you can spawn a diff in vim via git's difftool settings. Here's a basic version that can be used in one's .gitconfig:

    [diff]
      tool = customvim
    [difftool "customvim"]
      cmd = vim -R -f -d \"$LOCAL\" \"$REMOTE\"

paulirish3• 10 years ago

[I'm the author of diff-so-fancy, Steve helped with shipping it as a standalone script]

NPM?!? :)

A lot of people below are asking why a bash script (that depends on a perl script) is being recommended to install via NPM? The short reason is that NPM is the most straightforward way to get a script installed as a global binary in a cross-platform manner. This approach has worked quite well with `git-open`[0]. Asking all users to deal with the PATH is not my ideal.

In addition, I wanted a reasonable upgrade path, in case there are neccessary bugfixes. It's not a great experience if users identify bugs but the fix means they manually find it/download/PATH-ify each time. :/

That said, I'll add some Manual Install instructions to the readme so it's clear how to do this on your own. :) ( Edit: Here they are… https://github.com/stevemao/diff-so-fancy/blob/master/readme... )

[0] https://github.com/paulirish/git-open

Manishearth• 10 years ago

That said, I'll add some Manual Install instructions to the readme so it's clear how to do this on your own

Yeah, that helps a lot :)

I saw this, was like "cool, I want to use this", and then noted that it uses npm. I avoid installing ruby and node apps -- I have nothing against either, just that I currently don't use either language or have a dependency on a major tool written in those; but they pull in a lot of deps which take up space (at least, my experiences have been that many of these tools install way too much -- probably because I don't use either and all the "default libs" aren't on my system). On my previous machine I had lots of issues with this, so as a rule I avoid these things unless absolutely necessary. I know others who are of a similar opinion.

Fortunately I realized that it was just a shell script, and installed it directly :)

satbyy• 10 years ago

The short reason is that NPM is the most straightforward way to get a script installed as a global binary in a cross-platform manner

Really ? All Unix-like systems (incl OS X) can do this:

    /usr/bin/install myscript.sh /usr/local/bin

PS: Oh, just realized that there is npm uninstall as well, but not /usr/bin/uninstall (though it's just rm -f anyway)

goldbrick4• 10 years ago

`install` isn't package management, or anything close to that.

semi-extrinsic5• 10 years ago

Wouldn't it be easier for the end user if you used pip/PyPi? Essentially all Linux distros include Python, but there are very few that ship with Node.js installed by default.

LyndsySimon3• 10 years ago

I can only speak for myself, but my systems all prohibit installation of packages into the system Python namespace by default.

goldbrick4• 10 years ago

And most of distros don't come with pip, so we're back at square one.

stevemao3• 10 years ago

I see a lot of projects that's written in other languages on npm, especially bash. Substack even published c code to npm. I think it makes the script more accessible especially for nodejs users. I don't mind publishing it to other package mangers.

txutxu2• 10 years ago

Please do not confuse 'more accessible specially for', with 'less accessible and exclusively for' nodejs users.

viraptor• 10 years ago

Or use FPM (https://github.com/jordansissel/fpm/wiki) and abstract the whole packaging idea. linux and mac packages supported.

gkya3• 10 years ago

I had no reasons to use this package, but now I have one to not use it. I only wanted to see what it was because the name suggested something fun.

Why whould someone who can't add $HOME/bin to $PATH be using git?

argonaut• 10 years ago

I realize your question is rhetorical, but there are tons of people. Anyone new to programming, in a CS course that uses git, for example, would be familiar with basic git but many would be unfamiliar with the path (or on Windows).

crottypeter• 10 years ago

git is a content tracker.

People who don't need to edit PATH might still need to track content.

hobarrera4• 10 years ago

Last I tried, npm didn't even work on IPv6, even if there's some transition mechanism in place (eg: NAT64).

It's really pretty awful as a distribution mechanism. Why not a simple Makefile?

_ZeD_• 10 years ago

what are the advantages over colordiff[0]? (or a graphic differ like kdiff3[1])

[0] http://www.colordiff.org/ [1] http://kdiff3.sourceforge.net/

jfountain2015• 10 years ago

Nice improvement to diff but I think I'll still use `git difftool` with Diffmerge https://sourcegear.com/diffmerge/

FiloSottile• 10 years ago

If you don't want your diff so fancy (pun intended, and I'm sorry) but you still want the inline highlights, the script comes with git (https://github.com/git/git/tree/master/contrib/diff-highligh...):

    ln -sf "$(brew --prefix)/share/git-core/contrib/diff-highlight/diff-highlight" ~/bin/diff-highlight

and add to .gitconfig

    [pager]
            log = diff-highlight | less
            show = diff-highlight | less
            diff = diff-highlight | less

makecheck2• 10 years ago

I handle this in a way that is more agnostic to the type of revision control, and fully flexible in coloring (using the most powerful scheme available).

For example, I shouldn't have to put up with basic colors if the terminal can do better.

Here is how it works; starting with:

  #!/bin/bash 
  if [ -r ".svn" ] ; then
    exec svn diff ${1+"$@"} | my_colorize_diff
  else
    git diff ${1+"$@"} | my_colorize_diff
  fi

...where the "my_colorize_diff" script at the end of the pipe is as follows:

  #!/usr/bin/env perl
  # by Kevin Grant (kmg@mac.com)
  my $term_program = (exists $ENV{'TERM_PROGRAM'} && defined $ENV{'TERM_PROGRAM'}) ? $ENV{'TERM_PROGRAM'} : '';
  my $term = (exists $ENV{'TERM'} && defined $ENV{'TERM'}) ? $ENV{'TERM'} : 'vt100';
  my $is_xterm = ($term =~ /xterm/);
  my $is_24bit = ($term_program =~ /MacTerm/);
  print "\033#3BEGIN DIFF\n";
  print "\033#4BEGIN DIFF\n\033#5";
  while (<>) {
    if (/^\+/ && !/^\+\+/) {
      if ($is_24bit) {
        print "\033[48:2:150:200:150m", "\033[2K", "\033[38:2::88:m", "\033[1m";
      } elsif ($is_xterm) {
        print "\033[48;5;149m", "\033[2K", "\033[38;5;235m", "\033[1m";
      } else {
        print "\033[42m", "\033[2K", "\033[30m", "\033[1m";
      }
    } elsif (/^\-/ && !/^\-\-/) {
      if ($is_24bit) {
        print "\033[48:2:244:150:150m", "\033[2K", "\033[38:2:144:0::m";
      } elsif ($is_xterm) {
        print "\033[48;5;52m", "\033[2K", "\033[38;5;124m";
      } else {
        print "\033[41m", "\033[2K", "\033[37m";
      }
    } else {
      print "\033[3m";
    }
    chomp;
    print;
    print "\033[0m\n";
  }
  print "\033#3END DIFF\n";
  print "\033#4END DIFF\n\033#5";

thristian• 10 years ago

For what it's worth, there's a lot of 24-bit-capable terminals that aren't MacTerm. Even xterm supports the 24-bit-color sequences, although it picks the closest entry in its 256-colour palette rather than using the 24-bit colour directly.

Also, you seem to be assuming "xterm" supports 256 colours and everything else doesn't. The best way to figure out how many colours the terminal supports is $(tput colours). tput also looks up other useful sequences; you can "tput bold" to turn on bold mode, "tput setaf 12" to set the foreground to colour 12 (bright yellow), "tput sgr0" to zero all active formatting, etc.

makecheck2• 10 years ago

Good point. Although, unless there are shells that have "tput" built-in, that means more subprocesses to obtain basic information (which would slow down the result a bit). In my case, the environment is sufficient to figure out what to do.

AdmiralAsshat• 10 years ago

So what does this offer over simply using vimdiff?

oabm• 10 years ago

What happened to this line from the second file in the screenshot?

  -        var optionsGlassPane = new WebInspector.GlassPane(document);

An important part of viewing diffs for me is seeing what the old code was.

nqzero3• 10 years ago

the netbeans.team.diff tool is similar (showing the specific words that changed), allows interactive editing, and does a good job even with large insertions and deletions

Animats• 10 years ago

Hurts. Hurts bad. Tiny type in many primary colors on a black background. 1985 called, it wants its screen layout back.

mschuster91• 10 years ago

what I'd like to see is that a/b in front of the filenames disappear. Getting rid of that would FINALLY allow me to double-click on the filename (which is configured to select the part between the spaces and copy it to the clipboard) and paste it instantly for the next command... or to be able to do git diff > foo.patch and on another system do patch < foo.patch without having to remember the correct -p value.

datashaman• 10 years ago

git diff --no-prefix

tremguy• 10 years ago

No pesky + or - at line-stars, making for easier copy-paste.

I wonder if easing copypasting is a good or bad thing..

module17• 10 years ago

It looks so good and real, I kept hitting `q` whilst looking at the image.

GreaterFool• 10 years ago

Is there any language aware diff tool? I think I saw some commercial product for Java but other than that I haven't seen any attempts to do that.

nikolay• 10 years ago

I find icdiff [0] (Improved Colored Diff) better.

[0] https://github.com/jeffkaufman

samuell• 10 years ago

When writing manuscripts in git, my favourite "trick" is git diff --word-diff (of course aliased to git wdiff).

felipesabino• 10 years ago

I have an alias for the diff params bellow, which has basically the same visual result, without the need to install anything.

  $ git diff --color --color-words --abbrev

stevemao3• 10 years ago

We've grown and it's out of control. diff-so-fancy moved to an org!!! https://github.com/so-fancy/diff-so-fancy

hobarrera4• 10 years ago

I didn't quite like this, put it does reference diff-hightlight, which is part of git-contrib (so it may already be installed on your system, but just not in your $PATH!):

https://github.com/git/git/tree/master/contrib/diff-highligh...

For example, here's a diff where it improved readability enormously:

https://i.imgur.com/8iQNaeu.png

hobarrera4• 10 years ago

Yes, the code in that sample is horrible triplicate. Please ignore that.

Diff So Fancy: make Git diffs look good

Related Stories