Felipe Contreras <felipe.contre...@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'. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
