In defense of mutable history

With Git, you have a multide of ways to slice and dice commits: the index lets you commit things in bits and pieces as you go; the stash gives you a way to transplant changes between branches or shelve work for a while; the power of rebasing allows you to go back and split large commits sensibly into atomic ones. In other DVCSs, all of this is also possible but requires painstaking busywork using far less powerful tools; in centralised VCSs most of it is for all intents and purposes impossible to do at all.

But lately I’ve seen entries cautioning against the use of this power. To me this seems like a sign that Git has arrived – it is pulling in people who don’t subscribe to the philosophy behind its design. Personally, I consider the argument for immutable history a terrible idea, even if it is logically defensible within certain parameters. Why?

In contrast to systems with immutable history, Git doesn’t force you into any sort of careful premeditation where you try to anticipate all possible and impossible problems you may or may not realise yet. You go about business as usual, and if you belatedly notice a problem you hadn’t thought of or couldn’t even have been aware of at the time, you just go back and fix it. No sweat. Think of it as the Never Use a Warning When you Mean Undo principle, applied to version control.

Git is humane, in the Aza Raskin sense.

Update: Chris Siebenmann makes a good point that rewriting history in Git is actually no such thing. Of course, that is why pushing “rewritten” history causes the problems it does. And of course that in turn is actually desirable, and thus very much by design.