After pushing to a review repository, "abort: can't rebase immutable changeset" on rebase

Question

We have a code review repository where people hg push -f all sorts of stuff. After reviews are complete, we pull from the project's central repository, rebase, and push. I recently upgraded to mercurial 2.1 and get this message:

abort: can't rebase immutable changeset 43ab8134e7af
(see hg help phases for details)

when I try to hg pull --rebase from the central repository. How do I fix it?

Achene

Answer 1

In the review repository's .hg/hgrc file, add these lines:

[phases]
publish = False

The problem is due to a new feature in mercurial 2.1 called phases. It's great. Here is a nice introduction to its use.

To make the changesets in question mutable right now, use hg phase -f -d REV to force REV to be mutable again. Once the hgrc file has been changed, you shouldn't have to do that any more.

As a side note, hg push -f is lame. Make an alias hg review that pushes with -f to that repository.

Achene

@DanielSokolowski: Did you put it in the review repository's hgrc? That sounds like you put it in the local repo's hgrc file. – Achene

Answer 2

I don't think disabling phase support on the server is the correct solution, but your problem sounds weird.

Pull --rebase should rebase your local changes, on top of the remote changes, which should be allowed, even if phases are supported by the client, as long as these changes have not been seen by anyone else, eg. they haven't been pushed out anywhere.

Is it possible that you have already pushed your your own changes, to somewhere else (which set them to public phase), and after that tried pulling from the testing repo? Because then, this is the correct behaviour that you are seeing.

Most of the time it is a bad idea to mess with phases manually (with hg phase -f), because it can easily lead to a history rewrite, which can lead to duplicated changesets, or various errors when other people try to pull/push. If a changeset became marked as public (as in your case), it probably happened for a good reason.

Emmaline

Right, normally that would all be true. However, since we're pushing things to a review repository (from which pulls are illegal; preoutgoing=/bin/false) and then potentially rebasing them before sending them out to the production repo, we don't want the reviewed changesets to be made public. And yes, hg phase -f is normally bad. I was just suggesting its use for changes that had been made public before the review repo's hgrc file change went into effect. – Achene

Answer 3

I've encountered such behaviour with collapsed rebase. Phasing out back to draft hadn't helped me. So I've just pulled up (hg pull -u) to sync with remote repo, then just grafted the problem commit (hg graft <problem_commit>) and then amended this very new commit.

Dihedral

What do you mean when you say phasing out back to draft didn't help you? If hg phase -f -d REV doesn't let you rebase REV, something is seriously wrong. – Achene