On Thu, Apr 4, 2013 at 2:14 PM, Jed Brown <jed@xxxxxxxx> wrote: > Felipe Contreras <felipe.contreras@xxxxxxxxx> 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. 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. >> 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html