Here's, I think, the big philosphic difference: Some people only want good code in the repo. Some people want every change in the repo. I'm in the second cam

Here's, I think, the big philosphic difference: Some people only want good code in the repo. Some people want every change in the repo. I'm in the second camp. I'll gladly commit broken code and then fix it later. I don't push broken code, of course, but sometimes it's useful to have a snapshot of the broken code before you start fixing it. For example, let's say I'm accepting a patch from someone or I found a useful snipit of code on the internet. I integrate the code and it breaks a unit test in some non-obvious way. I like to commit the code as it was from the original source before I start trying to fix it. That way I can quickly revert if my fix attempt is way off base. Further, I have in my history who / where the code came from and how it was fixed (in a later commit, complete with an easy to get diff). I'm not saying Eric's best practice is wrong. Some people prefer to only commit good code, some prefer to commit early and often. I don't think either practice is inherently better than the other. Edit: I realize I didn't really respond to the immutability issue... I don't really have an opinion on that.