[PATCH 0 of 2 RFC] forward current bookmark on hg update

[Kevin Bullock]

On Apr 20, 2011, at 11:29 AM, Idan K wrote:

> On Wed, Apr 20, 2011 at 6:11 PM, Benoit Boissinot <bboissin at gmail.com> wrote:
> FYI, personally I prefer having bookmarks move on
> pull/unbundle/commit. Idan why do you find it unintuitive?
> 
> I actually didn't know pull will move the current bookmark, just noticed that 
> after you mentioned it. FWIW I'm not entirely sure I would expect it to.

It's somewhat surprising because of the fact that bookmarks didn't used to be shareable at all—but of course that's changed.

> If I'm working on something using a bookmark and I incidentally decide to pull,
> that doesn't mean my next step would be a 'hg update' (or merge for that matter).
> So if I continue working without a hg update, I basically need to 'hg bookmark -f...' to
> get it back.
> I would expect it to move when (if) I actually decide to update my working copy to what I just pulled.

If I'm working on a branch that's bookmarked (we'll call it 'feature'), and someone else has newer work on that branch, it makes sense to update the (shared) bookmark on pull.

If I want to track my own (possibly divergent) development on that branch, the current solution would be to create a second bookmark called, say, 'kbullock/feature', and keep that bookmark local (or, push it if someone else wants to track my development).

> Also, I may be thinking ahead here but if we ever introduce bookmark namespaces
> (per entry in paths for example), the way I see things the consequence of a pull would be to move
> the remote bookmark rather than the local one (much like git does for that matter).
> Only if I follow up with a 'hg upd/merge remote/bookmark-name', the local bookmark should be moved.

I'm not keen on on having `update` move bookmarks. So I'm -1 on this series. As Alexander pointed out, `update` should be a working-dir-only operation (debate on the current functioning wrt subrepos notwithstanding).

Giving `merge` the ability to do so, OTOH, makes sense to me, even in the trivial 'merge'-with-descendent case (which Git calls a fast-forward merge).

pacem in terris / mir / shanti / salaam / heiwa
Kevin R. Bullock

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20110420/c469ec43/attachment.htm>