On Git's lack of respect for immutability and the Best Practices for a DVCS

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.

Where git differs is not in its mutablity, but in how it allows you to move around the head of a branch in a more free fashion than most other DVCSs. (I don't mean "more free" as a value judgment here, just an observation that it is a superset of typical capabilities.)

It should be pointed out this only address about a half of the objections you can raise for this re-writing; it is not true that you lose things because of the re-writing, because you can get them back from the reflog. But it is of course still true that history rewriting in the sense that most people mean it is true.

Basically, from a technical point of view this is a non-issue, but from a human point of view it still can be.

Personally, I'm willing to concede this is a powertool and perhaps isn't for everyone, and by the definition given it's not a "best practice", but I don't think I'm willing to accept that definition in general. I'd prefer something more relative to the local user set, not go for a global definition. Perhaps some teams would do nothing but shoot themselves, but in my experience with my team and the local related teams, history re-writing is a net gain in terms of how it impacts how we work. And it's hard to convince me of a point my personal experience doesn't correspond to.

Anyway, the great news is that if you have a central repository, you can deny non-fast-forward commits. That then gives you the same "immutability" or "security" as Subversion or anything else.

The moral of the story is, if you don't want to do something, don't do it.

(As an aside, I think this article is a classic case of, "SEE MY PRODUCT IS STILL RELEVENT!!!11". Would he be saying this if he didn't have an inferior product to sell?)

And usually it's only available as an "admin" feature (at least in the commercial tools I've used). So it's not as if it's an everyday thing developers would use or have access to.

The difference with Git is that you're the admin of your local repository and can pretty much do what you will with it.

But there's a difference between your work repository located on your laptop, workstation, etc. and the "reference" shared repository that's used by your team+. So go and set all kind of hooks to prevent history rewrites (in the form on non-fast-forward pushes and the like) on it. What happens in that case is you can mess around all you like and clean up locally but once you've decided to push up and share, your commit history isn't going to be changing.

+If there isn't a difference between the two repositories then either you're prematurely optimizing your development and shouldn't worry about this issue OR you've got larger separation of role issues to deal with beyond being able to change your repository's history.

Git is aimed at people who know what they are dong.

Others will benefit from a more restricted feature set.

The bottom line for me is, that criticizing Git for not being immutable is like criticizing Ferrari for being too damn fast.