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
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!).
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 :)
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'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.
Bash is funny with the -gt, -lt etc. operators and the [[ ]] builtin -- bash treats them as arithmetic operators like it does with math in $(( )), and so you provide them the variable name, not the value.
$ TEST=3
$ if [[ TEST -gt 2 ]]; then echo "honk"; fi
honk
$ TEST=1
$ if [[ TEST -gt 2 ]]; then echo "honk"; fi
$
That lets you do things like
$ if [[ TEST*3 -gt 6 ]]; ...
without having to nest even more double parentheses.
You're correct about having to export DELTA_FEATURES at least once. (I export it outside of the function, but no harm in doing so whenever it's set -- but it's not required to re-export it when you change the value.) Thanks for catching that!
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.
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
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:
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?
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.
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
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
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!
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.
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.
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”.
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
[0] https://dandavison.github.io/delta/grep.html
[1] https://github.com/sharkdp/bat
You can use \cat to prevent alias expansion.
Or 'command cat', which is a little less convenient but will also handle the case where "cat" is a function, not an alias.
(In bash at least. Not sure about newfangled shells!)
Neat! thanks for sharing. Few times I needed that but I had to go hunting down the full path.
I have ‘ccat’ aliases to the original cat binary
That's even better, thank you!
or you can do =cat on zsh
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.
update: while trying to look it up I found this https://www.wilfred.me.uk/blog/2014/09/27/the-definitive-gui...
This is what KDevelop called Semantic Highghting (as opposed to Syntax Highlighting). I think it was there earlier than this, but the earliest post I can find describing it is from 2009: https://zwabel.wordpress.com/2009/01/08/c-ide-evolution-from...
The author of that post wrote "difftastic", which is "a structural diff that understands syntax" using treesitter.
https://difftastic.wilfred.me.uk/
https://github.com/Wilfred/difftastic
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.
[0] https://github.com/ankurdave/color-identifiers-mode
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!).
Not as fancy, but if you want halfway reasonable word-level diffs with just standard issue git, this is often good enough:
How do I enable this by default (in .gitconfig)?
Try this
git config --global diff.colorWords true
git config --global diff.wordRegex '\w+|.'
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.
> It's unclear to me why this is not the default
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
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 :)
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.Perfect, thank you.
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.
Delta looks clean, and is super fast
Here's a handy delta trick for you, to turn the side-by-side feature on and off based on window size. bash here, other shells left as an exercise:
You are probably missing a $ before COLUMNS and export before setting DELTA_FEATURES
Bash is funny with the -gt, -lt etc. operators and the [[ ]] builtin -- bash treats them as arithmetic operators like it does with math in $(( )), and so you provide them the variable name, not the value.
That lets you do things like without having to nest even more double parentheses.You're correct about having to export DELTA_FEATURES at least once. (I export it outside of the function, but no harm in doing so whenever it's set -- but it's not required to re-export it when you change the value.) Thanks for catching that!
I use both delta and difftastic (difft), and cannot recommend them enough.
If you use the terminal at all, get them!
Difftastic and Delta work not only in bare terminals. Both are supported by Magit in Emacs, both are also supported by Lazygit.
What??? Do I have to set something in Magit for that to work?
That would be one of the coolest news in weeks!
https://github.com/jesseduffield/lazygit/blob/master/docs/Cu...
magit-delta https://github.com/dandavison/magit-delta
For delta, there's magit-delta in MELPA.
For difftastic, there is difftastic package in MELPA, see also https://github.com/pkryger/difftastic.el for instructions.
I second this question.
I've been using difftastic for a while. How do you use both together?
I have `delta` as my default and for difft, I use the following:
`env GIT_EXTERNAL_DIFF=difft git log -p --ext-diff`
Hope it helps :)
I have this set as an alias:
difft = -c diff.external=difft diff
I may add a similar alias for delta
I am also curious.
... and this one.
Also, checkout tig: https://jonas.github.io/tig/
I want to like this having used regular `git diff` tool with colours, but this is just too busy.
you might like diffr (https://github.com/mookid/diffr) (disclaimer: my project)
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.
had the same impression. never really found bare git diff to be a problem.
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.
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)
On a not-so-completely unrelated note, if you didn't know on GitHub READMEs you can do things like
To automatically display the light or dark version of images depending on their gh theme (works html style too)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
Thanks! https://github.com/dandavison/delta/pull/1893
> 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.
It’s beautiful, I love it
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:
The bat config change will make delta respect my "system" theme.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?
Same for me. I don't know, delta seems more like a chaos I can't make sense of than default git diffs
I use a modified version of vimdiff as my daily diff tool: https://gist.github.com/PhilipRoman/60066716b5fa09fcabfa6c95...
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.
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
https://dandavison.github.io/delta/tips-and-tricks/export-to...
Try webdiff (I’m the author) https://pypi.org/project/webdiff/
xfce4-terminal supports "Copy as HTML" for stuff like this.
I'm still on diff-so-fancy; Worth investigating this one?
I created diff-so-fancy and I migrated to Delta a few years back.
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
Delta has a diff-so-fancy mode, so could be a nice way to transition.
I use both.
Looks like the author has also written magit integration for it: https://github.com/dandavison/magit-delta
Any user feedback on how it is (perf etc) ?
i like bat, but they also link over to delta :D
https://github.com/sharkdp/bat?tab=readme-ov-file#git-diff
I really like delta. I use it every day.
This is pretty sweet. What's the recommended color scheme for default Ubuntu purple background terminals?
https://raw.githubusercontent.com/dandavison/delta/main/them...
i knew git could use arbitrary diff filter but never realised it was this simple to use. This looks very nice.
The related? project "bat" also looks interesting.
If you are getting to check out bat, you might want to check,
- 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,
> eza: A replacement for ls that's git aware
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!
I love broot, I use it for everything.
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.
can broot scroll the file preview on the right? ranger can do it, so far I feel ranger is better
It can but it scrolls the cursor instead of managing real mouse scroll events a la vim mouse=a so it's not ideal.
tbh I prefer to use less for previewing files anyway.
Ranger seems quite slow for the directories I tried to use it on. Use lf, may give broot a try.
speedy for me all these years
Love these, my only change is lsd over exa (pure personal preference)
bat is great. I end up doing
curl … | prettier --parser html | bat
to get not-ugly HTML output from curl.
I've been using Delta for a few years now and absolutely love it. Huge improvement to my command line diff viewing!
I love delta, I don’t always run it but I usually do. I recommend anyone give it a try.
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.
Been using delta for diffs for a while, highly recommend it!
I’ve been using Araxis Merge for almost 20 years. This seems… not as good?
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.
Sure, but I use Araxis Merge as my basic diff tool as well.
If you use a GUI to view the output of git diff... then yea this probably isn't for you :P
You say that like it’s a bad thing?
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?
Because some people, prefer to use their terminal as their universal IDE.
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 probably do git status; git diff; git commit; 20+ times a day sometimes. Leaving the terminal in the middle for the diff is unfathomable to me.
It's so fun how different people work.
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.
The price, is infinity times cheaper. Also terminal based means it can run on remote machines or local.
Does Araxis Merge work in the terminal on Linux?
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”.