Search code examples
mercurialpushbitbucket

Unexpected new head created

I am working with Hg and TortoiseHg on a project and pushing every couple of days to a remote repo on Bitbucket. When I tried to push changes today, I got an error saying that I was trying to create a new head. I thought this was odd since I am definitely the only person working on the project and I work from one PC.

I pulled to see what was going on on the remote repo and after pulling the local repo tree looks like so:

Local Repo

At the bitbucket end the repo looks like this:

Remote Repo

Can someone help me understand why I got two heads if I'm the only one working on the project and why Hg is not recognising that Rev.40 and Rev.36 are the same revision?

How do I fix this now? If I strip 40 locally, what will happen when I try to push changes to the remote repo? Will it strip the revision at the remote repo too?

Solution

  • you can try this (on a clone repo if you prefer to be sure)

    having a clean workgin directory

    hg co 40
hg backout -r 40
hg merge 39
hg push

    revision 40 would be the one that exists in the remote repo, before the amendment so, you check it out, you back it out (put the inverse on top of it) then you merge your ongoing work (left at 39) and there should be no merge conflicts at all, since all changes are incoming then, when satisfied, you push

    ===

    why I got two heads

    this part was already addressed in the comments, you realized you amended the commit after pushing it, thus the apparent duplicate of it

    How do I fix this now?

    you do a merge on your local repo, to get rid of the two heads, so having only one the remote repo won't complain about it if you like, you can backout the before-amendment commit to be safe (or not, if you really know how to merge the conflicts making your local prevail) but in both these cases, the non-amended commit survives, therefore it'll show up in your history, beware

    If I strip 40 locally, what will happen when I try to push changes to the remote repo?

    is gonna be there unless you strip it there (directly on the remote repo)

    Will it strip the revision at the remote repo too?

    no, it won't