[laughinghan]

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.

[klodolph]

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.

[chousuke]

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.