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

Kevin Bullock kbullock+mercurial at ringworld.org
Wed Apr 20 16:58:52 CDT 2011


On Apr 20, 2011, at 3:41 PM, Matt Mackall wrote:

> If the remote repo has a bookmark X that is a descendant of your local
> bookmark X, then X -is not your bookmark- (as evidenced by the fact that
> someone else has moved it and you haven't). In this case, Mercurial is
> right to move X on pull.

Right. If a bookmark is shared, it indicates _our_ latest work on a particular line of development, not _my_ latest work.

> If remote bookmark X is an ancestor of your local X, then it is your
> bookmark and there's nothing to do anyway.
> 
> If local X and remote X are not linearly related, there's a conflict,
> and again Mercurial does nothing.
> 
> 
> I think the real issue is what happens when:
> 
> - you've got local bookmark X
> - you pull new changesets descended from X
> - remote has never heard of your bookmark.
> 
> Do we linearly advance the bookmark on pull or not?

Aha, now there's a useful distinction. I suspect the answer is no. But we would need to introduce a check for this case.

> ..and that, of course, has nothing to do with remote bookmarks, which
> are a red herring. Yes, having a remote namespace would be nice. No,
> it's (obviously) not mandatory - all you need to prove that is to
> observe that everyone agreeing on a <user>-<id> format for bookmark
> naming avoids collisions.

Exactly.

> Also, I think this is yet another case where arguing about individual
> behaviors in isolation is going to be unproductive. We need to make a
> table of all the bookmark advancement behaviors and make sure they're
> sensible and mutually consistent.


Here's an attempt at one that applies only to changeset-sharing commands:

                Advance local on pull/unbundle?         Advance remote on push?
remote only     [1]                                     [6]
local only      [2]                                     [7]
remote newer    [3]                                     [8]
local newer     [4]                                     [9]
unrelated       [5]                                     [10]

1. create with -B BOOKMARK
2. no? (the last case outlined above)
3. yes (first case above)
4. not needed (second case above)
5. no (third case above)
6. no? (almost certainly wrong to advance a remote bookmark we don't have locally)
7. create with -B BOOKMARK
8. not needed
9. yes
10. no

Note that 1 & 7, 2 & 6, 3 & 9, and 4 & 8 are pairs of inverses that should be consistent with each other. 5 & 10 should also behave consistently.

For commands like commit, qnew, qpush, etc., I think one rule applies: commands that create (or destroy) changesets locally should advance (move back) the current bookmark. But I'm not claiming any authority on that, nor do I know what the current behavior actually is for sure.

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



More information about the Mercurial-devel mailing list