Perhaps it is useful to point out that this happens on a daily basis in
our environment.  It goes like this:

    * Developer A works on new-feature branch, decides to merge changes
      from bugfix branch.
    * Developer B works on bugfix branch, commits a change and tries to
      push.

Since we have some A-type developers who wish to merge often (perhaps
more than once per day), all of the B-type developers cannot foresee
whether the "-f" warning printed by Mercurial should be ignored or heeded.

Kai

Mozilla has been running into this. I still think that --force should not be
needed for (re-)starting a branch, but mpm disagrees.

I think this "--force is only needed the first time" is not the whole truth.

We have the default branch which contains the stable code.  And then there is an
"unstable" branch for the new feature stuff.  Now, folks working on unstable
will regularly do "hg merge -r default" to profit from the bugfixes.  But after
someone has done "hg merge -r default" and pushed the result, then the default
branch has lost its head.  Thus, the first commit on the default branch
afterwards will produce a "use -f to force" warning on "hg push".

IMHO it is highly counterintuitive that things done on a different branch mean
that I have to use push -f.

Changed title to distinguish this from Issue756, which seems related.

Yes, in that case you need --force push only the first time.
And pushing a new branch (named or not) should be an explicit action.
(so you could say it doesn't need enough --force if you branch off of tip)

Hrm, the scenario I was thinking of was fixing a bug on a branch that was
already fixed in default or otherwise doesn't effect default so no merge should
be needed.  I can understand if I have to --force push to a named branch, I was
just curious why I have to --force (only the first time?) changes to default. 
I'll play some more with my test repos and see if this works for me.

If the changes done to <branchname> will be merged with default (to fix a
problem only in the release and merge it into the devel/default branch), you
will have to do a merge in the devel repo anyway, so the warning about new heads
is quite helpful.

If you don't want to merge, the maint tree will become a separate head after the
first push --force, so on subsequent fixes there is no need to use --force again.

Comment to your 'clone -r <TAG>': with this the tag will not be transferred,
because the tag is recorded in a changeset that happens after the to-be-tagged
changeset. Therefore you might want to clone the whole tree and update to the
tag later.

With named branches you would use either 
$ hg clone -r 1.2.3_maint foo bar
or even better
$ hg clone foo#1.2.3_maint bar
(the later would prevent subsequent pulls from pulling in history of other branches)

So maybe I don't understand what the right method is.  In my live repo I have
tip and tip only.  I have tags at each release point but I haven't turned them
into branches yet due to not understanding the behavior.  As I understand it, I
would do a clone -r <TAG>, then hg branch <branchname>, then a commit/push.  I
would do this for each release point.  But I want to keep working on the
"default" branch which is where active development happens.  It seemed in my
testing that to push something from "default" back to the branched repo I would
have to use --force.  What am I doing wrong in my thoughts?

With this you will need --force only when creating the release maint branches
(this is good), but not when appending changes to active branches.

Of course, if you merge the maint branch into the main branch (which we do with
hg  main vs. hg stable, too, just without names), then the maint branch always
is inactive. In this case you won't get a warning, too, if you don't merge the
fix into the default tree, I think this is good, too.

So for these two use cases the current behaviour is good, or not?

So in my development model we aren't going to be using named branches for new
features that often.  Instead we'll be using the named branches for maint work
on old releases.  Say I have software that I use to create Fedora releases.  I
want to create a branch at each Fedora release time, so that if I have to fix
bugs for the version of that software in that Fedora release I can fix it on the
branch and issue a package update from the branch, while "default" is used for
continued new development.  Having to --force all the time feels dangerous on
the default branch.

In this case the default branch is inactive, therefore it is quite likely that
you want to develop in coolbranch (or merge with it now).
If you're sure you want to extend the default branch, just use more --force.

Still it would be nice if the push code would know more about named branches,
e.g. to notice that 'default' will grow a second head while some other named
branch will lose one.

I adjusted the title for this.

Given a repo that has multiple branches, "default" and "coolbranch".
Clone the repo, notice that current branch is "default".  Do a pull, do
an update just to make sure you're all updated.  Make some change to
the working copy, commit it, and push.

pushing to /home/jkeating/test/head
searching for changes
abort: push creates new remote branches!
(did you forget to merge? use push -f to force)

Response from mailing list was:

This is a bug in hg, the network stuff isn't really aware of named
branches, it will only notice that the number of heads changes.