5 ms·

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

175 points by nickjj 7mo ago

linsomniac 7mo ago
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/ https://difftastic.wilfred.me.uk/
- TJTorola 7mo 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.
- nh2 7mo ago
  Still waiting for Delta + Difftastic integration: https://github.com/dandavison/delta/issues/535 https://github.com/dandavison/delta/issues/535
  - kennykartman 6mo ago
    Be careful with difftastic, because it has at least one severe bug involving python that has been present for a long time: https://github.com/Wilfred/difftastic/issues/587 https://github.com/Wilfred/difftastic/issues/587
    - nh2 6mo ago
      Thanks for pointing that out!
- nchmy 7mo ago
  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 7mo ago
  > https://difftastic.wilfred.me.uk/ 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.
  - skydhash 7mo 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.
baumy 7mo ago
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 https://x.com/dani_avila7/article/2023151176758268349
- MeetingsBrowser 7mo 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.
  - ab71e5 7mo 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 7mo 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.
deleted 7mo ago
[deleted]
diath 7mo 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. https://github.com/so-fancy/diff-so-fancy/issues/498 https://github.com/so-fancy/diff-so-fancy/issues/498
jeninho 7mo ago
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 7mo ago
We've been building an open source tool called sem (https://github.com/ataraxy-labs/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.
- dominotw 7mo ago
  can diffs be piped through an llm to give you something higher level but still tie it back to to changes
  - rs545837 7mo 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.
- esafak 7mo ago
  It tells you the function changed but not how; you still need line-level diffs.
  - rs545837 7mo 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.
good-idea 7mo 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.
- whinvik 7mo ago
  Haven't used it but have seen some online recommendations for gh-dash. https://github.com/dlvhdr/gh-dash https://github.com/dlvhdr/gh-dash
- jfyne 7mo ago
  I wrote myself https://github.com/jfyne/meatcheck https://github.com/jfyne/meatcheck to do this. We use it with Claude to review markdown files and do reviews of changes. Claude spawns the process, it pops open a browser tab. You review what is there and can leave line by line feedback. You click finish and your comments go to stdout for Claude to read. We ask Claude to group changes and order them by importance to make reviews easier for us.
  - deleted 7mo ago
    [deleted]
dex01 7mo ago
How about using the already provided git provided diff-highlight tool ? git config core.pager /usr/share/git/diff-highlight/diff-highlight

175 points by nickjj 7mo ago

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/ https://difftastic.wilfred.me.uk/

TJTorola 7mo 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.
nh2 7mo ago
Still waiting for Delta + Difftastic integration: https://github.com/dandavison/delta/issues/535 https://github.com/dandavison/delta/issues/535
- kennykartman 6mo ago
  Be careful with difftastic, because it has at least one severe bug involving python that has been present for a long time: https://github.com/Wilfred/difftastic/issues/587 https://github.com/Wilfred/difftastic/issues/587
  - nh2 6mo ago
    Thanks for pointing that out!
nchmy 7mo ago
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 7mo ago
> https://difftastic.wilfred.me.uk/ 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.
- skydhash 7mo 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.

baumy 7mo ago

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 https://x.com/dani_avila7/article/2023151176758268349

MeetingsBrowser 7mo 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.
- ab71e5 7mo 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 7mo 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.

deleted 7mo ago

[deleted]

diath 7mo 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. https://github.com/so-fancy/diff-so-fancy/issues/498 https://github.com/so-fancy/diff-so-fancy/issues/498

jeninho 7mo ago

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 7mo ago

We've been building an open source tool called sem (https://github.com/ataraxy-labs/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.

dominotw 7mo ago
can diffs be piped through an llm to give you something higher level but still tie it back to to changes
- rs545837 7mo 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.
esafak 7mo ago
It tells you the function changed but not how; you still need line-level diffs.
- rs545837 7mo 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.

good-idea 7mo 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.

whinvik 7mo ago
Haven't used it but have seen some online recommendations for gh-dash. https://github.com/dlvhdr/gh-dash https://github.com/dlvhdr/gh-dash
jfyne 7mo ago
I wrote myself https://github.com/jfyne/meatcheck https://github.com/jfyne/meatcheck to do this. We use it with Claude to review markdown files and do reviews of changes. Claude spawns the process, it pops open a browser tab. You review what is there and can leave line by line feedback. You click finish and your comments go to stdout for Claude to read. We ask Claude to group changes and order them by importance to make reviews easier for us.
- deleted 7mo ago
  [deleted]

dex01 7mo ago

How about using the already provided git provided diff-highlight tool ? git config core.pager /usr/share/git/diff-highlight/diff-highlight