That's by design; Git history is intended to be immutable when working with others.
But, if you haven't pushed something up to a remote, the right command to make more changes is to use `git commit --amend`.
But, if you haven't pushed something up to a remote, the right command to make more changes is to use `git commit --amend`.
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.
"History is immutable" is generally accepted as describing the contents of commits, not their id's or relative ordering.
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.
Which BTW I learned it exists when magit switched "p -f u" to use it instead of plain --force.
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.