I was looking for a good TUI tool for diffs recently, but I'm not sure yet if what I want exists already (and I don't think this tool does it (yet?)). I've been moving my workflow out of VSCode as I'm using TUI-driven coding agents more often lately but one thing I miss from my VSCode/GitHub workflow is the ability to provide a comment on lines or ranges in a diff to provide targeted feedback to the agent. Most diff tools seem to be (rightfully) focused on cleanly visualizing changes and not necessarily iterating on the change.
I admit I haven't looked super hard yet, I settled on configuring git to use delta [0] for now and I'm happy with it, but I'm curious if anyone has a workflow for reviewing/iterating on diffs in the terminal that they'd be willing to share. Also open to being told that I'm lightyears behind and that there's a better mental model for this.
*Edit: I see you meant providing feedback to an agent, not a PR. Well that's what I get for reading too fast.
llbbdd 1 days ago [-]
No problem, I appreciate another reason to look at Neovim; I do sometimes have a need to interact with GH's actual PR flow and once I've moved the rest of my workflow out of VSCode, Neovim looks like the best option for the last mile of actually writing and editing code. I just have to commit the time to set it up with everything I probably take for granted in VSCode's editor.
Imustaskforhelp 14 hours ago [-]
Micro editor is a great choice as well imo but I don't think that micro has the thriving plugin ecosystem as compared to neovim but it is possible to make plugins for micro editor as well
Checkout https://github.com/agavra/tuicr - it's built exactly for this purpose (reviewing code in your terminal and then adding comments and exporting it to an agent to fix).
eddyg 41 minutes ago [-]
This is really nice! I like the ability to add comments to "send it back" for another pass.
thamer 1 days ago [-]
I had tried `delta` a few years ago but eventually went with `diff-so-fancy`[1]
The two are kind of similar if I remember correctly, and both offer a lot of config options to change the style and more. I mostly use it for diffs involving long lines since it highlights changes within a line, which makes it easier to spot such edits.
I have an alias set in `~/.gitconfig` to pipe the output of `git diff` (with options) to `diff-so-fancy` with `git diffs`:
You can do this with diff-highlight, which comes packaged with git. No extra packages needed.
flamestro 1 days ago [-]
I was also searching for some time, but most of them did not have enough context for my workflow tbh. So thats why I decided to make deff. Another good one I liked is vimdiff
mckn1ght 1 days ago [-]
I use delta for quick diffs in a shell (along with the -U0 option on git-diff), but in my claude workflow, i have a 3 pane setup in tmux: :| where the right side is a claude session, the top left is emacs opened to magit, and the bottom left is a shell. Magit makes navigating around a diff pretty easy (as well as all the other git operations), and I can dive into anything and hand edit as well.
jfyne 1 days ago [-]
Not TUI based but I made something called meatcheck. The idea being that the LLM requests a review from the human, you can leave inline comments like a PR review.
Once you submit it outputs to stdout and the agent reads your comments and actions them.
Thank you! At a glance this is very close to what I had in mind, especially with the straightforward output format, I'll give this a try.
coryrc 1 days ago [-]
magit
ushironoko 15 hours ago [-]
[dead]
k_bx 1 days ago [-]
What I would love to see is "tig" replacement that is:
- even faster, especially if you have couple thousand files and just want to press "u" for some time and see them very quickly all get staged
- has this split-view diff opened for a file
Otherwise tig is one of my favorite tools to quickly commit stuff without too many key presses but with review abilities, i have its "tig status" aliased to "t"
This looks great as well! I personally prefer a bit more context. Thats why I added a bit more of it to deff. It also allows to mark files as reviewed by pressing `r` which is quite handy for my flow.
lf-non 1 days ago [-]
I also use icdiff, but it is good to have the file-awareness for git diff esp. the ability to quickly skip files that I know aren't important.
Amorymeltzer 1 days ago [-]
For that in particular, I use delta (<https://github.com/dandavison/delta>) with `side-by-side = true` enabled. I find I use both icdiff and delta side-by-side on a regular basis.
behnamoh 1 days ago [-]
Delta is so much faster than icdiff too.
vindin 1 hours ago [-]
Learn to read canonical diffs. It is the standard and will get you further than any new tool
rileymichael 1 days ago [-]
getting users to adopt a new tool with its own incantations is a tough sell. git supports specifying an external pager so folks can plug in alternatives (such as https://github.com/dandavison/delta) while still using the familiar git frontend
greaakdls 1 days ago [-]
[flagged]
ZoomZoomZoom 1 days ago [-]
Why shouldn't this be a simple wrapper to tie Delta to some kind of file browser or a thing like television[1]?
I’m not really sure what would pull me away for a vim based solution for viewing diffs (current using codediff.nvim). For a git client in general, I use a cli/tui based solution (lazygit or plain git depending on what I need to do) but when it comes to directly manipulating text why would I throw away all the muscle memory and custom configuration of my editor for a comparatively bare bones standalone tui?
jamiecode 1 days ago [-]
The specific gap side-by-side covers for me is reviewing changes on a remote box without firing up an IDE. Delta is great but keeps the unified format. icdiff does the split view but is pretty barebones. So there's definitely space here.
What nobody's mentioned yet is difftastic. Takes a completely different approach - parses syntax trees instead of lines, so indentation changes and bracket shuffles don't show up as noise. Worth a look if you're comparing options.
Main question I'd have: how does it hold up on large files? 5k+ line diffs are where most of these tools either choke or produce unreadable output. That'd be the test I'd run first.
flamestro 1 days ago [-]
So I tested this on huge files (checking cargo lock for instance) and it is super fast in the navigation of those. Until now I did not encounter any issue with bigger files (around 4k-6k changes but also only 4k-6k lines).
I wrote a script that takes two git commits and opens all changed files in vimdiff tabs side by side. I find lots of things too hard to see in github gui. It depends one [tpope's vim-fugitive].
I personally find vimdiff a bit harder to navigate for my usecase. The reason is that I am context unaware of the file often in larger projects and wanted something that allows me to check all lines in a touched file. However, I have to admit vimdiff comes quite close to what I need and is a great tool!
I ran in to a couple problems when trying that script (details below), but I'm really happy that you shared it, because I had not seen ':windo diffthis' before, and that method of scripting diffs. I'll definitely be customising it!
(I found that my mac machine doesn't support the '-printf' option, and also I was attempting to run 'git bvd main' on a branch but it seems it does a recursive directory diff, so I'll use 'git diff --name-only' as the input to the awk command).
Edit: worked nicely! I haven't used tabs much in vim so is a slightly new workflow but otherwise very handy
devnonymous 13 hours ago [-]
> For me a bigger issue was git calling vimdiff for each file,
If you configure vimdiff as the difftool in your git config, just doing a `git diff` would show you the diff for each file sequentially.
metalliqaz 1 days ago [-]
but is it blazingly fast?
syngrog66 1 days ago [-]
if its not in Rust or browser-based or a "cloud" service or the result of multi-GWH of LLM "training" or a VSCode plugin or ideally all of the prior then the HN kids wont be interested :-)
suralind 1 days ago [-]
What you want is difftastic. No need to thank me.
xmorse 13 hours ago [-]
Check out Critique too if you are looking for a side by side diffs TUI
It uses opentui, the same framework uses by opencode.
It can also render diffs to images, pdf and html. Very useful for agents to share diffs in remote environments like Openclaw or Kimaki
The left side has lines 1365-1371 having the same code as lines 1374-1380 on the right side, yet they're not aligned with each other.
Most diff views would put padding between lines 1364-1365 on the left side so lines 1365-1371 are aligned with 1374-1380 on the right side.
raphinou 1 days ago [-]
Looks interesting. I'm currently using https://tuicr.dev/ , of which I like that the first screen it shows is the choice of commit range you want to review. Might be something to consider for deff?
I feel Kitty doesn't get enough love, it's all ghostty this, ghostty that, but Kitty has been my top performing terminal emulator for 10 years now.
agavra 23 hours ago [-]
I just built a version of this a month ago that also allows you to add review comments so you can export them back to an Agent to fix: https://github.com/agavra/tuicr
Great work on deff, would love to brainstorm here :)
teddyh 1 days ago [-]
emacs --eval='(ediff-files "file1" "file2")'
(The “|” key toggles side-by-side view.)
flamestro 1 days ago [-]
Yes, but emacs < vim
dingnuts 1 days ago [-]
[dead]
hatradiowigwam 1 days ago [-]
vimdiff is pretty fast, and is likely installed on your linux system without you realizing it.
flamestro 1 days ago [-]
Its a great tool, but misses some of the context I needed.
tty456 22 hours ago [-]
So, basically 'vim -d' in rust? cool
sourcegrift 20 hours ago [-]
Does it show moved codeblocks like reviewboard. Is that the second screenshot
ivanjermakov 23 hours ago [-]
8 terminal lines are taken by the tool's UI. Could have been 2.
It blows my mind that nowadays, some random tools on internet tells you to do "curl -fsSL https://.... | bash" to install some "binary" things and a lot of people will do it without hesitation.
It probably explains why there is so many data leaks recently but it is like we did a 20 years jump back in time in terms of security in just a few years.
flamestro 1 days ago [-]
I get the hesitation :D But the code is open and the install.sh is as minimal as it gets tbh. Still, as said, I get the hesitation. What a time to be alive.
It does not install binaries, it builds the binary by checking out the project basically. You can also do the process manually and use the tool.
warkdarrior 1 days ago [-]
> But the code is open and the install.sh is as minimal as it gets tbh.
I bet 99.9999% of users do not review the code nor the install script.
pwdisswordfishy 1 days ago [-]
One day folks who live inside commandlines and TUIs all day will realize that there's nothing particular about webapps or the sandboxes that they execute in that requires we build exclusively graphical runtimes around them, instead of taking advantage of the same security and distribution model for programs accessible and usable from within terminal emulator.
jaden 1 days ago [-]
Is it that different from downloading and running a binary?
greatgib 22 hours ago [-]
No, but who said that downloading and running a random binary found on internet is a good idea?
As I said, it's like being back 20 years back in the past.
duskdozer 11 hours ago [-]
How else are you going to get your openclaw to run blazingly fast??
But seriously, I think there's a bit of overzealousness/misalignment in security lately with a disregard for usability and privacy, making people less tolerant of dealing with inconveniences.
holoduke 1 days ago [-]
Cowboys rule the internet.
zem 1 days ago [-]
will this play well with jj?
insane_dreamer 1 days ago [-]
we need something like this in lazygit -- which is excellent all around but lacking in visual diffing/merging.
What is most useful though is a 3-panel setup, like JetBrains -- still the best git client I have worked with.
lolive 12 hours ago [-]
unfortunately for terminal lovers, the best .gitconfig snippet is still this:
What would the third panel contain in this case? Do you mean the setup that IntelliJ has in merge conflicts?
insane_dreamer 19 hours ago [-]
yes, it shows the final merge (what was accepted from the left and right panels); very handy
dec0dedab0de 1 days ago [-]
looks pretty good at a glance, though I would like to see three views for handling conflicts. Target on the left, source on the right, and the combined result in the middle.
...I really just like the way the Jetbrains IDEs do it, and I wish there were a TUI version that I could launch automatically from the git cli.
riteshyadav02 16 hours ago [-]
[dead]
Rendered at 23:06:40 GMT+0000 (Coordinated Universal Time) with Vercel.
I admit I haven't looked super hard yet, I settled on configuring git to use delta [0] for now and I'm happy with it, but I'm curious if anyone has a workflow for reviewing/iterating on diffs in the terminal that they'd be willing to share. Also open to being told that I'm lightyears behind and that there's a better mental model for this.
[0] https://github.com/dandavison/delta/
This in conjunction with gh-dash [1] to launch a review can get you a pretty nice TUI review workflow.
[0] https://github.com/pwntester/octo.nvim
[1] https://github.com/dlvhdr/gh-dash
*Edit: I see you meant providing feedback to an agent, not a PR. Well that's what I get for reading too fast.
https://github.com/micro-editor/plugin-channel
Link to Micro editor: https://micro-editor.github.io/
The two are kind of similar if I remember correctly, and both offer a lot of config options to change the style and more. I mostly use it for diffs involving long lines since it highlights changes within a line, which makes it easier to spot such edits.
I have an alias set in `~/.gitconfig` to pipe the output of `git diff` (with options) to `diff-so-fancy` with `git diffs`:
[1] https://github.com/so-fancy/diff-so-fancyOnce you submit it outputs to stdout and the agent reads your comments and actions them.
https://github.com/jfyne/meatcheck
- even faster, especially if you have couple thousand files and just want to press "u" for some time and see them very quickly all get staged
- has this split-view diff opened for a file
Otherwise tig is one of my favorite tools to quickly commit stuff without too many key presses but with review abilities, i have its "tig status" aliased to "t"
[1]: https://alexpasmantier.github.io/television/
What nobody's mentioned yet is difftastic. Takes a completely different approach - parses syntax trees instead of lines, so indentation changes and bracket shuffles don't show up as noise. Worth a look if you're comparing options.
Main question I'd have: how does it hold up on large files? 5k+ line diffs are where most of these tools either choke or produce unreadable output. That'd be the test I'd run first.
[tpope's vim-fugitive]: https://github.com/tpope/vim-fugitive
I'll paste it next time I'm on that machine.
vim folds are fully programmable. For me a bigger issue was git calling vimdiff for each file, which I fixed with my own difftool: https://gist.github.com/PhilipRoman/60066716b5fa09fcabfa6c95...
(I found that my mac machine doesn't support the '-printf' option, and also I was attempting to run 'git bvd main' on a branch but it seems it does a recursive directory diff, so I'll use 'git diff --name-only' as the input to the awk command).
Edit: worked nicely! I haven't used tabs much in vim so is a slightly new workflow but otherwise very handy
If you configure vimdiff as the difftool in your git config, just doing a `git diff` would show you the diff for each file sequentially.
It uses opentui, the same framework uses by opencode.
It can also render diffs to images, pdf and html. Very useful for agents to share diffs in remote environments like Openclaw or Kimaki
https://github.com/remorses/critique
And a link to an asciicinema would help a lot too.
---
Also, I'm not sure how useful the side-by-side view is.
The second example (https://github.com/flamestro/deff/blob/main/docs/example_02....) is confusing.
The left side has lines 1365-1371 having the same code as lines 1374-1380 on the right side, yet they're not aligned with each other.
Most diff views would put padding between lines 1364-1365 on the left side so lines 1365-1371 are aligned with 1374-1380 on the right side.
I use it with
I feel Kitty doesn't get enough love, it's all ghostty this, ghostty that, but Kitty has been my top performing terminal emulator for 10 years now.
Great work on deff, would love to brainstorm here :)
It probably explains why there is so many data leaks recently but it is like we did a 20 years jump back in time in terms of security in just a few years.
It does not install binaries, it builds the binary by checking out the project basically. You can also do the process manually and use the tool.
I bet 99.9999% of users do not review the code nor the install script.
As I said, it's like being back 20 years back in the past.
But seriously, I think there's a bit of overzealousness/misalignment in security lately with a disregard for usability and privacy, making people less tolerant of dealing with inconveniences.
What is most useful though is a 3-panel setup, like JetBrains -- still the best git client I have worked with.
...I really just like the way the Jetbrains IDEs do it, and I wish there were a TUI version that I could launch automatically from the git cli.