Why did "hg push", push my local bookmark to remote?

[Sean Farley]

Jaikiran Pai writes:

> Hi Nathan,
>
> On Friday 06 February 2015 12:05 PM, Nathan Goldbaum wrote:
>>
>> So it looks like I completely misunderstood the documentation 
>> (http://mercurial.selenic.com/wiki/Bookmarks) about bookmarks. I 
>> considered them to be local branches (like in git) *and* the commits 
>> being local too.
>>
>>
>>         So from what I understand then, there's no way to limit the
>>         visibility of the commit from the remote repo? In other words,
>>         no way to hide my local changes from the remote repo? (I see
>>         that you suggest a alias for this and I'll come to that later).
>>
>>         The way I was planning to use bookmarks was something like this:
>>
>>         1. Have a local workspace which points to 2 different remote
>>         repos. Remote repo 1 points to "upstream" which is used by the
>>         entire team and remote rep 2 points to my own private
>>         repository hosted remotely (example bitbucket).
>>
>>         2. While working on a major feature, I create a local bookmark
>>         "foo-bar" and start committing it to it. I don't want any of
>>         these commits to show up in "upstream" remote repo till I
>>         explicitly pull them into the default branch and push them to
>>         that repo. I however, want to have these changes
>>         available/backed up in my private remote repo, so I keep doing
>>         an explicit "bookmark push" so that changes belonging to this
>>         bookmark are visible in my private remote repo.
>>
>>         From what I gather, that probably won't work without being
>>         extra careful (i.e. a plain hg push can result in the upstream
>>         repo receiving my commits from the bookmark).
>>
>>
>> You might find the phases feature to be useful, in particular marking 
>> local work as secret:
>>
>> http://mercurial.selenic.com/wiki/Phases
>>
>> Commits in the secret phase are not pushed by default.
>
> That does look interesting/promising. In fact, the "commit" command 
> allows the -s option (at least in 3.3 version of mercurial) to make it a 
> secret commit. I can create an alias for "commit" to be "commit -s" and 
> be a bit more assured that my local commits aren't pushed to remote. 
> I'll have to try out a few things with this to maybe come up with a 
> optimal setup where I can perhaps mark all commits as secret *only when 
> I'm currently on a bookmark* or some such thing. I'll also experiment a 
> bit on how various other commands and extensions behave with such 
> commits and my regular dev work flow. Thanks for pointing to this, Nathan.

That is the way to do this now.

> I however wish that it was much simpler than this and maybe that 
> proposal in that mercurial-dev thread from 2012 could be revisited to 
> improve the situation?

That is moot as far as I understand. What would be considered now is a
proposal to improve the 'paths' option to only push certain branches to
specific remote servers.

I don't understand what you want to be easier. You are saying that
adding *one* command-line option of '-s' to your secret branch is too
hard? I find that very explicit and refreshing that Mercurial is doing
what I told it to do: mark this secret. Commits on top of secret commits
are always secret.