[PATCH 0 of 6] improve help and hints, then add 'update --bookmark'

[Kevin Bullock]

On Dec 7, 2011, at 2:30 PM, Idan Kamara wrote:

> On Wed, Dec 7, 2011 at 10:01 PM, Kevin Bullock <kbullock+mercurial at ringworld.org> wrote:
> On Dec 7, 2011, at 12:32 PM, Idan Kamara wrote:
> 
> > Why would you not want to move the *active* bookmark when updating to a
> > descendant? When opening issue2894 this is the behavior I expected, others
> > disagreed but I didn't understand the use cases in which this is undesired.
> 
> 
> The use case is using bookmarks as a replacement for localtags (and Matt has explicitly stated he considers localtags deprecated in favor of bookmarks). Example:
> 
> Alice has done a major experimental refactoring and wants Bob to review it. She bookmarks the last non-experimental revision as 'last-stable', and the head as 'experimental'. Bob clones (with bookmarks) and updates to 'last-stable' to inspect it. He then runs `hg update` to inspect the head of Alice's work.
> 
> On no account should the 'last-stable' bookmark move in this case.
> 
> Well, one might argue that if the user has no intention of moving a bookmark, it shouldn't be active.

If that's the case, then maybe updating explicitly to a bookmark shouldn't make it active? Then we wouldn't need this flag.

> But I can now see that this might be surprising to some, so a flag might be the lesser evil of the two.
> I just hope we don't end up with too many bookmark-centric flags on the various commands, so using them will also feel lightweight...


I think this and the issue of divergent bookmarks (which Matt is actively working on) are the last two remaining issues that should make bookmarks really usable for (Git-style) feature branching. So I don't hold much fear that other commands will grow a --bookmark flag.

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurial-scm.org/pipermail/mercurial-devel/attachments/20111207/e1d2ca51/attachment-0002.html>