Some thoughts about Mercurial bookmarks

[Sean Farley]

David Demelier <demelier.david at gmail.com> writes:

> Hello,
>
> When I started to work with other people, I've searched for several 
> workflows that could be nice to use.
>
> I know a little bit how Git works and wanted to do the same with 
> Mercurial. I heard of bookmarks and since they are popular and the 
> recommended way, I've tried to use it for several weeks.
>
> But I've encountered several issues that I personally think inconvenient:
>
> 1. Bookmarks are not deleted upon a pull

At the last sprint, we agreed to bring some remote bookmark
functionality into core. This should be able to help propagate bookmark
deletion and divergence improvement.

> 2. Calling hg update moves the bookmark automatically

This is just broken. Ryan will hopefully come through with the patches
to change that :-)

> 3. Rebase extension does not move bookmarks
>
> When using Git, creating a branch is like creating a bookmark, it does 
> not create new heads. Thus, when you're done with your work, you can 
> just do git rebase and all of the code is merged.
>
> By contrast, Mercurial will only allow rebasing if the bookmark revision 
> is actually in a different head, that means you have to check manually 
> the tree for what action you must do, either rebasing or moving yourself 
> the bookmark where you want.
>
> I suggest that hg rebase could simply move the bookmark from the source 
> to the destination if they are in the same head and to a real rebase 
> instead.

I think I see what you're trying to say here. Once 'hg update' changes
behavior, I think we can look at other commands that move bookmarks. For
this particular issue, I think I can implement it in the 'remote names'
to get a feel for the workflow.

Off the top of my head, I wouldn't know how to differentiate between
wanting to rebase a bookmark on top of another bookmark vs. advancing
the other bookmark after the rebase is done. Maybe a flag to rebase?