== Why version control systems should support 'rewriting history' There's a hot debate about whether VCSes should allow developers to 'rewrite history' ([[in the git sense GitNewHistory]]). The usual way to frame the options can be wrapped up as a question: should the VCS allow developers to rewrite history, or forbid it? Put this way, a fair number of people will incline towards 'no'. But this is a misleading and wrong question, because it quietly assumes that the VCS can actually stop people from rewriting history. This is incorrect; no VCS that has branches and lets developers apply patches can stop them from 'rewriting history' by hand if they want to badly enough. (This especially applies to DVCSes, where you can clone repositories outright and then throw away clones you don't want.) So the actual choice that we have is this: should the VCS provide convenient support for letting developers rewrite history, or should it refuse to help and force them to do it all by hand? As it happens we already know that developers are going to do this, one way or another; they do now to such an extent that there are various programs to help them with it (and I'm not talking about DVCSes that already support this). Since it's going to happen anyways, having the VCS support it has three advantages: * you can give developers as much help as possible with what is a tediously annoying and potentially tricky operation. * you can capture information about what actually going on. * you may have a chance to gently steer developers away from bad ideas, provided that you can give them a good alternative. By contrast, the VCS washing its hands of the whole deal means that it is abandoning the developers and abrogating any chance it might have had to mitigate damage or do any good. (But you get some mathematical purity out of it; [[my views on that SecurityIsPeople]] are [[on record VCSDependencyProblem]].)