[HN Gopher] Improved Git Diffs with Delta, Fzf and a Little Shel...
___________________________________________________________________
Improved Git Diffs with Delta, Fzf and a Little Shell Scripting
Author : nickjj
Score : 106 points
Date : 2026-03-24 15:02 UTC (4 days ago)
(HTM) web link (nickjanetakis.com)
(TXT) w3m dump (nickjanetakis.com)
| linsomniac wrote:
| 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/
| TJTorola wrote:
| 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.
| nh2 wrote:
| Still waiting for Delta + Difftastic integration:
|
| https://github.com/dandavison/delta/issues/535
| nchmy wrote:
| Came to say this as well. Started with delta, then found
| difftastic.
|
| Even better is using it via jjui, a fantastic TUI for jj vcs
| TacticalCoder wrote:
| > https://difftastic.wilfred.me.uk/
|
| ah, it's using tree-sitter to not bother reporting changes that
| have no effect.
|
| That's very nice!
|
| Now, of course, the biggest issue is that our DVCes still are
| from the paleolitic era and store source code as non-structured
| text files instead of trees, so we need to the proper thing
| "outside" the DVCS (which is using tools like diffstatic /
| tree-sitter: tools that have seen the light).
|
| It's basically the old "tabs vs space" and "tabs = how many
| spaces?" and "bracket on the same line or not" discussions all
| over again. I'm pretty sure I've got comment from 15 years ago
| saying that in a proper world this shouldn't even be a concern
| because this should purely be a client-side concern, on the
| dev's machine. And that the DVCS should have a specific
| representation, not opened for discussion (a code formatter for
| example, but ideally just the source code already as a tree).
| And then no more bitchin' about tabs vs space, about how many
| spaces is a tab worth, on which line brackets should go, etc.
|
| Don't get me wrong: it's great that people are doing the right
| thing. But it's still a kludge that's needed because the
| underlying tool were made by us and for us cavemen and really
| could have been oh so much better.
| baumy wrote:
| 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
| MeetingsBrowser wrote:
| 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.
| ab71e5 wrote:
| 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
| MeetingsBrowser wrote:
| 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.
| henrebotha wrote:
| 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".
| MeetingsBrowser wrote:
| 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"
| henrebotha wrote:
| I mean yeah, there are tools to automate it. I think you
| may have a point if both of the following hold true:
|
| 1. You very frequently have to install your setup from
| scratch.
|
| 2. Preconfiguring something that aids in installing from
| scratch is not viable or sensible. (Perhaps you work in
| an environment where you're not allowed access to your
| personal dotfiles repo, for example.)
|
| But I think most people will fail at least one of these
| checks.
| WhyNotHugo wrote:
| I find that (neo)vim enable code navigation to be much
| faster than any GUI as well, once past the learning
| curve. If you're going to work with code long term (eg:
| years), the learning curve pays off quickly.
| rileymat2 wrote:
| > 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.
| MeetingsBrowser wrote:
| 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
| rileymat2 wrote:
| Yes, for things like Node, I do use tools like the chrome
| dev tools for debugging and such.
|
| But find a terminal first approach leads me to other
| tools like curl and jq usage as I go. I see coworkers
| using a ton of time trying to repetitively execute the
| code to see those spots in really inefficient ways. And
| end up completely lost when they could be using tools
| like git bisect.
|
| Or another good example devops type support is if one web
| server out of many seems to be misbehaving, I can use aws
| command line to get internal ips behind the lb to curl to
| grep and find it in minutes after others have tried for
| hours. It makes it second nature if your mind goes there
| first.
| packetlost wrote:
| I work 99% in a terminal and fire up a JetBrains IDE when
| I need to do deep debugging. It's so rare for me though
| that it's worth more for me to get good at the terminal
| stuff. I'm sure this depends heavily on the type of work
| being done, game dev for example really needs a good
| debugger. That being said, gdb and others have perfectly
| fine text mode interfaces, albeit with a steeper learning
| curve.
|
| As always, the "best" tool is the one your most familiar
| with that gets the job done. Text vs GUI doesn't really
| matter at the middle of the bell curve.
| backscratches wrote:
| Lol terminal is better for everything except maybe the one
| case you mentioned: first time use feature discovery, and
| that's debatable
| rileymat2 wrote:
| 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.
| MeetingsBrowser wrote:
| 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.
| baumy wrote:
| 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.
| MeetingsBrowser wrote:
| > 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
| hrmtst93837 wrote:
| Composability sounds great until you need to onboard three
| new devs who would rather gouge their eyes out than
| decipher an 80-line shell script that breaks on macOS
| because one env var or BSD tool behaves differently. That
| cost is not theory.
|
| Terminal skill ceiling exists, but a lot of custom flows
| are just local maxima that look elegant to the person who
| wrote them and miserable to everyone else who has to debug
| or extend them. GUIs give up some raw power, yet for diff
| review, history browsing, and getting a team moving without
| turning every workflow into a tiny priesthood, they are
| often the better tool.
| nickjj wrote:
| > watching people discover all these tools now that claude code
| is sending them into the terminal.
|
| Hi, I'm the author of the post.
|
| I don't like replying to comments like this but I think it's
| important because of how "invasive" LLMs have become and how
| they might jade your opinion (not you specifically, but
| everyone) on any type of output such as blog posts, videos,
| code, etc..
|
| I wrote about this because I've done contract work for lots of
| companies, spoken with lots of developers and every time they
| see the output of Delta they are like "how did you make your
| git diffs look so cool?", so I thought it was worth sharing
| because there's lots of folks out there who might not know
| about it.
|
| By the way, this concept of having a terminal based workflow is
| something I've openly been using, sharing and writing about for
| around a decade. There's 500+ posts and videos on my site
| covering a ton of different topics.
|
| You're more than welcome to explore any of the 70+ open source
| projects I maintain https://github.com/nickjj?tab=repositories,
| with git histories going back well before LLMs existed.
| Thousands upon thousands of human written lines of shell
| scripts, Python scripts, Docker set ups, etc.. Every readme
| file was written by hand and 99.999% of current day code is by
| hand too. I've been playing with AI to learn new languages like
| Lua to solve specific problems but I end up rewriting most of
| that code afterwards. You can view comments I've made on HN in
| the past in how I feel about LLM code haha.
| godelski wrote:
| I'm a long time vim user and terminally terminal as well. I
| also feel very mixed
|
| On one hand I'm really glad more people are coming over.
| There's been an explosion in TUIs and it's helping that people
| understand how important UX and visual design is.
|
| On the order hand I'm annoyed as things move from unix
| philosophy and it feels like people are just trying to make
| terminals GUIs. The beauty of the CLI is its power. I'll give
| up the UI because it is so powerful. The learning curve is
| steeper but it's not that bad once you get used to it. And
| since so many people go through the same experience there's a
| shared language across many different tools.
|
| Maybe an obvious example of that is how people conflate "vim
| mode" with using hjkl for movement. Even `set -o vi` in bash is
| more rich of an experience than what many people think "vim
| mode" _should_ mean, at least to a vim user. But lots of that
| shared unix language is getting lost and I 'm not a fan of
| those tools
| diath wrote:
| 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
| jeninho wrote:
| Been using delta for a while now, the side by side mode alone was
| worth the switch. Pair it with fzf and you can browse commits
| interactively which is a lifesaver on repos with messy history.
| rs545837 wrote:
| 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.
| esafak wrote:
| It tells you the function changed but not how; you still need
| line-level diffs.
| rs545837 wrote:
| Right, sem gives you both. sem diff --verbose shows the full
| before/after body of each changed entity. The entity-level
| view tells you what changed and what's affected. The line-
| level detail is still there when you need it.
| dominotw wrote:
| can diffs be piped through an llm to give you something higher
| level but still tie it back to to changes
| rs545837 wrote:
| You can, but it's slow, expensive, and hallucinates. An LLM
| looking at a raw diff might miss a renamed function or invent
| a dependency that doesn't exist. sem does it structurally:
| parses both sides with tree-sitter, computes structural
| hashes, walks the real dependency graph. If you want to layer
| an LLM on top for summarization, you're feeding it 10
| entities instead of 500 lines of unified diff.
| good-idea wrote:
| Related and a step beyond just viewing diffs - has anyone found a
| good TUI solution for a local equivalent of doing GitHub PR
| reviews?
|
| I love the simplicity of using existing tools in this post. It
| would be nice to have something similar that would allow for
| adding online comment threads on a diff, and output it to a
| simple markdown file. Of course, I'm thinking about a local agent
| workflow here.
| whinvik wrote:
| Haven't used it but have seen some online recommendations for
| gh-dash. https://github.com/dlvhdr/gh-dash
___________________________________________________________________
(page generated 2026-03-28 23:00 UTC)