Thanks for sharing your experience. I’d love to put up a tiny tiny frontend to share my versioned work, but so far my best options seem to be cgit (configuration appears to be a bit of a bear), and legit by icyphox (spelling) (which is a bit unrefined, but at least it’s pretty easy to modify).

Lord help me if I end up trying to make own…

Disclosure: I love git. I learned it along with vi and the GNU coreutils, etc, at my first job, so the roots run deep. When I think of programming, I think of git.

That said, I can appreciate how it is unintuitive to people who don’t really grok it. It is an incredibly powerful tool, but you have to really learn it on its own terms. You’ll probably have to pick up a little graph theory, memorize a few kata to get yourself out of common problems (merge conflicts, interactive rebases, etc).

I’m not sure how anything could replace it without also feeling lack-luster to people who are already good at git. Maybe we just need to keep adding more tooling and visualisation over top of it and let the power users at least be able to work at those lower levels if they choose to.

I was going to say Git Butler looks like it might have been this, but taking a look at their page now and it seems like they’ve gone all-in on corporate sponsorships. :P

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 “…”””

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