I just made a commit that I want to reverse, but I want to keep the bad commit in history. So, I hg update to the previous (good) commit. Then I keep working.

This leaves me with a new head: the abandoned bad commit.

Is this bad practice? What's the best way to keep bad commits in history while not using them?


If you don't want the branch you don't have to have it, use hg revert.

using revert will still keep the bad commit in history, it will create a new commit that undoes the changes from the bad commit.

  • stackoverflow.com/questions/2506803/… gives the difference between the two if you want to know that – jk. Mar 9 '13 at 9:19
  • 3
    +1, and remember you can revert the revert if you want to bring the changes back again. – MattDavey Mar 9 '13 at 12:22
  • Is this the preferred way to keep bad commits? I guess I'm looking for best-practices; it seems like either way would work. – Tom Marthenal Mar 9 '13 at 19:18
  • yes id say it is preferred compared to branching (via update) – jk. Mar 13 '13 at 9:09

If you want to keep track of the mistake in the history you want to use backout. The backout command will create a new commit that cancel the previous one. You can even document why original commit is a mistake.

  • There are many reasons why adding extra heads is bad, it complicates or destroys ability to safely push/pull and merge for one thing. – Warren P Mar 11 '13 at 13:18

Not the answer you're looking for? Browse other questions tagged or ask your own question.