graft backouted commit - 'skipping ancestor revision'

Wujek Srujek wujek.srujek at gmail.com
Tue Dec 11 18:01:12 UTC 2012


We had the following problem today: there were two (already published)
commits on default that should really be done on a different branch (which
didn't exist yet). What we wanted to do is the following:
1. remove these 2 commits from default
2. create a new branch and apply the commits there

So we did this:
1. hg backout -r 2nd_commit
2. hg backout -r 1st_commit
(We did it in reverse as we thought it will be easier to do for mercurial -
fewer conflicts - and for us to understand, but does this really play any
role here?)
3. hg branch new_branch
4. hg graft -r 1st_commit -r 2nd_commit
The last step didn't work with the message 'skipping ancestor revision
1st_commit'. I understand why this is happening, but maybe mercurial could
perform the graft? After all, the commit is as good as undone, so maybe
backout could add some metadata somewhere to say that this backouted commit
effectively is no more there? Or am I missing something obvious why this is
a bad idea?

What we eventually did was we exported patches from both commits and
imported them again to the working copy, and it worked. Is there any better
way to do this?

wujek
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurial-scm.org/pipermail/mercurial/attachments/20121211/2e1cb1ad/attachment-0002.html>


More information about the Mercurial mailing list