The git history command deserves more attention

this is super interesting, but i do think git is going to have to invent something shaped like a change ID to really make this nice to use: the commit hashes changing all the time and being very long is rather a drag.

and running scary rebase -i commands that can leave your tree in a half-broken state if you so much as sneeze.

I've literally never done this. There's always git rebase --abort (or git checkout HEAD@{n}).

I’ve had a horribly complex alias in my gitconfig called fixr (fix + rebase) that I can now replace by git history fix. I’m happy git is learning new tricks. I have switched to jj, but most of my colleagues are using git.

Judging by how many people are using jj, I do think there’s still some key mental shift which I’m not yet making. And to be clear, git history doesn’t close the full gap: jj still gives you an operation log with easy undo, models your working copy as a commit, and can carry conflicts through a rebase, none of which this is trying to do.

Well, that almost covered it. Add persistent change IDs, and “carrying conflicts through a rebase” doesn’t really convey the full impact of first-class conflicts. There’s also the ergonomic benefit of a CLI that isn’t cluttered by decades of accumulated patches.

I think you won’t “get it” just by comparing the list of features and arguing about whether they’re equivalent; you have to experience the workflow, and how freeing it is to eliminate all the git cruft and distraction that turns out to be unnecessary.

Interesting thanks