Aborting push if there are new revisions in more than one branch

[Angel Ezquerra]

On Mon, Jan 30, 2012 at 2:12 PM, Pierre-Yves David
<pierre-yves.david at logilab.fr> wrote:
> On Mon, Jan 30, 2012 at 02:06:28PM +0100, Angel Ezquerra Moreu wrote:
>> Hi,
>>
>> Let's say that someone is working on a repo that has several branches.
>> For some reason the user has made changes to several of those
>> branches. Perhaps he is working in some long term stuff in branch
>> "my_feature" but they also need to create a bug fix in branch
>> "stable".
>>
>> …
>>
>> It is easy for the user to forget this and push all changes
>> when he only intended to push the changes to the stable branch. This
>> may result in a user pushing work that he does not intend to push by
>> mistake.
>>
>> …
>>
>> I've seen this a few times already, so I believe it is probably a
>> somewhat common mistake? Is there some easy way to avoid this?
>
> The next version to be release in a few day add a "secret changeset" concept
> that allows you to tag part of the history you don't want to share with the
> outside yet.
>
> On older version you can use the "default=http://repo-url#branch" notation to
> ensure you always push and pull to the defautl branch.
>
> --
> Pierre-Yves David

Thank you Pierre-Yves,

unfortunately I don't think that solves the issue, because if you
forget to make your changesets secret then you have the same problem.

If your branching workflow is based on using multiple clones this is
not a problem, but if you use named branches on a single repo to do
parallel development you can hit this problem very quickly.

It is surprising that mercurial protects you from pushing new branches
and multiple-heads, but it does not protect you from unintentionally
pushing revisions on different heads. Maybe it is an artifact of the
old multiple-clone based branching, which did not suffer from this
problem?

So is there some other way?

Angel