Improved Git Diffs with Delta, Fzf and a Little Shell Scripting

I had been using delta for around a year and liked it, but still found some of the diffs I was looking a bit hard to read. A few weeks ago after a discussion on HN I tried difftastic, and have become a fan. You might want to consider it if you go down this rabbit hole. https://difftastic.wilfred.me.uk/

We've been building an open source tool called sem (https://github.com/ataraxy-labs/sem) that takes this one level further: entity-level diffs instead of AST-level.

Instead of showing you which syntax nodes changed, it shows you which functions, classes, and methods changed, classifies the change (text-only, syntax, functional), and walks a dependency graph to tell you the blast radius.

The delta + difftastic integration problem in that issue is interesting because sem already has the pieces both sides need, before/after content with full context for every changed entity, plus structured JSON output. The blocker in #535 is that difftastic's JSON doesn't include surrounding context. sem's output includes complete entity bodies by default.

Would love to collaborate on a common interchange format if anyone from the delta or difftastic projects is interested. Entity-level granularity sits naturally above AST-level diffs and below file-level diffs, and having a standard way to represent "what changed and what depends on it" would be useful for the whole ecosystem.

I had to give up on diff-so-fancy because it would break a lot when used with `git diff --patch` but this post just reminded me of the issue and it turns out that it has recently been fixed, so I may give it another go.

https://github.com/so-fancy/diff-so-fancy/issues/498

As someone who's used vim + a shell as my IDE since the start of my time using computers, it's been really awesome (and occasional eye-roll inducing...) watching people discover all these tools now that claude code is sending them into the terminal.

A lot of posts like this are making it to the front page of HN now that new people are exploring this world for the first time. That's great, the more the merrier, but gets a bit frustrating when a post title is written as if it's discovered some new awesome development tool or methodology, and it's just something people have been doing for years or even decades. This post isn't that big of an offender, but I'm thinking more of stuff like this [0] that it reminded me of.

I should try to be less grumpy about it, but I hope people also try to recognize how often these "new" tools they've been discovering have been routinely used long before LLMs. Maybe I'm just hitting my get-off-my-lawn stage, but it's a bit jarring to come to hacker news and see upvoted posts that are just "look, I can color the diffs in my terminal!". I'm glad this person discovered it, but I thought that was table stakes for the community here.

[0] https://x.com/dani_avila7/article/2023151176758268349

We've been building an open source tool called sem (https://github.com/ataraxy-labs/sem) that takes this one level further: entity-level diffs instead of AST-level.

https://github.com/so-fancy/diff-so-fancy/issues/498

Still waiting for Delta + Difftastic integration:

https://github.com/dandavison/delta/issues/535

Came here to say this, difftastic is great as long as you are working in a language where it understands the language tree (most languages). Getting away from diffs being focused on line changes to diffs that understand the actual language makes so much sense once you start to use it.

[0] https://x.com/dani_avila7/article/2023151176758268349

Having used both terminal and GUI based development environments, the good GUI environments blow terminal based workflows out of the water.

There are pros and cons to each. Vim can do some neat things, but GUI based IDEs are generally useful and easier to use out of the box for development.

The terminal tools are getting popular because people don’t need to do development. Claude is doing the development task. People just need to quickly review code in terminal.

Still waiting for Delta + Difftastic integration:

https://github.com/dandavison/delta/issues/535

Having used both terminal and GUI based development environments, the good GUI environments blow terminal based workflows out of the water.

There are pros and cons to each. Vim can do some neat things, but GUI based IDEs are generally useful and easier to use out of the box for development.

The terminal tools are getting popular because people don’t need to do development. Claude is doing the development task. People just need to quickly review code in terminal.

> but GUI based IDEs are generally useful and easier to use out of the box for development.

This is true, they are much better for discovery and affordance, but as you progress with your tooling and tool usage there is a much higher ceiling on your productivity with other tools and their composability. In my opinion, not putting effort into learning tools ultimately holds a lot of people back from their potential.

Why would you say GUI based workflows are better (ignoring LLMs for now)? I would maybe give you debugging with breakpoints but for anything else I love my neovim with tmux setup

Lol terminal is better for everything except maybe the one case you mentioned: first time use feature discovery, and that's debatable

I completely disagree. Terminal workflows are superior in a number of ways. Most important to me are that they are more composable and more customizable. The learning curve is tougher, but the "skill ceiling" on them is higher. The ease and speed with which somebody comfortable in their terminal based environment will navigate through the tasks they need to do will always exceed what is even possible in a GUI.

I would say that GUIs are superior for a few specific use cases, but otherwise sub par. Step through debugging comes to mind as a good GUI use case, but even that I'm not sure if it's because a GUI is inherently better, or making a terminal based debugger is harder and so nobody has made a good one yet.

> but GUI based IDEs are generally useful and easier to use out of the box for development.

I use both and mostly agree, but for me I don’t think the ROI for learning terminal based tooling is there.

They make some parts of text manipulation faster, but those parts of text manipulation take up less than 1% of my time spent working.

Things like debugging, which take up a large portion of my time, are not so nice in terminal based environments

Why would you say GUI based workflows are better (ignoring LLMs for now)? I would maybe give you debugging with breakpoints but for anything else I love my neovim with tmux setup

I spend more time reading and debugging code than writing it.

Vim and other terminal tools make doing complex text manipulation easy, but I rarely need to do anything complex when writing code.

I also work from different machines and ephemeral vms regularly and don’t want to spend time setting things up each time.

I can install vscode and the one lsp plugin I need in under a minute. In contrast, Vim doesn’t even have line number enabled by default.

Lol terminal is better for everything except maybe the one case you mentioned: first time use feature discovery, and that's debatable

That seems a little harsh. GUI tools can give us a more vibrant and useful interface.

But, I think the main problem is that although there have been many attempts we have not gotten to a standard way to compose different GUI tools easily or repeat actions.

I spend half or more of my time debugging and I think I would quit if I were forced to only use terminal based tools.

I use both and mostly agree, but for me I don’t think the ROI for learning terminal based tooling is there.

They make some parts of text manipulation faster, but those parts of text manipulation take up less than 1% of my time spent working.

Things like debugging, which take up a large portion of my time, are not so nice in terminal based environments

That seems a little harsh. GUI tools can give us a more vibrant and useful interface.

But, I think the main problem is that although there have been many attempts we have not gotten to a standard way to compose different GUI tools easily or repeat actions.

> Terminal workflows are superior in a number of ways

What specific ways do you find boost your productivity the most?

For me, the things terminal workflows can do faster take up almost a negligible amount of my workday.

Curious to hear if I’m missing out on a terminal workflow, or if my workday is just very different from yours

I spend half or more of my time debugging and I think I would quit if I were forced to only use terminal based tools.

> Terminal workflows are superior in a number of ways

What specific ways do you find boost your productivity the most?

For me, the things terminal workflows can do faster take up almost a negligible amount of my workday.

Curious to hear if I’m missing out on a terminal workflow, or if my workday is just very different from yours

I spend more time reading and debugging code than writing it.

Vim and other terminal tools make doing complex text manipulation easy, but I rarely need to do anything complex when writing code.

I also work from different machines and ephemeral vms regularly and don’t want to spend time setting things up each time.

I can install vscode and the one lsp plugin I need in under a minute. In contrast, Vim doesn’t even have line number enabled by default.

I don't think setup time is a fair comparison here. Any dev who cares to use CLI tools has a dotfiles repo that sets up everything in "under a minute".

What about installing the tooling needed to make various plugins work (ripgrep, fd, lsps, etc)?

And I work on different types of systems, which have different requirements and different ways of installing these tools.

Yes, there are other tools to help automate this process as well, but vscode “just works”

What about installing the tooling needed to make various plugins work (ripgrep, fd, lsps, etc)?

And I work on different types of systems, which have different requirements and different ways of installing these tools.

Yes, there are other tools to help automate this process as well, but vscode “just works”

Updated on March 24, 2026 in #dev-environment, #linux

awesome-git-diffs-with-delta-fzf-and-a-little-shell-scripting.jpg

Spotting differences in code is an important part of what we do, Delta is by far the best CLI diff tool I ever used.

Quick Jump:

Want to watch the video to see how it works? It’s on YouTube.

Around a year before writing this post I tricked out git to show its diffs with delta and created a little gd (git diff) script to make it easier to see diffs when doing PR reviews. It’s all up in my dotfiles.

Then I forgot to write a blog post about it because I guess internally I thought to myself “of course I wrote a post about this already, I use this almost every day”. Oops!

This is one of those posts where it’ll be easier for the both of us to watch the demo video to see how it works. My dotfiles have all of the code. If you already know you want it without watching that’s cool too, here’s some of the files of interest in text form.

# System Dependencies

If you plan to use delta, you’ll need to install it.

If you’re using my dotfiles it automatically handles installing everything for you on Arch Linux, Debian, Ubuntu and macOS. If not, you can find delta using whatever package manager is available on your OS. It’s the git-delta package in most.

If you want to use the gd script you’ll need to have fzf installed. Again, my dotfiles take care of installing this for you too. I can’t believe it’s been 10 years since I started using fzf. It’s a gift that keeps on giving.

# Shell Config

You’ll likely want to set export DELTA_FEATURES="diff-so-fancy" in your shell’s profile to get the improved (IMO) look of diffs by default. This gives you great looking diffs where you can see both character and word changes with dual tone colors (light and dark green, etc.).

# Git Integration

With only a tiny bit of git configuration, these git commands will start using Delta:

git show
git diff
git add -p
git blame

The above link shows how to configure your .gitconfig for this.

# Script

If you want to use the delta + fzf powered gd script, it’ll let you view git diffs with a custom fzf menu so you can quickly jump between files, it even supports an optional --side flag if you want side by side diffs:

Run gd in a git repo to view a git diff
Run gd main.. in a git repo to compare the checked out branch vs main
- I use this all the time for reviewing PRs, it’s invaluable!

The gd script passes the args directly over to git diff so commands like gd --staged or comparing your local branch with a remote “just works”. No new API to learn!

# ripgrep Support

You can use rg --json <search_pattern> | delta to have matches get highlighted with delta instead of rg’s default. I don’t use this a lot but wanted to include it because it’s neat.

The video below shows how all of these commands work.

BONUS: Since I recorded this video I also created a separate script for browsing and searching git log, it’s up in my dotfiles, I’ll make a future post about this at some point!

# Demo Video

Timestamps

0:22 – Character diffs are easy to spot
0:46 – The custom gd TUI with fzf
2:22 – Using normal git diff, add, blame and show commands
4:24 – Configuring git to use delta
5:28 – Configure Delta to use fancy diffs
6:42 – Installing Delta
7:27 – The gd TUI script
8:45 – Feeding rigrep’s output into delta

How do you view diffs? Let me know below.

Like you, I'm super protective of my inbox, so don't worry about getting spammed. You can expect a few emails per year (at most), and you can 1-click unsubscribe at any time. See what else you'll get too.

Hacker Times