Fixing divergent changesets

[David Douard]

On 11/13/2014 04:40 PM, MHarbison at attotech.com wrote:
> Now that I've shot myself in the foot, I understand what I did wrong, and am
> wondering what options I have for fixing this.
> 
> I had a graph like this:
> 
> o -- o -- A -- o -- o ...
> 
> I intended to split A apart, so I updated to A, amended it, and then reverted the
> files back to A and committed, so that I had something like this:
> 
> o -- o -- A' -- B
>             \
>              A -- o -- o
> 
> Thinking I could then manually record that this was a split, I tried:
> 
> $ hg kill A -s B
> 1 changesets pruned
> 2 new divergent changesets
> 
> Oops.

Nothing wrong here, no reason to oops.

What you got here is then:

o -- o -- A' -- B
            \  /
             A -- o1 -- o2
  
means A is obsoleted by 2 new changesets (A' and B), but the remaining of your code 
history is still on A, which is obsolete, thus unstable. So everything is OK but need 
a bit of cleaning.

> So I tried this:
> 
> $ hg evolve
> abort: conflict rewriting. can't choose destination

'hg evolve' don't know what to do (there is no "one obvious solution", some heuristics 
might be implemented, but not yet available). 

But *you* know how to fix it, *you* know that the remaining of your code history should 
now live on the top of B. So be it:

  hg rebase -s o1 -d B

And you're done, no more instability. Coffe time.

As a user of evolve since the very beginning, I don't trust 'hg evolve' a lot, so I almost 
always resolve my instability problems by rebasing.


Cheers,

David Douard



> I must have done something else when I first ran into this, because while I got
> the message above, I then started getting this message:
> 
> $ hg evolve
> base of divergent changeset not found (this case is not yet handled)
> 
> I wasn't able to get the "not yet handled" case when trying to recreate the
> issue.
> 
> 
> So, a couple of questions:
> 
> 1) What are my options for fixing this?  I really don't want to reclone and
>    manually move all of the shelves and MQs over.  I suppose I could just export
>    the csets, tweak the time and reimport them after killing the originals.
> 
> 2) I think kill should check for successors before operating.  Should it require
>    a -f, or just abort if there are successors?  Other than setting up a test
>    case, I'm not sure why it's useful for the user to create divergent markers
>    inside a single clone.  In recreating this scenario, I was also able to do
>    this _after_ the amend:
> 
> $ hg kill A -s A'
> 1 changesets pruned
> 
> But the changeset was already pruned, and I only realized I typed the wrong
> value because I was expecting the divergent message.  Perhaps this should abort
> and hint that it is already pruned?
> 
> --Matt
> 
> 
> _______________________________________________
> Evolve-testers mailing list
> Evolve-testers at selenic.com
> http://selenic.com/mailman/listinfo/evolve-testers
> 


-- 

David DOUARD		 LOGILAB
Directeur du département Outils & Systèmes

+33 1 45 32 03 12	 david.douard at logilab.fr
+33 1 83 64 25 26	 http://www.logilab.fr/id/david.douard

Formations - http://www.logilab.fr/formations
Développements - http://www.logilab.fr/services
Gestion de connaissances - http://www.cubicweb.org/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: david_douard.vcf
Type: text/x-vcard
Size: 302 bytes
Desc: not available
URL: <http://lists.mercurial-scm.org/pipermail/mercurial-evolve-testers/attachments/20141113/02aa37bb/attachment-0002.vcf>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: OpenPGP digital signature
URL: <http://lists.mercurial-scm.org/pipermail/mercurial-evolve-testers/attachments/20141113/02aa37bb/attachment.asc>