branching out –
[default]$ hg branch talks
[talks]$ <... some commits ...>
[talks]$ hg update default
merging back –
[default]$ hg merge talks
3 files updated, 0 files merged, 0 files removed, 0 files unresolved
pushing to remote repo –
[default]$ hg commit -m "merging talks to default"
[default]$ $ hg push
abort: push creates new remote branches: talks!
(use 'hg push --new-branch' to create new remote branches)
Further investigation revealed that remote repo doesn’t want me to have multiple heads at the remote end. But I just did a merge to merge the two heads into one, isn’t it?
The graph from hg serve also seems to agree with me (I hope)

However, I also see two heads from hg heads
[default]$ hg branches
default 9:85752ecd6326
talks 8:2b00714d76d5 (inactive)
I’m guessing you’ve misunderstood the branch feature. You’ve just created a branch who’s name will live forever in the repository. I suspect you didn’t really want to do this. You might want to investigate the bookmarks feature for local branches that don’t end up with names that live forever in the repository.
Mercurial balks at pushes that add new global branch names to the repository being pushed to because that’s so very rarely what you really want to do.
hg push --new-branchwill tell Mercurial that yes, you really mean to do that.The two heads you’re seeing are misleading. Notice how one head is listed as ‘(inactive)’. That just means it’s the last change on the global branch, but not an actual head. You frequently want to see the heads of branches, even if those heads actually have children and are not really heads.
As a small aside… I wrote the code that added that feature to the ‘heads’ command awhile back. 🙂