Neat, but I don't like how it highlight the entire like if I change just one character on that line.

Maybe there's a setting I'm missing, but I really like diff-so-fancy for legibility of changed lines.

For example if I've got like these changes:

***
a	2026-06-01 14:36:20.699016620 -0400
+++ b	2026-06-01 14:36:21.842027381 -0400
@@ -1,11 +1,10 @@
 foo
 bar
-baz
+bazz
 
 foo
-bar
 baz
 
-foo
+bar
 bar
 baz

difft shows me:

but diff-so-fancy shows me:

Imho it's easier to read the pertinent info in the latter, where you've got that attractive word diffing on changed lines.

I do like the conditional side-by-side and unified diffing, though. That's huge.

Updated OP with what I came up with. I wasn't able to make use of $GIT_REFLOG_ACTION -- for some reason it was blank in every case, but reading the first line of the existing commit message, if it exists, does the trick.

I do foresee a potential problem if you're doing like an interactive rebase for example, and you go to edit a commit message that starts like the default "Revert " style--that could be surprising... Maybe some other cases I haven't thought of too, but yeah, works for me. Thanks for pointing me in the right direction!

Thanks that is a great start, and even better gives me an excuse to faff about with scripting. I'll share what I come up with!

EDIT Oh interesting, in my debugging I found out that if you revert a revert now (git version 2.43.0) that the subject line reads "Reapply" instead of "Revert "Revert "..."""

Thanks for the 2am nerd snipe :D

You can do this via git hooks and a script. Specifically the prepare-commit-msg hook (.git/hooks/prepare-commit-msg). In your script, check for the GIT_REFLOG_ACTION env variable, and check if its value is "revert". If so, you are in a revert, and you can echo/printf out whatever you would like in your template.

Might be a bit more work to get to where you want, but hopefully that points you in the right direction?

And yeah I made an account just to ask this question. Hello! Nice looking server you've got here. 🖐

Gitflow is a legacy Git workflow that was originally a disruptive and novel strategy for managing Git branches. Gitflow has fallen in popularity in favor of trunk-based workflows, which are now considered best practices for modern continuous software development and DevOps practices. Gitflow also can be challenging to use with CI/CD

https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow

Feeling the pressure from Jujutsu.

It's free cache space 😏

This is a really cool post, thanks! I should make a page with links to weird things people do with DNS.

Relevant.

Why are there posts for how to open a tab in vim

The codebase audit link at the bottom is also a really good read!

I take full responsibility for this. I thought this was a parody. I didn't think anybody in their right mind would actually use this. In my defense their page contains of fake product reviews. Anyway... It's probably best to remove this, I'm perhaps mistaken. Thanks for the warning.

I acknowledge that the idea is amusing.

Let's be clear: anything that prevents devs from pushing to a branch will necessarily result in code being isolated on a dev's local machine. This is always a bad idea, and will always lead to lost work. I've seen it happen too many times.

Pre-commit hooks and pre-push hooks must be skipped, and eventually deleted. Every single time.

Rule 3. No spam of tools/companies/advertisements.

Yet here we are pushing a waitlist for a crap husky pre-push script? What?

The fuck is that site doing to my cursor and why?

A graph view is largely superfluous 99% of the time.

Fair enough. I don't tend to use it all that much. But it is there. I tend to find I don't really need to see the graph all that much. Maybe because I'm mostly working in small teams. It's just not that important to my understanding of what's going on.

One can use custom viewers via core.pager and interactive.diffFilter in git configuration, not to mention defining custom difftools directly.

I primarily use delta for this (sometimes packaged as git-delta), which itself is implemented in Rust too.

For example, save this as a script called delta-s somewhere in $PATH:

#!/bin/bash

delta -s \
  --minus-style='syntax #400000' \
  --plus-style='syntax #004000' \
  --minus-emph-style='normal #a00000' \
  --plus-emph-style='normal #00a000' \
  --line-buffer-size=48 \
  --max-line-distance=0.8 $@

Then, in ~/.gitconfig, add

[difftool "d-sbs"]
  cmd = diff -u $LOCAL $REMOTE | delta-s

And the you can just

git difftool --tool d-sbs HEAD~

You can further create an alias for that too of course.

The script is linked and is only 33 lines long. The instructions are also written down later in the Readme.

curl|bash? No way

Yes if you don't get a real GUI you'll end up using this poor-man's imitation a lot.

I just used whatever my company would provide, and since I changed company quite a bit, and SVC software with it, I never really learned anything beyond add, commit, push/pull (seriously) for the last 18 years. Then this winter they asked me to teach advanced git, so I went ahead and learnt all the fancy commands and I'm thoroughly enjoying the CLI with command completion.

I have some handy aliases so I use CLI most of the time. And on my gaming keyboard I have the side macro keys set to:

• git status
• git diff
• git add .
• git commit - m """ (with the cursor left into between quotes)
• git commit -am ""

For merge conflicts I'll use whatever the IDE provides.

The default difftool is vimdiff, which is not a GUI program. But no, the point of difftool is to iterate through files to diff and pass the different versions to an external program. There are many external CLI and TUI diffing programs. The point, though, is that the git CLI is still the driver of everything and you still have the full range of options available to git diff, rather than some GUI program being the driver, which are universally limited in what they can do.

Personally, I load regular git diff output into a vim buffer via :read. Unified diff is largely superior to side by side diffs, IMO, because most of the time, changes in one file are accompanied by changes in a number of other files, so it's useful to be able to quickly follow a thread of changed calls or whatnot. And with unified diff output, you can see and manipulate hunks directly.

What I'm saying is that performing a diff via command line isn't something that brings as much utility as using a GUI. You can do it, but a major part of this utility is the visual aspect, layout, navigation. CLI tools don't come close to what I want. Isn't difftool meant to be used in GUI form? Am I missing something here?