gitui VS delta

I was missing interactive rebase, as it is missing from libgit2

https://github.com/extrawurst/gitui/issues/32

I have this feeling with all rust apps using crossterm crate as their backend like GitUI for example

GitUI is a terminal UI for git written in Rust. We aim to simplify common git tasks in a fast, keyboard-only and cross platform way without leaving your beloved CLI.

The terminal applications I used are GitUi and LazyGit. Both are very good and have almost all what you need.

Give gitui a try. It’s a text|terminal user interface (tui) for git. I think that’s what you are looking for. Also, search GitHub for “git tui” and I’m sure you will find a bunch of other options.

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.

Thanks for the difftastic & zoxide tips.

However, I've been using this git pager/difftool: https://github.com/dandavison/delta

While it's not structural like difft, it does produce more readable output for me (at least when scrolling fast through git log -p /scanning quickly

View on GitHub