Why Does Update with No Args Move Bookmark?

[Martin Geisler]

Stephen Lee <sphen.lee at gmail.com> writes:

> On Thu, Oct 10, 2013 at 12:00 PM, Jensen, Aaron <ajensen at webmd.net> wrote:
>>
>> Why does `hg update` without arguments move a bookmark [1]? It seems
>> like this could cause unintentional problems if someone does work on
>> a bookmark, and un-mindfully runs `hg up`. This feels like a bug.
>
> The short answer is that it simplifies the common scenario where you
> pull changes from some public server, and you have not made any
> commits of your own. "hg up" moves you to the tip of the current
> branch and drags the bookmark with it so you are ready to start
> working.

That scenario is actually not common in my experience.

> If you had made your own commits then "hg up" complains that the
> update will cross a branch and fails (suggesting you merge). This is
> the fail-safe that prevents you from accidentally moving the bookmark
> when you didn't want to.

I've found that this didn't work very well in practice. We tried to use
bookmarks for a couple of weeks and abandoned them again.

We agreed to let the '@' bookmark show the last reviewed commit on
default, with the idea that we would advance '@' when a reviewed branch
was merged into default.

Despite our best efforts, we found that '@' got out of sync on a daily
basis, e.g., people forgot to update it when pushing to the main server
or it got updated by mistake.

We've now mostly dropped the idea of using bookmarks for anything but
local markers (but even there I find it easier to just look at the graph
in TortoiseHg and update to the head I want).

A particularly annoying feature of bookmarks is that they spread like
crazy and that they display themselves prominently in various lists
(such as 'hg bookmarks', dropdowns at Bitbucket, etc). It's backward
that this should be a mis-feature, but that's how it felt to me and my
team when we suddenly had 30+ bookmarks in our repos.

It's not that we worked on 30+ features simultaniously (we're just six)
but the problem is that deleting bookmarks is hard by design: even when
I delete the bookmark locally and on the server, it doesn't help the
rest of the team if they've already pulled it.

Git helps here by not showing all branches all the time. If I push a
branch to the central server, the rest of the team will get it when they
pull, but the branch lives in the origin/ namespace. It is only branches
that I've checked out explicitly that I see when I run 'git branch'. So
tons of branches can come and go in the main repository without
bothering me.

I've only played a little with Git, but a similar mechanism might be key
to make bookmarks more managable in Mercurial.

-- 
Martin Geisler
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <http://lists.mercurial-scm.org/pipermail/mercurial/attachments/20131010/1c976947/attachment.asc>