4

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?

2

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
2

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.