Fixing divergent changesets

MHarbison at attotech.com MHarbison at attotech.com
Thu Nov 13 17:03:27 UTC 2014


Bryan Murdock <bmurdock at gmail.com> wrote on 11/13/2014 11:25:09 AM:

> From: Bryan Murdock <bmurdock at gmail.com>
> To: MHarbison at attotech.com,
> Cc: evolve-testers at selenic.com
> Date: 11/13/2014 11:25 AM
> Subject: Re: Fixing divergent changesets
>
> When I get into situations where evolve isn't doing what I want, I
> just start using rebase to manually arrange the changesets how I want
> them.  You should *not* have to make a new clone and start over.
>
> Bryan

I don't think that will change anything here though.  The problem is A
has two successors: A' and B.  If I rebase either (or both) they will
get an immediate successor, so there are still two succession paths.
Probably what I need to do is kill one (but then I'd have to manually
recreate it), or fold them (but then I'm right back to where I started).

There's certainly a "don't do dumb things with a power tool" aspect of
this, but it would be nice if there was an easier way to recover from
this before evolve gets integrated into core.  I know I've been saved by
phases before when the rev I wanted to kill was mistyped or off by one.
I don't have any suggestions though.

--Matt

> On Thu, Nov 13, 2014 at 8:40 AM,  <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.  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
> >
> >
> > _______________________________________________
> > Evolve-testers mailing list
> > Evolve-testers at selenic.com
> > http://selenic.com/mailman/listinfo/evolve-testers
> >
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurial-scm.org/pipermail/mercurial-evolve-testers/attachments/20141113/08b1a427/attachment-0002.html>


More information about the Evolve-testers mailing list