Perhaps git should have a "checked rebase" command that requires a `--force` flag if there's an upstream branch set.
*And even then it's kind of okay as long as no one else has made commits on top of the rebased commits.
For me, this is where the problem with got lies. I use so many of it's commands infrequently enough that I don't know where the weird disastrous edge cases are, where I should use.
I think git would greatly benefit from a topical man page; a list of common and uncommon situations that shows the recommended commands for solving them, and explains what those commands do. I know that hundreds of random "guides" exist, but are they outdated, are they cannon, do they have bugs? When your UI is esoteric, situational documentation is really important.
Which BTW I learned it exists when magit switched "p -f u" to use it instead of plain --force.
"History is immutable" is generally accepted as describing the contents of commits, not their id's or relative ordering.
That's another pet peeve (though maybe less git's fault): immutable, yes, but then rebase is pushed quite liberally. Arguably not by git itself, but by many online learning resources.
It's convenient, and mostly works, but then occasionally really stings you.
...yet undoing the last commit, arguably the least aggressive of history-rewriting commands, remains awkward.