Martin Pool's blog

Forgiveness in version control

I just typed half a commit message in Subversion and then accidentally committed. I didn't explain the change in as much detail as I really wanted to.

(My natural reaction would be to hit C-c after exiting vi in the hope of catching it before the commit really took place. But from past bitter experience this is likely to lock up Subversion's database, so I have tried to break the habit.)

I'm sure any programmers reading must have done this too, more than once. It's not the end of the world. In this case I'll just do without it. The other pattern people sometimes use is to make a following empty commit which has the rest of the message. It's OK, but it's a bit kludgy.

The darcs version control system has a very interesting fix for this: darcs unrecord.

Most version-control systems are strictly write-forward: once an action has been done, it cannot be undone. This is supposed to give people assurance that their work cannot be lost, but it has negative side-effects, such as being unable to fix incorrect commits. Getting the log wrong is only a relatively minor problem: committing something that should remain confidential, or mixing together two things that should be separate commits are worse. The write-forward model does not have the desirable UI property of forgiveness. Of course you can kludge it in many systems, but that's not forgiving and it tends to be dangerous.

To quote from the GNOME Human Interface Guidelines:

We all make mistakes. Whether we're exploring and learning how to use the system, or we're experts who just hit the wrong key, we are only human. Your application should therefore allow users to quickly undo the results of their actions.

I think darcs gets a reasonably good balance between allowing people to undo mistakes, and protecting them from accidentally losing work.

In darcs, you can remove commits from history — with some limitations. If the change has already been merged into a different tree, or is included in a tag, or is depended upon by something else, then you can't get rid of it without backing that out too. This is as it should be: by the time you ship it, or give the change to someone else, it's too late to discover the mistake. But if it's only in a single distributed repository, it's very friendly to allow it to be backed out. The basic simplifying insight is: if you want to not lose your work, make backups.

Darcs is currently my favourite tool for smallish projects. It's simple and powerful.

[More on darcs]

Archives 2008: Apr Feb 2007: Jul May Feb Jan 2006: Dec Nov Oct Sep Aug Jul Jun Jan 2005: Sep Aug Jul Jun May Apr Mar Feb Jan 2004: Dec Nov Oct Sep Aug Jul Jun May Apr Mar Feb Jan 2003: Dec Nov Oct Sep Aug Jul Jun May