Yeah, one of my co-workers just plays video games while his bot works away. That’s not my way, but imo, that’s a much better trade than trying to spin between 5 different tasks and toiling harder than you ever did when you had to do it “manually.”
If they want fast and cheap they can have it, but don’t work yourself into a burnout trying to make the output totally slop free.
I can relate, but there are still oases of sanity out there. Very hard to find anywhere profit motive is worshiped over common sense, though.
This is the way. It’s how we got our CTO to stop sshing into pods to yolo his ideas.
I’m lucky enough to work somewhere that doesn’t dictate what tools I have to use. I don’t use it for code, because that’s just not fun for me. But I will use it once in a while when web search just totally fails me, but I know the answer is Out There (in the weights of scraped corpus).
I’m fighting back, I guess, mostly just by showing that it’s easy and enjoyable to do things without checking in with Sam Altman first. ;p
On my free time I don’t currently write code, non-technical hobbies and maintaining the homelab I conjured eat it up.
I should get more non-technical hobbies, especially physical ones… But I’ll be literally sat at my wfh desk typing for work, looking forward to after 17h when I can switch the kvm to writing code for pleasure lol. I do really like programming though. Somehow still not sick of it after all these years.
I am getting really sick of this format. Everything feels like an ad.
The man page sheds a bit of light, but basically it the stuff on top of the core git functionality.
LOW-LEVEL COMMANDS (PLUMBING)
Although Git includes its own porcelain layer, its low-level commands are sufficient to support development of alternative
porcelains. Developers of such porcelains might start by reading about git-update-index(1) and git-read-tree(1).
The interface (input, output, set of options and the semantics) to these low-level commands are meant to be a lot more stable
than Porcelain level commands, because these commands are primarily for scripted use. The interface to Porcelain commands on the
other hand are subject to change in order to improve the end user experience.
Related, but not to be confused with the --porcelain option available for some git commands. Eg, from the man page for git status:
--porcelain[=<version>]
Give the output in an easy-to-parse format for scripts. This is similar to the short output, but will remain stable across
Git versions and regardless of user configuration. See below for details.
Like it says, if you’re doing any kind of scripting this will remove weird escape codes to make parsing the output easier.
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. 🖐
Personally, I think that’s a decent mental shortcut. I would call an API “good plumbing.” It kind of depends on your audience, for some the API is for the intended audience (developers), but from their perspective the API may be the plumbing while they provide a higher level tool (eg. a GUI) for their intended audience (regular people).