I've been using a mix of delta and difftastic both are amazing. Difftastic especially for tree-sitter AST syntaxes, it is a bit slower, but AST aware diff is so nice.
I also use foot+fzy as a tiny sway dmenu replacement.. I started to make other kinds of custom tiny TUI popup menus using this strategy and it's great, since it all uses my terminal style and each is an extremely tiny 1 or 2 line script.
I've been using eza (and exa before it) for a long time, but only for the pretty and colored output. I didn't even know about the git support! I now added the --git flag to my alias and will try it out. Thank you!
Delta has been one of those set and forget things, it's been a while since I've seen 'bare' git grep/diff/blame output, I also use it all the time for normal diffs (outside of git repos), but TIL that it also works with ripgrep [0]
As someone else already mentioned there is also bat[1], which was also set and forget, I aliased cat to bat and have a seperate alias vcat for 'vanilla cat' /usr/bin/cat
Same here, to be honest I never gave much thought to seeking alternatives, but this one looks really nice, especially having the line numbers and similar layout to GitHub diffs
Different use case. This is just a diff pager, it's not supposed to help you solve complicated 3 way merges.
On a separate tangent - I haven't needed to do a gnarly merge in years it seems like. I feel like the dev community has collectively gotten better at git/SCM in general. Maybe I was super junior before but it's just not a problem I seem to face in daily software dev anymore.
Default git diff output is soooooooooo bad. This tool makes it closer to a good GUI tool. At which point why not just use one of the tools that is excellent and existed for decades?
I can't fathom git diff in the terminal providing me value... ever? It's such a crappy and limited tool. My brain never learned to parse the +/- lines. I want a side-by-side view.
Which the linked tool does side-by-side. But I don't really run a diff unless it's for something non-trivial. In which case terminal still kinda sucks.
I don't see popping into a GUI as a loss. It's fast and snappy. No loss.
There's a class of programmers that seemingly live almost their entire life in the terminal. I've never been part of that class. My career has always been spent in a an IDE like Visual Studio, VSCode, or these days 10x. And that's assuming I'm not in something like Unity or Unreal. The terminal is something I regularly alt-tab to. It's never somewhere I stay.
Running inside a terminal provides precisely zero value to me.
Perhaps the answer is “git-delta attempts to provide a GUI like experience. If you can use a GUI you should. But if for some reason you can’t consider this as a less good alternative”.
I was about to make the same recommendation! I tried delta and difftastic and both were too much for me, so I've been using diffr as my git diff program for the past few years. It's delightful, thanks for making it.
Very nice, I've been looking for something like this since completing a port of DiffMatchPatch. I'll going to give it a spin right away, thanks for sharing your hard work!
As a bit of feedback, you might wish to put a section showing how to make a git alias for diffr, to complement the section on how to install it as the default. I know how to do this already, because I use delta and dft depending on what I need to see, but it would be useful to others to have a copy-paste solution handy.
The thing that prevents me from using delta is lack of "system" theme detection. Can't set it up and forget and mismatching theme with shell makes it really difficult to read.
It will use whatever `bat` theme is set. Bat itself doesn't do system theme detection, but it's easy enough to do in a script - I have one that gets called when my system theme changes where I set themes for various programs. Looks like this for dark mode:
Hi, delta now automatically detects whether the terminal background is light or dark and selects a theme accordingly. (This is due to the nice work of contributor bash: https://github.com/bash/terminal-colorsaurus)
To automatically display the light or dark version of images depending on their gh theme (works html style too)
I'm also fond of
<p align="center">
....
</p>
Which I notice you do :), but did you know you could also do it to tables and center the caption?
<table align="center">
<tr>
<td>
<img width=800px src="https://user-images.githubusercontent.com/52205/87230973-412eb900-c381-11ea-8aec-cc200290bd1b.png" alt="image" />
<br>
<p align="center"><sub>delta with <code>side-by-side</code> and <code>line-numbers</code> activated</sub></p>
</td>
</tr>
</table>
This isn't really a critique or anything, it is that I appreciate that you took the time to make things look pretty and it seems like you'd be interested in this kind of stuff
Also to others, this even works in issues and elsewhere. I find this stuff really helpful when writing issues
Delta is great for what it does, but I consistently hit an issue where it truncates long lines. This post inspired me to check if the situation had changed... and it has! Now if you set `git config --global --replace-all delta.max-line-length 0`, it will no longer truncate lines. It's unclear to me why this is not the default. Discussion about the change is in https://github.com/dandavison/delta/pull/290.
If you read the comments, you’ll find https://github.com/dandavison/delta/pull/1746 which adds the option I mentioned, which limits the length of syntax highlighting, but still has a rather low limit on maximum (unhighlighted) line length :)
I find it easier to navigate that way since the diff of each file is in its own tab (yes I know... not how tabs are meant to be used)
For grep, vim's built in location list seems good enough. As for blame, I haven't used it since learning about git log -L. Vastly superior in my opinion.
Speaking of diffs, one thing that annoys me about Git's diff output is that is prints file paths like Unix diff traditionally does, starting with the two file names:
I often cmd-click in iTerm to open a file in an editor, but this doesn't work here because of the a/ and b/ prefixes. Any way to make Git format the file name better? I don't even need two lines here.
I saw this recently and thought "great!" and tried it out, thinking I would love it. But somehow I actually prefer the way git already does it, even if it seems inferior to me. Maybe I'd just have to get used to it?
What's a good way to convert the output of something like this into an html page?
We have non technical people looking at markdown PRs and commits in github and the diff viewer is terrible. It will highlight and entire paragraph because someone removed a trailing space. I use git-so-fancy locally which makes it much easier to see changes but I can't expect non-technical editors to move from their GitHub based workflow to a terminal based one
Why? How does syntax coloring help in this context? I don't use syntax coloring at all in my editor, I don't think it adds any information or clues that help me understand the code. I think colored diff output (beyond red for deleted and green for added) just adds distractions.
Delta can show in the terminal a diff that looks like the GitHub one. You can compare side by side what was changed. It also highlight with more strength what changed inside the line. I installed it once, and never came back to the standard diff output.
If Delta doesn't work like you expected and you want a standard diff output temporarily, no problem, you can run Git with
git -c core.pager=less
Note also that if you redirect the Git output, Git is smart enough to not call the pager (in this case, Delta)
This is a case of personal taste. My only complaint about Delta is its name. Delta is already a concept in Git, and every time that I need to search about it is a pain... I search directly by "dandavision delta"
That tells me what Delta does, but not why I might want syntax highlighting in the diff context. I want to quickly see the differences, not a kaleidoscope of colors.
I normally use vimdiff and lazygit to see diffs. No syntax coloring.
There was a good point made, that has stuck with me over the years. that our syntax highlighters are highlighting the wrong thing.
They should not be coloring the grammar, we are good at picking out grammar, they should be highlighting the symbols. each different variable and function name should be getting it's own color. that is, the goal is to make it quicker to distinguish different symbols, not that they are a symbol.
But this is much harder than stylizing the grammar so all our tooling sticks with the easy thing rather that the useful thing. Now, I am being a bit mean on grammar styling. It does help quite a bit but I would like to see a symbol matching engine in action to see if that really works.
Unfortunately I don't remember where I read the original post and am unable to attribute it correctly.
Totally agree, at first it looked alien to me but I've grown used to and prefer this way of highlighting. Personally I use color-identifiers-mode[0] for Emacs.
We are pretty good at picking out variable names too... Especially if the grammar itself is highlighted since we then know exactly where to look / where not to look.
I'm not convinced of the argument, but still a bit curious.
I sometimes highlight a variable to follow it and make sure I don't miss an instance of it, so that I totally get. But not sure we have enough colors and contrast to make sense to follow many variables without cluttering everything up. A compromise might be to manually color up to 3 or something variables.
... but the cases where that helps may be a sign that the code isn't very readable to begin with (helping with messy codebases is a proper usecase though!).
97 comments
[ 3.2 ms ] story [ 161 ms ] threadDelta looks clean, and is super fast
If you use the terminal at all, get them!
That would be one of the coolest news in weeks!
For difftastic, there is difftastic package in MELPA, see also https://github.com/pkryger/difftastic.el for instructions.
`env GIT_EXTERNAL_DIFF=difft git log -p --ext-diff`
Hope it helps :)
difft = -c diff.external=difft diff
I may add a similar alias for delta
The related? project "bat" also looks interesting.
- rg (ripgrep): A grep replacement
- sk (skim): A grep/fzf/fzy replacement
- fd: A find replacement that's .gitignore+.ignore aware.
- eza: A replacement for ls that's git aware
- broot: A TUI file finder to browse large directories
- yazi: A file manager (I haven't used this one too much)
sk+rg + gawk in action to find files matching some text,
I also use foot+fzy as a tiny sway dmenu replacement.. I started to make other kinds of custom tiny TUI popup menus using this strategy and it's great, since it all uses my terminal style and each is an extremely tiny 1 or 2 line script.
tbh I prefer to use less for previewing files anyway.
I've been using eza (and exa before it) for a long time, but only for the pretty and colored output. I didn't even know about the git support! I now added the --git flag to my alias and will try it out. Thank you!
curl … | prettier --parser html | bat
to get not-ugly HTML output from curl.
As someone else already mentioned there is also bat[1], which was also set and forget, I aliased cat to bat and have a seperate alias vcat for 'vanilla cat' /usr/bin/cat
[0] https://dandavison.github.io/delta/grep.html
[1] https://github.com/sharkdp/bat
(In bash at least. Not sure about newfangled shells!)
On a separate tangent - I haven't needed to do a gnarly merge in years it seems like. I feel like the dev community has collectively gotten better at git/SCM in general. Maybe I was super junior before but it's just not a problem I seem to face in daily software dev anymore.
Default git diff output is soooooooooo bad. This tool makes it closer to a good GUI tool. At which point why not just use one of the tools that is excellent and existed for decades?
Most of the time, diffs are small, and the overhead/break in workflow, of starting a separate GUI program just for them, can be big.
I can't fathom git diff in the terminal providing me value... ever? It's such a crappy and limited tool. My brain never learned to parse the +/- lines. I want a side-by-side view.
Which the linked tool does side-by-side. But I don't really run a diff unless it's for something non-trivial. In which case terminal still kinda sucks.
I don't see popping into a GUI as a loss. It's fast and snappy. No loss.
There's a class of programmers that seemingly live almost their entire life in the terminal. I've never been part of that class. My career has always been spent in a an IDE like Visual Studio, VSCode, or these days 10x. And that's assuming I'm not in something like Unity or Unreal. The terminal is something I regularly alt-tab to. It's never somewhere I stay.
Perhaps the answer is “git-delta attempts to provide a GUI like experience. If you can use a GUI you should. But if for some reason you can’t consider this as a less good alternative”.
Any user feedback on how it is (perf etc) ?
As a bit of feedback, you might wish to put a section showing how to make a git alias for diffr, to complement the section on how to install it as the default. I know how to do this already, because I use delta and dft depending on what I need to see, but it would be useful to others to have a copy-paste solution handy.
I'm also fond of
Which I notice you do :), but did you know you could also do it to tables and center the caption? This isn't really a critique or anything, it is that I appreciate that you took the time to make things look pretty and it seems like you'd be interested in this kind of stuffAlso to others, this even works in issues and elsewhere. I find this stuff really helpful when writing issues
> To automatically display the light or dark version of images depending on their gh theme
Ah, good call. That could be a nice improvement -- creating light and dark versions of the screenshots with switching as you describe.
https://github.com/sharkdp/bat?tab=readme-ov-file#git-diff
git config --global diff.colorWords true
git config --global diff.wordRegex '\w+|.'
It's literally in the PR you mention:
syntax-highlighting very long lines (e.g. minified .js) will be very slow if they are not truncated
I find it easier to navigate that way since the diff of each file is in its own tab (yes I know... not how tabs are meant to be used)
For grep, vim's built in location list seems good enough. As for blame, I haven't used it since learning about git log -L. Vastly superior in my opinion.
We have non technical people looking at markdown PRs and commits in github and the diff viewer is terrible. It will highlight and entire paragraph because someone removed a trailing space. I use git-so-fancy locally which makes it much easier to see changes but I can't expect non-technical editors to move from their GitHub based workflow to a terminal based one
If Delta doesn't work like you expected and you want a standard diff output temporarily, no problem, you can run Git with
git -c core.pager=less
Note also that if you redirect the Git output, Git is smart enough to not call the pager (in this case, Delta)
This is a case of personal taste. My only complaint about Delta is its name. Delta is already a concept in Git, and every time that I need to search about it is a pain... I search directly by "dandavision delta"
I normally use vimdiff and lazygit to see diffs. No syntax coloring.
They should not be coloring the grammar, we are good at picking out grammar, they should be highlighting the symbols. each different variable and function name should be getting it's own color. that is, the goal is to make it quicker to distinguish different symbols, not that they are a symbol.
But this is much harder than stylizing the grammar so all our tooling sticks with the easy thing rather that the useful thing. Now, I am being a bit mean on grammar styling. It does help quite a bit but I would like to see a symbol matching engine in action to see if that really works.
Unfortunately I don't remember where I read the original post and am unable to attribute it correctly.
update: while trying to look it up I found this https://www.wilfred.me.uk/blog/2014/09/27/the-definitive-gui...
https://difftastic.wilfred.me.uk/
https://github.com/Wilfred/difftastic
[0] https://github.com/ankurdave/color-identifiers-mode
I'm not convinced of the argument, but still a bit curious.
I sometimes highlight a variable to follow it and make sure I don't miss an instance of it, so that I totally get. But not sure we have enough colors and contrast to make sense to follow many variables without cluttering everything up. A compromise might be to manually color up to 3 or something variables.
... but the cases where that helps may be a sign that the code isn't very readable to begin with (helping with messy codebases is a proper usecase though!).