Proposed bookmarks plan posted to wiki

[Kevin Bullock]

On Jun 13, 2012, at 9:49 AM, Augie Fackler wrote:

> 
> 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

Yeah, that seems like a sensible option too. I've updated the wiki page.

>> 
>>> * 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?

Yes. It's the distinction between using bookmarks as a replacement for localtags vs. using them as shared markers on heads à la Git. What I should have said there is "The above proposed behavior is a compromise between" &c.

pacem in terris / мир / शान्ति / ‎‫سَلاَم‬ / 平和
Kevin R. Bullock

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20120613/03eb728e/attachment.html>