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

[Jaikiran Pai]

On Friday 06 February 2015 01:12 PM, Jaikiran Pai wrote:
> On Friday 06 February 2015 12:41 PM, Sean Farley wrote:
>>> 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.
>
> Sean, the thing I wish was easier was local/lightweight branches in 
> mercurial. As a developer working on various different features, bug 
> fixes locally I wish it's easier to just do a "hg up 
> local-branch/bookmark/or-whatever-other-term", then do some commits on 
> it and don't have to worry that those commits will end up remotely 
> unless I explicitly push them. The "paths" proposal sounds like it 
> could take care of this. From what I understand of that proposal, it 
> sounds like I would be able to do in hg what I currently can do with 
> local lightweight branches in git like:
>
> git checkout local-branch-foo
> ... // do changes
> git commit -m "WIP commit locally"
> git push upstream master // i.e. *don't* push local-branch-foo but 
> only push the branch named master to upstream remote repo
> ... // more changes to local branch and now ready to have it included 
> in master branch
> git rebase upstream/master // rebase my local branch commits on top of 
> upstream master branch
> git push upstream master // now that the local commits are ready to be 
> pushed to upstream and are rebase on (local) master branch, push it to 
> the remote master branch

To add to this earlier reply, IMO, it's not about having to add one 
command line option of -s. It's much more than that when there's more 
than 1 developer within a team. It's hard to enforce using the -s when 
it's not the default or when it involves having to carefully remember 
that you are on a local bookmark and commits to that bookmark should be 
secret. I think what I'm getting to is that, having a standard default 
way to isolate/scope commits to the local bookmark and be assured that 
those won't end up to remote repo (unless explicitly done) is much more 
preferable, instead of expecting every developer in the team to be using 
the -s option, IMO.

-Jaikiran