When you want a commit, you tell git to commit and it will commit.

When you don't want to revoke or mutate a commit ("irrevocably and permanently immutable"), you don't tell git to revoke or mutate the commit and it won't revoke or mutate the commit.

When you fucked up history and you want to change it, there are some simple git commands to do this and some very, very tedious svnadmin commands to do this.

Some of us fuck up history and want to change it. Some of us don't. Git serves both of us well. Subversion only serves one of us well. A lot of the time we have to use the same version control system, because we want to collaborate.

Additionally, if I have admin access to the SVN repository and rewrite history, how would you ever find out unless I told you about it?

In that sense Git has stronger support for immutable commits, since rewriting published history will actually cause everyone downstream to stand up and notice.

The thing most people seem to miss is that you can't actually mutate a commit in git. You can only appear to do so by removing the old commit and replacing it, and all of its children if it has any, with new commits.

If someone depends on your "mutated" commit, they will notice that it's gone, and you can deal with the issue.

The most common use for rebasing and commit editing is to make commits actually sensible.

Huge end-of-the-day commit-all-my-work chunks do not benefit anyone. The index and rebasing allow you to create commits that make sense, regardless of the state of the working tree. In subversion, this is a painful, dangerous and error-prone operation that involves manually using diff and patch. Git frees the developer from having to worry about when to commit.

smsm42 already said it, and you say you're still missing something, so I'll try another try another way.

If I want to work on some code locally, I might want to experiment and break things, and in the process of doing so I want the ability to commit and have the safety net of version control. That said, a lot of those experiments might be garbage, and I don't want to send garbage to my co-workers when I make a pull request.

So instead, I splash about in my local repo and make tons of commits and screw around with my experiments until they're fully baked, and have tests, and comments and docs and so on. Then I can use rebase to clean up that mess and present them with something atomic and contained that makes clear what I really wanted to publish. The garbage can be tossed from the history or it can be kept around locally, but at least I'm not asking my colleague to trudge through my own thought and work-process.

Does that not sound like a worthwhile feature? If it doesn't that's pretty cool too, you don't have to use rebase at all. Feel free not to, Git works fine without it.

Git's commits are immutable (their identity is an hash signature of their content, they can't be changed), what you want are non-removable commits, ie forbidding the user from moving refs to a commit that isn't a descendant of the current commit.

In practice this is what happens when you share your commits with the world (through push or someone pulling from you). As long as some commits are only in one computer git lets you happily nuke them, but why should it be otherwise? No one can force you to publish your commits anyway, you can always make a new clone and rewrite history there...

Actually you can make something more or less like that by signing a tag, and, as you pointed out, releasing it. this makes it convenient to check that no previous commit as been removed, as git signs a hash of the tag which is a hash of all the hashs in the history

(the tag can still be deleted, but just to show the convenience added)

I don't want anything my computer ever does to be irrevocable. If you want to always commit one at a time and never change them, that's fine - you can just never rewrite your history. But for many people rewriting history is useful, because it's easier to see what the correct commit boundaries in your change are after you've done the whole thing. That git allows these people to do that can't possibly be a disadvantage to using git.

Right, so the greater point I was getting at is that committing is something under the programmer's control. It's not "sacred history", it's all created by programmers as part of their craft, saying you shouldn't rewrite history because you might need it is not much different from saying you should commit every keystroke—they both mean you are of the opinion that you need to know every transformation to the code that happened.