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