Mercurial for Subversion Expats: Merging remote changes. “abort: push creates new remote heads!”

November 14th, 2010 3 minutes reading time.

Commit anywhere/anytime with Mercurial

So you have been using subversion for the past few years and now your team has decided to move on to Mercurial for all the benefits. Two or more people are working on the same branch and they’re pushing code to the main copy of the repository before you’re done with your changes.

In the Subversion world, if you tried to commit in this same situation you’d get an error saying that your repository checkout is not up to date, so you’d fix this by doing:

$ svn up #gets the latest changes from the repo and it tries to merge all remote changes
$ # ... solve any conflicts if they arise.
$ svn ci -m "my commit message" #push your latest changes to the main repo.

In Mercurial it’s a little bit longer

$ hg ci -m "my local changes"
$ hg pull #this brings the latest version of the repo, but doesn't change the state of your files.
$ hg merge #when you're ready, you merge the changes

If at this point you try to push, you will get the following error

$ hg push
pushing to
searching for changes
abort: push creates new remote heads!
(did you forget to merge? use push -f to force)

first, ignore the “push -f to force”, they should remove that message and put something like

(did you forget to merge and commit?)

After a lot of thinking I was doing something wrong with the merge, I realized that before pushing you have to commit your merge locally as well, makes sense, so the whole sequence should be like this instead:

$ hg ci -m "my local changes" #same as 'hg commit'
$ hg pull #this brings the latest version of the repo, but doesn't change the state of your files.
$ hg merge #when you're ready, you merge the changes
$ hg ci -m "merging latest changes from repository"
$ hg push
pushing to
searching for changes
http authorization required
realm: HTTP
user: gubatron
adding changesets
adding manifests
adding file changes
added 2 changesets with 1 changes to 1 files
bb/acl: gubatron is allowed. accepted payload.

So, yes, its a little more work to merge and commit, but remember that you’re working now on a distributed fashion and you have to think a little bit differently, you gotta merge locally, fix any conflicts if they arise, commit the changes and push them. In exchange you don’t get to deal with lots of .svn folders, no single point of failure (one remote repo that could go down and leave all developers without version control until it’s back up), and super easy branching on a single folder, no need to checkout branches and be writing down revision numbers.

Just remember that pulls don’t change your local changes unless you explicitly ask to do so by invoking hg merge; hg commit, which would be the equivalent (at least I see it like this) to svn up

Please Donate To Bitcoin Address: [[address]]

Donation of [[value]] BTC Received. Thank You.

4 Responses to “Mercurial for Subversion Expats: Merging remote changes. “abort: push creates new remote heads!””

  1. asdf Says:

    Just use “hg fetch” to automate away the pull/merge/commit sequence

  2. gubatron Says:

    gubatrons-macbook-pro-2:$ hg fetch
    hg: unknown command ‘fetch’

    I suppose it must be some extension.
    I had already implemented a command of my own to automate the sequence. Thanks!

  3. gubatron Says:

    Ok, “hg fetch” is indeed an extension, and it’s just an alias for “hg pull -u”

    You enable it by adding the following in the [extensions] section of your .hgrc file


  4. robinsonc494 Says:

    Nothing related to this post but I followed a link from on what I believe was your profile.
    I’m the user you replied to on the WordPress nosql fork. I’m pasting below what I said over there in the hopes that you’re notified.
    I couldn’t find a link to contact u, I’m using my mobile so I may have missed it.

    Ive only been poking around at the source code. with no interest from anyone to help I was going to leave most of it until next summer when I have more time to do it on my own but certainly if I’m getting any help then I’d be willing to kick up the pace right away. I’m also very familiar with Apache cassandra,writing a book on it in fact. So if you’re team has no ties to mongodb then even better. Although I should be able to easily learn the ons and outs of mongodb. Please let me know if this can go on, I’d be very interested in being a part of it.

    I’ve included my correct email above. Drop me a line.

Leave a Reply