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!).
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.
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'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”.
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
reply