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 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.
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.
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.
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.
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.
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
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.
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.
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/
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.
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.
It tells you the function changed but not how; you still need line-level diffs.
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.
can diffs be piped through an llm to give you something higher level but still tie it back to to changes
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.
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
> 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.
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.
3 replies →
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
5 replies →
Lol terminal is better for everything except maybe the one case you mentioned: first time use feature discovery, and that's debatable
2 replies →
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.
1 reply →
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
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.