bat VS delta

I page man (and many other things) through bat[0] which improves my experience.

[0]: https://github.com/sharkdp/bat

my cat replacement (bat), shows the changed lines

bat (for enhanced preview in search)

Have you heard of the command-line tool bat, written in Rust? bat is a command-line tool similar to cat that displays file contents in the terminal, but with additional features like line numbering, syntax highlighting, and paging.

bat

Perhaps interesting (for some) to note that hyperfine is from the same author as at least a few other "ne{w,xt} generation" command line tools (that could maybe be seen as part of "rewrite it in Rust", but I don't want to paint the author with a brush they disagree with!!): fd (find alternative; https://github.com/sharkdp/fd), bat ("supercharged version of the cat command"; https://github.com/sharkdp/bat), and hexyl (hex viewer; https://github.com/sharkdp/hexyl). (And certainly others I've missed!)

Pointing this out because I myself appreciate comments that do this.

For myself, `fd` is the one most incorporated into my own "toolbox" -- used it this morning prior to seeing this thread on hyperfine! So, thanks for all that, sharkdp if you're reading!

Ok, end OT-ness.

i like bat, but they also link over to delta :D

https://github.com/sharkdp/bat?tab=readme-ov-file#git-diff

You can also do that with delta (https://github.com/dandavison/delta), with additional options that you can put on your .gitconfig

https://github.com/dandavison/delta/issues/364 https://github.com/dandavison/delta https://dandavison.github.io/delta/full—help-output.html

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.

As someone who also uses Git exclusively from the command line, without any TUI wrappers, I agree with a lot of this. The parts about commits being revertable, bisectable and in general _atomic_ are very important, and IME the only correct way of using version control.

One exception: conventional commits. I find them very useful even on solo projects, since a) they make it easy to spot the type of change at a glance, and b) they force me to keep commits atomic. That is, if I'm ever compelled to make a commit that is both a `fix` and a `refactor`, usually out of laziness :), sticking to a conventional commit message is a quick way to determine what needs to be split into a different commit. These conventions really shine when used in a team, as they improve communication and keep the history tidy (along with all other benefits of atomic commits), but so far I haven't had the luck to work on teams that agree to adopt this workflow. Using these commits to generate changelogs would be wrong, as changelogs should almost never be autogenerated (though these days maybe AI does an acceptable job at it), but they're still useful to keep track of the number of fixes, features, etc. that were produced in a release.

And a tip: in addition to plain shell and Git aliases, I've found scmpuff[1] and delta[2] to be invaluable in a Git CLI workflow.

[1]: https://mroth.github.io/scmpuff/

[2]: https://github.com/dandavison/delta

https://github.com/dandavison/delta is nice for a prettier presentation of the same information as `git diff`.

This may or may not qualify, since I think GNU diff supports it with an option, as does Git diff, but "Color-words" diff can be nice, where changes in the middle of the line are highlighted and whitespace is ignored.

Somebody already recommended https://github.com/Wilfred/difftastic, which I second. It uses treesitter and is very interesting. Surprisingly, in practice difftastic is not always noticeably better than color words diff (don't expect miracles), but occasionally it is much better.

`git blame` lets you identify the commit that changed the line you’re looking for, but doesn’t make it easy to then view further details. The author might prefer GitHub’s blame view because it has these features:

• each hunk has a link to the commit that changed it, as opposed to needing to copy a line’s SHA and then run a new `git show …` command

• each hunk has a link to view the `blame` as of that older commit, as opposed to needing to copy a line’s SHA and then run a new `git blame … path/to/file` command

• the code is syntax highlighted by default, without you needing to configure your local Git install to use https://github.com/dandavison/delta

These features lead to a better experience than `git blame`. Various IDEs, editor plugins, TUIs, and GUIs provide similar features.