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

[Angel Ezquerra]

El 06/02/2015 08:56, "Jaikiran Pai" <jai.forums2013 at gmail.com> escribió:
>
> 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

A couple of comments:

- It seems to me that all your problems would be fixed by simply using a
GUI such as TortoiseHg:
    - It lets you change the default push behavior from "push all" to "push
the current anonymous branch" our even "push up to the current revision"
    - It's "outgoing" button lets you view what will be pushed and then
right click on the revision that you want to push.

- There is nothing non lightweight about bookmark based mercurial
"branches". They are just as lightweight as git's. The fact that they are
pushed by default does not make then any less lightweight. In fact
mercurial can create branches that are lighter weight than git's. These are
called anonymous branches. To create them just update to any revision and
create a new commit. There is no need to create a bookmark or named branch
first.

Cheers,

Angel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurial-scm.org/pipermail/mercurial/attachments/20150206/4d3e15ae/attachment-0002.html>