If you're trying to redo the last commit (perhaps with a better commit message, perhaps with a bug fixed) then you should now use
$ hg commit --amend
to update the last commit. That is much safer than using hg rollback as described below.
If the commit is the last commit and you have not updated anywhere, then you can use hg rollback. Please read hg help rollback — is it a potentially destructive command.
What it does: hg rollback will roll back the last transaction in your repository. Every time you hg commit, hg pull, hg unbundle, etc, you create a new transaction. When everything is stored safely, Mercurial closes the transaction. If something goes wrong in the middle of the transaction, Mercurial can recover (see hg recover). You can also manually roll back the last transaction with hg rollback. See hg rollback --dry-run for a preview of what the command will do.
The rollback command wont touch your working copy. This means that files that showed up as modified before will appear modified again. So it's easy to do
$ hg commit -m "Fixed buug-123"
Ups, typo in the commit message! Let's fix that:
$ hg rollback
$ hg commit -m "Fixed bug-123"
(Use hg commit --amend instead with Mercurial 2.2 and later.)
The last commit message is also saved in .hg/last-message.txt so you can recover it from there if you don't have it in your shell history.
What if I have uncommited changes before I want to do hg rollback? Do I have to commit those first?
Rollback doesn't touch the working copy. This means that any additional changes in the working copy will appear together with the changes from the changeset. It's as if you didn't type hg commit at all.
What about last several commits? Does sequential hg rollback stack up changes from those commits to existing uncommited changes?
No, you only have one level of rollback since we only track the last transaction.
