6

I used hg shelve in a repository, where I had some unfinished changes because I needed to switch to a different head and perform unrelated changes.

Once my work on the other head was committed, I switched back to the head on which I had originally used hg shelve and ran a hg unshelve command. This was the result:

$ hg unshelve
unshelving change 'default'
adding changesets
adding manifests
adding file changes
added 1 changesets with 4 changes to 4 files (+1 heads)
abort: uncommitted changes
$ hg diff
warning: ignoring unknown working parent 893e15ecb5b4!
$

I did run hg head before and after the unshelve command and saw identical outputs. The commit 893e15ecb5b4 never existed, I have no clue where Mercurial got it from.

In case it is of any relevance, I am running Mercurial version 2.8.2 on Ubuntu 14.04.

How can I get my repository back in a working state, and how can I get my shelved changes back?

kasperd
  • 1,952
  • 1
  • 20
  • 31

1 Answers1

8

The following steps solved the problems for me:

  1. Use hg debugsetparents to replace the corrupted parent revision number 893e15ecb5b4 with the correct one I had updated to before using unshelve
  2. Because the above had left me in a state where Mercurial had forgotten all local changes, I had to use hg manifest | tr '\n' '\0' | xargs -0 touch to get it to notice any local changes again.
  3. The shelved changes could be recovered using patch -p1 < .hg/shelved/default.patch, which in my case did exactly what hg unshelve should have done for me in the first place.
kasperd
  • 1,952
  • 1
  • 20
  • 31
  • 4
    `hg debugrebuildstate` is probably what you need instead of #2. – Mark Tolonen May 13 '15 at 16:05
  • @MarkTolonen Because it is simpler than what I did? Or because there would be additional information which could be out of sync? If it's the later, then what information would be out of sync? – kasperd May 13 '15 at 16:08
  • 2
    It forces Mercurial to rebuild its internal state, so I imagine it is more accurate. I got the tip from http://hgtip.com/tips/advanced/2010-04-23-debug-command-tricks/ – Mark Tolonen May 13 '15 at 16:11