On Thu, Apr 4, 2013 at 12:17 PM, Jed Brown <j...@59a2.org> wrote: > Felipe Contreras <felipe.contre...@gmail.com> writes: >> Ideally we shouldn't do this, as it's not recommended in mercurial >> documentation, but there's no other way to push multiple bookmarks (on >> the same branch), which would be the behavior most similar to git. > > The problem is that you're interacting with a Mercurial upstream, not a > Git upstream. When you're in their playground, you have to play by > their rules. Creating new heads is disruptive and not likely to be > appreciated.
If that's the case, they should disable in the server, just like some people disable non-fast-forward pushes in git. 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 If somebody made a single commit to master (default), you can't push any more, you have to merge master to feature-a, and if you push further changes to feature-a and somebody is blocked by that, they need to merge feature-a to master. It's a completely nonsensical workflow, and there's nothing _we_ can do about it. However, it's easy to work around; simply create a 'bookmarks' branch were people can push unlimited amounts of heads, problem solved. The people working with traditional permanent branches won't be blocked by other people pushing bookmarks in a git-like workflow. Why punish the sane people? However we can have a configuration to turn this on and off, I would all it remote-hg.stop-me-from-doing-what-i-just-told-you-to-do. I don't see the hurry though, specially if (according to you), remote-hg can't even clone. Cheers. -- Felipe Contreras -- 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
