Fixing divergent changesets

[MHarbison at attotech.com]

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.  So I tried this:

	$ hg evolve
	abort: conflict rewriting. can't choose destination

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurial-scm.org/pipermail/mercurial-evolve-testers/attachments/20141113/467156f5/attachment-0002.html>