This script leaves the working directory in an inconsistent state. mkdir bug cd bug hg init echo 1 > file hg add file hg commit -u blah -m r0 echo 2 > file hg commit -u blah -m r1 hg up 0 echo 3 > file hg up -t false hg strip -k -r tip Now when trying to do hg commit, we get: abort: unresolved merge conflicts (see hg help resolve) and when running hg resolve --all: abort: unknown revision '<long hash>'! The same happens if using hg rollback rather than hg strip (doing hg revert -a ; hg up ; hg rollback instead of hg strip). The working dir can be brought back to a consistent state by first backing up the changes if necessary with hg diff or maybe hg shelve (I haven't tried), then running hg up -C. I'm grateful to smf from IRC for this solution.
Strip should probably refuse to work on unresolved repository.
Fixed by http://selenic.com/repo/hg/rev/69154e0ae384 Matt Mackall <mpm@selenic.com> strip: properly clear resolve state with --keep (issue4593) Normal updates automatically clean up the resolve state, but strip --keep does a "manual" update that bypasses the normal machinery. This adds a mergestate reset. (please test the fix)
That fix addresses one of the immediate issues as reported, namely the case of 'hg strip -k', but not the 'hg rollback' one which is how I ran into it in the first place. I'm unclear on whether it should be possible to run into the same issue in some other way. Currently I've found none but it seems plausible to me that there's one or that one is added in future, as there's no low-level check for a conflict between the revision(s) being stripped and the ones affected by the merge. In fact, a TODO item in repair.strip seems to point in that direction: # TODO handle undo of merge sets If I'm correct (which I may well not be because I'm unfamiliar with the hg sources) this bug is a consequence of that TODO item not being implemented.
Fixed by http://selenic.com/repo/hg/rev/59406b8b1303 Matt Mackall <mpm@selenic.com> rollback: clear resolve state (issue4593) (please test the fix)
That fixes the specific case I ran into, thanks.