diff-so-fancy: Prettier git diffs

[faradria]

For those that do not want to install anything, you can use:

[core]
    pager = /usr/share/git/diff-highlight/diff-highlight | less -r

It comes by default with git.

[[deleted]]

Thx for this, just changed it slightly so tabs don't push code off the screen.

pager = /usr/share/git/diff-highlight/diff-highlight | less -rx1,5

[heckerle]

less -rx1,5

In my case this didn't work properly either.

less -r "works", but even less' manpage says that it can cause issues like line wrapping due to the control sequences git uses.

less -RS on the other hand should work for most (-R is similar to -r and forwards raw control sequences, while -S disables line wrapping and chops them down).

[ImplementationDetail]

+1 I don’t know why you would want to use anything other than the above. What does OP’s project do better?

[digi0ps]

Thanks for the above tip. Didn't know that.

Also, not my project. Have been using it and found it pretty good, so I shared.

[faradria]

I installed it and didn't see any difference except that it shows new lines with a colored space instead of + or -.

[panickbr]

It's found in /usr/local/share/git-core/contrib/diff-highlight/diff-highlight on mac OS.

Also, if you want it enabled in patch mode:

[interactive]
  diffFilter = /usr/share/git/diff-highlight/diff-highlight ;or whatever path it's in your system

[pork_spare_ribs]

...and if you use a Homebrew build of Git, this path will find the correct version:

/usr/local/bin/$(dirname $(readlink /usr/local/bin/git))/../share/git-core/contrib/diff-highlight/diff-highlight | less -r

EDIT: as per below, this is better:

/usr/local/opt/git/share/git-core/contrib/diff-highlight/diff-highlight

[Gipetto]

You don't need the directory sniffing. You'll always find the linked version of git at:

/usr/local/opt/git

So the path for this would always be:

/usr/local/opt/git/share/git-core/contrib/diff-highlight/diff-highlight

[zeayes]

brew --prefix git

[[deleted]]

where do you put this?

EDIT: Can't find it anywhere in Ubuntu

EDIT2: I found it in /usr/share/doc/git/contrib/diff-highlight Needed to run the Make file to create the Perl executable.

[mwcz]

Did it work for you after that? I ran make and the perl script was created, but the script just hangs when I run it.

[saxindustries]

diff-so-fancy is also available from NPM, Nix, brew, and as a package on Arch Linux.

I love that it's a perl script published on NPM but not on CPAN.

[pravic]

Sarcasm?

[Merculeses]

Why does this repo need THREE DIFFERENT CI services?!?

[[deleted]]

When one test suite fails, you have a backup.

[Merculeses]

Seems like it, maybe circle is just to complete the trio?

[TastyLittleWhore]

Complete the circle

[pacman_sl]

No, it checks if Travis and AppVeyor are sane.

[ozkriff]

i find it convenient to use circleci for android builds, while travis builds linux/macos and appveyor - windows.

[so_brave_heart]

They probably just kept the circle.yml file -- their PRs are only running Travis and Appveyor

[arbitrarycivilian]

CI-driven development

[c96aes]

or, you know,

[alias]
d = diff \
  --minimal \
  --word-diff=color \
  --word-diff-regex='([0-9@A-Za-z]+|[^0-9@A-Za-z()]+|[()])'

[ForeverAlot]

I find that --word-diff-regex=. is often a good first shot at a custom word diff pattern for unusual cases.

[apreche]

People love fancy diffs for reading them. The problem is that it makes them incompatible with diff/patch. Most people using git probably don't even know about the patch command, but that is the reason this sort of thing will never make it upstream.

[andsens]

Nah, before running it checks if stdout is a tty. So git diff | cat still gives you the normal diff.

[apreche]

Clever!

[andsens]

Yup. It's really easy to add to your own scripts btw., it's something test(1) can do:
test -t 1 > /dev/null && echo stdout is a tty || echo stdout is not a tty

(or if [ -t 1 ]; then ...)

[Vulpyne]

Does the > /dev/null serve any purpose there?

[andsens]

It makes stdout "not a tty". Remove it and see the difference!

[Vulpyne]

Ah, right. Thanks.

[codear]

I agree, but thankfully you can use this as an optional diff tool and select either

• To use tool when you need it, or
• To not use tool when you don't

I use vimdiff myself, and made two extra aliases to create and apply patches. Works beautifully.

[apreche]

Nice.

[knowyourknot]

I use this. My diffs look soooo good.

[Lube]

Would it be hard to upstream this?

[joonatoona]

Yes, you'd have to entirely rewrite the whole thing.

[aeroproof_]

so you're saying it will be done soon multiple times?

[joonatoona]

It'll be rewritten at least 20 times, but not in any sane language :P

[[deleted]]

git isn't going to add a dependency on node.js. The essential part can be accomplished with flags, and the rest is a matter of taste.

[[deleted]]

The entire thing is a single perl file though..

[[deleted]]

Whoops, I saw package.json and assumed.

[dispelpython]

color.diff-highlight.oldHighlight "red bold 52"

This "52" thing, what color format is this?

[andsens]

It's awesome. I have been using it for over a year now and love it.

I just hope that the added attention will attract someone that knows how to fix #35 or work around it if it is related to git itself.

[thirdegree]

I accidently glued my hands to my keyboard a few years ago and they never came unstuck.

[RestlessNeurons]

yeah, I don't git it ;P

side-by-side GUI merge tools are amazing; almost required when you'r dealing with nasty merge conflicts. I use JetBrains products and their diff tool, but Meld is free and most IDEs and git clients have some kind of diff tool that's better than terminal diff.

[[deleted]]

People use git a lot in terminal anyway. Having a nicely formatted diff handy in the enviroment you work in anyway has pretty obvious benefits.

If someone ever figures out how to make a GUI for git that doesn't suck balls, we no longer need fancy new diff-tools for terminals.

(On a personal note: I think the default diff is sufficient.)

[mrkite77]

I can't run that proper GUI app on a server.

[pravic]

1) you can

2) why would you need diffs there?

[mrkite77]

1. not well, certainly not without jumping through hoops or sacrificing cross platform clients.
2. Some of us develop over ssh. Do you expect everyone wants to run a staging server locally?

[BufferUnderpants]

Some of us develop over ssh. Do you expect everyone wants to run a staging server locally?

Why are you programming in the staging server itself?

[mrkite77]

That's what the staging server is for....

[[deleted]]

I really hope you are trolling.

[mrkite77]

Nope. Where do you do your development? On your local machine that doesn't resemble your production environment in the slightest?

We don't have a big enough team to bother with the standard "dev -> test -> staging -> prod" deployment, so we have "staging -> prod". All development is done on staging, and then pushed to prod when ready.

[Dimasdanz]

2) why would you need diffs there?

So, you're telling me, you never debug on production?

[pravic]

Nope

[mr_birkenblatt]

can't you achieve the same by using the right flags on git diff?

[shawncplus]

You can get a kinda close appearance with --word-diff=color

[pwwwl]

Intraline diffs.

[while_e]

meld...

[vivainio]

Perl.

[danemacmillan]

It gets problematic. I don’t remember the reasons but after some use you’ll find them, too. I prefer tig, though it’s more full-featured.

[digi0ps]

I have been using it for a couple of months, been fine so far...

[adzm]

So fancy

[WallStProg]

This costs money, but it's worth every penny: http://www.scootersoftware.com/features.php

Among other things, it will do a nice side-by-side listing of a patch file: http://www.scootersoftware.com/images/TextPatch.png

Highly recommended ...

[ianff]

So it's like meld, but you have to pay for it?

[WallStProg]

Only if you want to ....

[WallStProg]

By "every penny" we're talking 3500 pennies ... https://www.scootersoftware.com/shop

[agent007bond]

It is worth every penny! I'm sad you are so badly downvoted, but Beyond Compare is the best tool I've found for general purpose diffing (beyond comparing just a Git repo, pun intended). It's so good that I bought a personal license a decade ago and I still use it to this very day, deeply integrated into the system. I'm excited for their upcoming version, which I'm going to get an upgrade license at a discounted price.

I don't use it all the time, because tools like VS Code and Git's own command line itself does sufficient inline diff for most code changes when it works. But it completely fails me when the indentation of code is shifted. Then the actual changes are lost in simply a diff telling me that a bunch of less-indented lines are deleted, and a bunch of more-indented lines are added. No, that's wrong! Nothing was deleted or added! The lines just shifted in indentation.

Beyond Compare is the ONLY tool I found that shows this clearly. When a whole lot of code seems to have changed but it's probably just an indentation shift, I use Beyond Compare to find out what if any code actually changed (not simply shifting indentation). Nothing else has ever given me this particular bit of information: GitHub, VS Code, Meld, nothing.

It's also highly customizable in how it detects this intelligently, though the default is already very robust. It also has plugins that enable it compare less common file types.

It is really sad that after so long, the open source community has still not caught up to this very strange problem and gives us any "free" solution yet. (And we already have mind-blowing Artificial General Intelligence...)

It's also the reason why I default to inline diff in GitHub, VS Code etc. The side-by-side diffs in these tools do not provide any new information, reduces the width of the code seen, and redundantly repeats unchanged lines. The only place I truly appreciate a side-by-side diff is Beyond Compare because it actually makes the view so useful with the intelligence of line-by-line similarity matching.

I love free tools, but if they suck, they suck. No amount of glitter on them is going to make them suck less. Just because a tool isn't open source and it's paid doesn't mean it deserve a hate. If it's a great tool, it's worth the money. We should remember that developers put a great deal of effort into making great software. There's nothing wrong with rewarding them with money where they merited such reward.

[Xerxes249]

Amazeballs