You can trust a git commit to never change.
> You will make mistakes, but Git encourages you to hide them in the stash, in private branches, in changed checkin comments (git commit --amend), and in history rewrites. In its default working mode,
That is not the purpose of any of those things, nor is the purpose to "hide" anything. The purpose is to make the history more understandable and give you the ability to compartmentalize changes. While you shouldn't be working on multiple things, I and most other people I met, end up doing so. Being able to split those into commits all about the same thing is handy.
> 2. You are not your code. Private branches are a symptom of the sort of perfectionism that violates this commandment.
It's not protectionist or perfectionist to keep non-working code out of the main branch. If I'm rewriting something, why should everyone else have a non-working version of it for the duration of the rewrite?
> Don't rewrite other people's code without consultation
You can't work on a project with other people without using their code, and often you _can't_ consult them. Sure, don't autoformat, &c. I don't see how private branches encourage of facilitate this. People will do what people will do. I've seen people do this in subversion, so I don't see your point.
> You don't want to find out a week later when you and your colleague both try to check in week-old private branches, and find that you'll need another day or two of work to fix up the differences.
I'm not sure what you're talking about as I've never had such a terrible merge in git (though I have in subversion).
> Don't be "the guy in the room." But Git wants you to be that guy. Before you can check a change in with Fossil, it first checks if there are any changes in the repo you cloned from, and makes you either say "fossil up" to pull them into your local repo, or check in on a branch. This encourages you to either test your changes against the tip of trunk before checkin in, or at least publish your changes as a branch so people can see you go haring off in a different direction, and maybe correct your trajectory.
You can't push a non fast-forward by default. (You can force, but that can be disabled and is heavily discouraged.) I'm not seeing why your model is inherently any better than make sure tests pass after a merge. Again, it's up to the dev, not the scm.
> Not all merge conflicts can be detected by the VCS's merge algorithm. Just because your changes merge cleanly into the central code repo doesn't mean you haven't broken the build, or the tests, or... Fossil encourages you to test your change against the tip of the branch you're working on before checking in.
Fossil does not, your build and project environments do.
> Git amounts to a social regression with respect to Egoless Programming.
I have no idea what you even mean. Git is about giving you the tools to make code changes that make sense, without the need to obtain someone's blessing over your code. All other decisions are yours and yours alone. I can not test in SVN, Fossil, CVS, Perforce, &c. I can edit other people's code as well. Nothing is stopping me but convention and what I decide to do.