Mercurial_ The Definitive Guide - Bryan O'Sullivan [66]
Before I discuss the options that you have if you commit a “brown paper bag” change (the kind that’s so bad that you want to pull a brown paper bag over your head), let me first discuss some approaches that probably won’t work.
Since Mercurial treats history as accumulative—every change builds on top of all changes that preceded it—you generally can’t just make disastrous changes disappear. The one exception is when you’ve just committed a change, and it hasn’t been pushed or pulled into another repository. That’s when you can safely use the hg rollback command, as detailed in Rolling Back a Transaction.
After you’ve pushed a bad change to another repository, you could still use hg rollback to make your local copy of the change disappear, but it won’t have the consequences you want. The change will still be present in the remote repository, so it will reappear in your local repository the next time you pull.
If a situation like this arises, and you know which repositories your bad change has propagated into, you can try to get rid of the change from every one of those repositories. This is, of course, not a satisfactory solution: if you miss even a single repository while you’re expunging, the change is still “in the wild” and could propagate further.
If you’ve committed one or more changes after the change that you’d like to see disappear, your options are further reduced. Mercurial doesn’t provide a way to “punch a hole” in history, leaving changesets intact.
Backing Out a Merge
Since merges are often complicated, it is not unheard of for a merge to be mangled badly, but committed erroneously. Mercurial provides an important safeguard against bad merges by refusing to commit unresolved files, but human ingenuity guarantees that it is still possible to mess a merge up and commit it.
Given a bad merge that has been committed, usually the best way to approach it is to simply try to repair the damage by hand. A complete disaster that cannot be easily fixed up by hand ought to be very rare, but the hg backout command may help in making the cleanup easier. It offers a --parent option, which lets you specify which parent to revert to when backing out a merge.
Figure 9-5. A bad merge
Suppose we have a revision graph like that in Figure 9-5. What we’d like is to redo the merge of revisions 2 and 3.
One way to do so would be as follows.
Call hg backout --rev=4 --parent=2. This tells hg backout to back out revision 4, which is the bad merge, and when deciding which revision to prefer, to choose parent 2, one of the parents of the merge. The effect can be seen in Figure 9-6.
Figure 9-6. Backing out the merge, favoring one parent
Call hg backout --rev=4 --parent=3. This tells hg backout to back out revision 4 again, but this time to choose parent 3, the other parent of the merge. The result is visible in Figure 9-7, in which the repository now contains three heads.
Figure 9-7. Backing out the merge, favoring the other parent
Redo the bad merge by merging the two backout heads, which reduces the number of heads in the repository to two, as can be seen in Figure 9-8.
Figure 9-8. Merging the backouts
Merge with the commit that was made after the bad merge, as shown in Figure 9-9.
Figure 9-9. Merging the backouts
Protect Yourself from “Escaped” Changes
If you’ve committed some changes to your local repository and they’ve been pushed or pulled somewhere else, this isn’t necessarily a disaster. You can protect yourself ahead of time against some classes of bad changeset. This is particularly easy if your team usually pulls changes from a central repository.
By configuring some hooks on that repository to validate incoming changesets (see Chapter 10), you can automatically prevent some kinds of bad changeset from being pushed to the central repository at all. With such a configuration in place, some kinds of bad changeset will naturally tend