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/
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
TJTorola 1 days ago [-]
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.
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.
skydhash 4 hours ago [-]
You forgot that while expression can be trees, statements are an ordered set. And most statements fits inside one line. So a diff that relies on lines gives enough information.
Also git can be made to ignore whitespace changes (a source of noise) and can refine a hunk to highlight what has changed. That’s plenty enough for most people.
rs545837 1 days ago [-]
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 1 days ago [-]
It tells you the function changed but not how; you still need line-level diffs.
rs545837 1 days ago [-]
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 1 days ago [-]
can diffs be piped through an llm to give you something higher level but still tie it back to to changes
rs545837 1 days ago [-]
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 24 hours ago [-]
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.
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.
> 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 23 hours ago [-]
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
MeetingsBrowser 1 days ago [-]
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.
rileymat2 1 days ago [-]
> 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.
vova_hn2 5 hours ago [-]
> there is a much higher ceiling on your productivity with other tools and their composability
What exactly is the "ceiling" for GUI based IDEs?
skydhash 4 hours ago [-]
Composition. I don’t think there’s any GUI that can be used for the git email workflow.
Versatility. In most TUI editors, running an external commands is easy, including piping a part of the text and receiving its output. As this is a fundamental unix principle, there’s basically no barrier between what you’re editing and other data on your system. In GUI, everything is its own silo.
Presentation. Code is not linear, but most gui forces use to use one window to see your text files. And when they allow splitting it’s cumbersome to use. Vim and Emacs has a easier way to divide you screen so that the relevant information can be presented at once. And there’s terminal multiplexers for simpler editors.
MeetingsBrowser 1 days ago [-]
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 1 days ago [-]
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 1 days ago [-]
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.
ab71e5 1 days ago [-]
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 1 days ago [-]
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 1 days ago [-]
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 1 days ago [-]
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 1 days ago [-]
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 1 days ago [-]
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.
backscratches 1 days ago [-]
Lol terminal is better for everything except maybe the one case you mentioned: first time use feature discovery, and that's debatable
rileymat2 1 days ago [-]
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 1 days ago [-]
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.
backscratches 14 hours ago [-]
I am sure you would!
baumy 1 days ago [-]
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 1 days ago [-]
> 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 24 hours ago [-]
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.
000ooo000 19 hours ago [-]
>onboard three new devs who would rather gouge their eyes out than decipher an 80-line shell script
If you've just hired a dev who can't/won't read 80 lines of shell, you have bigger problems than GUI vs TUI.
diath 1 days ago [-]
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.
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.
1 days ago [-]
Rendered at 20:17:33 GMT+0000 (Coordinated Universal Time) with Vercel.
https://github.com/dandavison/delta/issues/535
Even better is using it via jjui, a fantastic TUI for jj vcs
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.
Also git can be made to ignore whitespace changes (a source of noise) and can refine a hunk to highlight what has changed. That’s plenty enough for most people.
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 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.
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
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.
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
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.
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.
What exactly is the "ceiling" for GUI based IDEs?
Versatility. In most TUI editors, running an external commands is easy, including piping a part of the text and receiving its output. As this is a fundamental unix principle, there’s basically no barrier between what you’re editing and other data on your system. In GUI, everything is its own silo.
Presentation. Code is not linear, but most gui forces use to use one window to see your text files. And when they allow splitting it’s cumbersome to use. Vim and Emacs has a easier way to divide you screen so that the relevant information can be presented at once. And there’s terminal multiplexers for simpler editors.
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
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.
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.
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.
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”
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.
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 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.
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
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.
If you've just hired a dev who can't/won't read 80 lines of shell, you have bigger problems than GUI vs TUI.
https://github.com/so-fancy/diff-so-fancy/issues/498