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

[Nathan Goldbaum]

On Thu, Feb 5, 2015 at 10:25 PM, Jaikiran Pai <jai.forums2013 at gmail.com>
wrote:

> While looking more into this, I just happened to see this thread in
> mercurial-dev mailing list from 2012 which is exactly the situation/problem
> that I am running into (like Alice, from Matt Mackall's example)
> http://selenic.com/pipermail/mercurial-devel/2012-June/040831.html. It
> looked like there was a proposal to change this current behaviour but I am
> guessing it was never done (since I still run into this with latest 3.3
> version). Was there a reason the proposal was dropped?
>
> -Jaikiran
>
>
> On Friday 06 February 2015 11:50 AM, Jaikiran Pai wrote:
>
>> Hi Sean,
>>
>> Thanks for responding. My comments are inline.
>>
>> On Friday 06 February 2015 11:27 AM, Sean Farley wrote:
>>
>>> Jaikiran Pai writes:
>>>
>>>  I used to be a git user but have been using mercurial in a recent
>>>> project, for a while now. Just recently, I decided to use the "bookmark"
>>>> feature of mercurial to have lightweight branches similar to git. The
>>>> documentation at various places about bookmark suggests that if I have a
>>>> (local) bookmark and commits in that booking and I'm pushing to a remote
>>>> repository, then the commits to the bookmark will *not* be pushed to the
>>>>
>>> Incorrect. The commits will be pushed depending on the revset you
>>> requested to be pushed (by default all commits are pushed).
>>>
>> 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.


>
>>
>>> Only the bookmark itself will be pushed if the remote server has it.
>>>
>> To be clear, when you say a bookmark itself will be pushed, do you mean
>> the metadata related to the bookmark will be pushed? And in cases where the
>> remote repo already has the bookmark, the metadata (like what's the latest
>> commit in it) will be updated?
>>
>>
>>
>>> You probably want to create an alias called 'nudge':
>>>
>>> ~/.hgrc:
>>>
>>> [alias]
>>> nudge = push -r .
>>>
>>
>> So would that mean, I would do:
>>
>> hg bookmark "foo-bar" // new bookmark
>> hg up foo-bar // up to the bookmark
>> .. do changes
>> hg commit -m "test commit to bookmark"
>> hg nudge
>>
>> So in that case, it wouldn't push anything to remote since only local
>> bookmark has had new commit? Did I get it right? I'm going to give it a try
>> locally too, to see what it does.
>>
>> Overall, I am bit surprised that the bookmarks which are advertised as
>> local only entities (unless explicitly made remote) and as lightweight
>> branches similar to git work this way, out of the box.
>>
>> -Jaikiran
>>
>>
>>
> _______________________________________________
> Mercurial mailing list
> Mercurial at selenic.com
> http://selenic.com/mailman/listinfo/mercurial
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurial-scm.org/pipermail/mercurial/attachments/20150205/86c0280c/attachment-0002.html>