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

From: Felipe Contreras <felipe.contreras@gmail.com>
Date: Apr 4, 2013, 19:13 UTC
Message-ID: <CAMP44s1b_SWkVXe2Vyzs2yj1M9Z-2KcCXbp9LCJ_oWxuC+2pAg@mail.gmail.com>
In-Reply-To: <87y5cyqhya.fsf@59A2.org>

On Thu, Apr 4, 2013 at 12:17 PM, Jed Brown <jed@59a2.org> wrote:

Show 9 quoted lines

> Felipe Contreras <felipe.contreras@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