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

On Thu, Apr 4, 2013 at 2:14 PM, Jed Brown [off-list ref] wrote:

Felipe Contreras [off-list ref] writes:

quoted

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.

It's not possible to push new bookmarks without pushing new heads
(unless they are all reusing the same commits), and all the drawbacks
of doing that, Merucrial's UI make sure of that.

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.

No, we don't. The fact that you say so doesn't make it so.

I create a branch felipec-bookmarks, and I push as many heads as I
wish. Who will get affected? Nobody. I already explained that, and you
conveniently avoided that paragraph in the reply.

quoted

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.

feature-a is not a branch, it's a bookmark, and bookmarks cannot be
pushed without creating new heads (essentially).

Normal workflow in case of new commits upstream

And who says we are committing upstream?

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'.

This is not about the race condition, and the race condition cannot be
fixed with the current design.

-- 
Felipe Contreras