Proposed bookmarks plan posted to wiki

Augie Fackler raf at durin42.com
Wed Jun 13 09:49:55 CDT 2012


On Jun 11, 2012, at 6:37 PM, Matt Mackall wrote:

> On Fri, 2012-06-08 at 14:42 -0500, Kevin Bullock wrote:
>> === push ===
>> 
>> * `hg push -r BOOKMARK` should automatically sync the bookmark too, without having to specify `-B`.
> 
> Not clear. Pierre-Yves seems to have a use case where maybe he wouldn't
> desire that.

I do as well (I use a 'queued' bookmark to contain things that I push, but never want to push the 'queued' mark itself.)

> 
>> Discussion: It should be possible to push a bookmark and all the
>> changesets leading up to it in one command. Right now, `hg push -B
>> BOOKMARK` pushes _all changesets_, and then the given bookmark, which
>> is too much.
> 
> That -B behavior sounds like a bug, and doesn't align well with the docs
> at all. Really sounds like it ought to do what you're proposing for -r.

+1

> 
>> * Warn (with hint) when pushing changesets that are bookmarked without pushing the bookmarks (suggested by [[marmoute]]: http://markmail.org/message/pxemyessq6ek7ynw).
> 
> I don't think a warning is sufficient. Given our non-existent support
> for unpushing, this warning will usually translate as "you idiot, you
> just pushed the code you were trying to keep local".
> 
> Sometimes our "no new heads" restriction will prevent this class of
> accident, but I think we should aim to do it more generally.
> 
>> This is a compromise between local-only bookmarks and topic-branch
>> bookmarks.
> 
> Not sure what the distinction you're drawing here is.

I think he means my 'queued' bookmark (which is just a pointer to where I want to be applying patches from others vs bookmarks you would share for feature work in a non-email-based workflow. Is that accurate Kevin?

> 
> -- 
> Mathematics is the supreme nostalgia of our time.
> 
> 
> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel at selenic.com
> http://selenic.com/mailman/listinfo/mercurial-devel



More information about the Mercurial-devel mailing list