There's a huge divide between abusing rebase in horrible ways to modify published history, and using it to clean up a patch series you've been working on.

Oops, I made a mistake two commits ago, I'd really like to get some dumb print statements I added out before I send this off to get merged is perfectly valid, I just did it yesterday. A quick `git commit --fixup` followed by `git rebase -i --autosquash HEAD^3` and I had some dumb debugging code I left in stripped out.

Then, there's other perfectly valid uses of rebase, like a simple `git rebase main` in an active development branch to reparent my commits on the current HEAD instead of having my log messed up with a dozen merge commits as I try to keep the branch both current and ready to merge.

So, yes, I do think editing history is a grand idea that should be used regularly. It lets me make all the stupid "trying this" and "stupid bug" commits I want, without polluting the global history.

Or, are you telling me you've also never ended up working on two separate tasks in a branch, thinking they would be hard to separate into isolated changes, and they ended up being more discrete than you expected so you could submit them as two separate changes with a little help from `git cherry-pick` and `git rebase` too?

Editing history isn't evil. Editing history such that pulls from your repository break? That's a different story entirely.

When using systems without history editing I simply make an order of magnitude fewer commits. With git I basically commit every few minutes and then edit later, and with not-git I simply don't commit until it's "ready". Either way all of those intermediate states aren't getting published or saved forever.

you might want to check on what you "know" then....