Re: [PATCH v2 11/13] remote-hg: force remote push

[Jed Brown <jed@59a2.org>]

Felipe Contreras <felipe.contreras@gmail.com> writes:

> If that's the case, they should disable in the server, just like some
> people disable non-fast-forward pushes in git.

I don't know how to make Hg allow new branches and bookmarks, but not
new anonymous heads.  Vanishly few Hg projects use a workflow anything
like topic branches so it's normally not a common thing to be creating
new heads.  If someone is using remote-hg, we can be pretty sure they
are not the primary maintainer, so if they are pushing, they'll be aware
of upstream policy and will need to play by those rules.

> The problem is Mercurial, purely and simple, without forcing the push,
> how do you expect this to work?
>
> % git clone hg::whatever
> % git checkout -b feature-a master
> # do stuff
> % git push -u origin feature-a

There is a difference between pushing a new branch (see 'hg push
--new-branch -b branch-name') and creating arbitrary new heads.  In a
very common case where multiple people are pushing to the same
branch/bookmark, force push creates new anonymous heads that share the
same branch.  (For less familiar readers, hg branches can have multiple
heads, though most commands will behave as though the latest head to
appear in the repository is the unique head associated with a given
branch.  Yes, it's insane.)

Normal workflow in case of new commits upstream is to 'hg pull --rebase' or
to pull and merge (yucky for first-parent, but most Hg users are far
from caring about such things).  Silently creating new anonymous heads
is a bad default.

Note: I don't know of any way to avoid the race condition when pushing
a bookmark that creates a new head since there is no 'hg push --new-bookmark'.