title: Backing Out a backwards merge on Mercurial
body: <p>How do you reverse the effect of a merge on polarised branches without dying of agony?</p>
  
  <p>This problem has been plaguing me for <strong>months</strong> and I have finally given up. </p>
  
  <p>You have 1 Repository, with 2  <strong>Named</strong> Branches.  A and B. </p>
  
  <p>Changes that occur to A will inevitably occur on B. </p>
  
  <p>Changes that occur directly on B MUST NEVER occur on A. </p>
  
  <p>In such a configuration, merging "B" into "A" produces a dire problem in the repository, as all the changes to B appear in A as if they were made in A. </p>
  
  <p>The only "normal" way to recover from this situation appears to be "backing out" the merge, ie: </p>
  
  <pre><code> hg up -r A 
   hg backout -r BadMergeRev --parent BadMergerevBeforeOnA 
  </code></pre>
  
  <p>Which looks all fine and dandy, until you decide to merge later in the correct direction, and you end up with all sorts of nasty things happening and code that was erased / commented out on specifically branch B suddenly becomes unerased or uncommented. </p>
  
  <p>There has not been a working viable solution to this so far other than "let it do its thing, and then hand fix all the problems" and that to be honest is a bit fubar.  </p>
  
  <p>Here is an image clarifying the problem: </p>
  
  <p><em>[Original image lost]</em></p>
  
  <p>Files C &amp; E ( or changes C &amp; E ) must appear only on branch b, and not on branch a.
  Revision A9 here ( branch a, revno 9 ) is the start of the problem. </p>
  
  <p>Revisions A10 and A11 are the "Backout merge" and "merge the backout" phases. </p>
  
  <p>And revision B12 is mercurial, erroneously repeatedly dropping a change that was intended  not to be dropped. </p>
  
  <p>This Dilemma has caused much frustration and blue smoke and I would like to put an end to it. </p>
  
  <h3>Note</h3> 
  
  <p>It may be the obvious answer to try prohibiting the reverse merge from occurring, either with hooks or with policies, I have found the ability to muck this up is rather high and the chance of it happening so likely that even with countermeasures, you <em>must</em> still assume that inevitably, it <em>will</em> happen so that you can solve it when it does.</p>
  
  <h3>To Elaborate</h3>
  
  <p>In the model I have used Seperate files. These make the problem sound simple. These merely represent <em>arbitrary changes</em> which could be a separate line. </p>
  
  <p>Also, to add insult to injury, there have been substantial changes on branch A which leaves the standing problem "do the changes in branch A conflict with the changes in branch B which just turned up ( and got backed out ) which looks like a change on branch A instead " </p>
  
  <h3>On History Rewriting Tricks:</h3>
  
  <p>The problem with all these retro-active solutions is as follows:</p>
  
  <ol>
  <li>We have 9000 commits. </li>
  <li>Cloning freshly thus takes half an hour</li>
  <li>If there exists <em>even one</em> bad clone of the repository <em>somewhere</em>, there is a liklihood of it comming back in contact with the original repository, and banging it up all over again. </li>
  <li>Everyone has cloned this repository already, and now several days have passed with on-going commits.</li>
  <li>One such clone, happens to be a live site, so "wiping that one and starting from scratch" = "big nono" </li>
  </ol>
  
  <p>( I admit, many of the above are a bit daft, but they are outside of my control ). </p>
  
  <p>The only solutions that are viable are the ones that assume that people <em>can</em> and <em>will</em> do everything wrong, and that there is a way to 'undo' this wrongness. </p>