atom feed7 messages in com.selenic.mercurial-develBookmarks: don't push local bookmark ...
FromSent OnAttachments
Matt MackallJun 2, 2012 2:16 pm 
Levi BardJun 3, 2012 3:30 am 
Matt MackallJun 3, 2012 5:37 pm 
Augie FacklerJun 4, 2012 6:46 am 
Bryan O'SullivanJun 4, 2012 10:10 am 
Pierre-Yves DavidJun 8, 2012 8:05 am 
Kevin BullockJun 8, 2012 9:15 am 
Subject:Bookmarks: don't push local bookmark heads by default?
From:Matt Mackall (
Date:Jun 2, 2012 2:16:06 pm

Right now when we push, we push all heads. But we don't automatically propagate bookmarks so that users can keep a local namespace.

In some cases, this is fine. If Alice creates a new head on a branch and puts a bookmark on it, push will refuse to push it without -f and she can then push just the head she wants.

But if Alice instead creates a bookmark and makes several commits on the tip of default, then pushes, the remote server will now have Alice's bookmarked commits on default and people will automatically update to those commits. Which means it's not making it very easy for Alice to make a "local branch".

(Closely related is case 3 here: )

One possibility is that when an outgoing head has a bookmark that's local-only, we treat the commits as local-only as well and refrain from pushing it. This lets Alice make a private bookmark branch without needing to worry about it getting pushed by accident.


- no more need for manually specifying heads to push - no misguided push -f catastrophes


- significant change that might surprise people (though not ruled out insofar as the current behavior could be considered buggy) - might quietly prevent some who has a local bookmark on their named branch head today for some reason from pushing (more worrisome) - bookmarks only mark one end of a line of development, so if Alice makes a "real" commit followed by two bookmarked ones, the real one will be hidden from push - some overlap with secret phases functionality

Another alternative, pushing "local" bookmarks always, is probably off the table as it means anyone who is depending on having a private namespace today gets a nasty surprise on upgrade.