"push creates new remote head" issue

Question

I read all SO questions about this issue, and I still can't resolve it.

I am using TortoiseHg. I worked on a side-branch, and now I want to merge it back to the main branch. I pulled all changes made in both branches, updated to the main branch, and merged (and committed). But still when I try to push all this, I get the "abort:push creates new remote head" message.

I also tried (as was suggested in one of the questions in SO) to close the branch using the --close-branch option.

The only thing I did not try is to 'force' push. Any suggestions? Or is force-pushing the only option?

Peppi

Yes, it's incredibly stupid that hg doesn't let you push to a branch when it's only remote head is closed... – Quartziferous

Possible duplicate of Push creates new remote heads! (did you forget to merge? use push -f to force) – Curt

Answer 1

I just tried a similar setup, and I get the same warning. Apparently, although the second head you are trying to push is closed, it is seen as another head during the push. And closing both heads does not seem to be pushable either.

You can force the push, it should be ok, but you could eventually get the same issue if you keep multiple heads on your visualization branch, like you already have with changesets 14 and 20. To solve the issue once and for all, I would instead suggest to merge both changesets (14 and 20) and reclose the final head.

Theis

Merging 14 and 20, that's what I did on 21, and it still gave the same message. – Peppi

No, you did not. 21 is a merge of visualization in default, not visualization in visualization. When I meant merge 14 and 20, it wasn't for a descendant of 14 and changeset 20... – Theis

Ok, so merging the two heads of visualization into default still leaves me with two heads in that branch. Now it makes sense... Thanks. – Peppi

Answer 2

Just for everyone else that runs into this problem. What caused this problem for me were some local revisions on the default branch that I didn't push before I started to work on a new branch.

I had merged the latest revision I pulled for the default branch with my new branch, but these leaves your local changes to the default branch committed but un-pushed.

If you try to push them, it's not your new branch that is creating a remote head, it's the un-pushed revisions to the default branch that is creating a remote head.

When I stripped out those revision with hg strip -r 1234

hg push --new-branch 

went perfect.

What put me on the right track was

hg heads

With showed I had two heads that both had the name of the default branch with different revision numbers.

Lonna

Thank you for "it's unpushed revs to default branch creating remote head"!! For me the fix was to a) open the destination repository (on a local file share) in TortoiseHg Workbench, b) Update to the latest revision there, c) Pull from my local repository 1 revision newer than the server rev, d) close server repo and finally push all changes from local repository. – Weakling

hg strip doesn't exist anymore that I can tell. What would the new command be? – Valuation

Answer 3

Thanks for the answers, I definitely learned some new tricks.

What I ended up doing, is cloning an early revision from the remote repository, that is, a repository that doesn't have all the commits of my merges etc. I then pulled the change-sets, merged, and committed. Then the push finally succeeded.

It was basically the same steps I tried to do before, but apparently on the first (unsuccessful) trial I broke it down to more steps than were needed, and something went wrong at some point.

Peppi

Answer 4

Try this solution,

Assumption. You have enough rights to close and create the branch in the remote

This happens because you are trying to rewrite the history. Just try hg push -f which will create two heads in the remote repo, which you might not

So the first login to your remote and close the branch, now come to your local and push using hg push -f. The necessary new branch will be created automatically with the original condition as it was before.

Mireyamiriam