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

Kevin Bullock kbullock+mercurial at ringworld.org
Thu Apr 21 11:55:52 CDT 2011


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

> On Wed, 2011-04-20 at 16:58 -0500, Kevin Bullock wrote:
>> 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?
>> 
>> [...]
>>> 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:
>> 
>> [...]
> 
> Let me try a rewrite of that:
> 
>                move local on pull  move remote on push?
> remote only     N/A [1]             no? [2]
> local only      no? [2]             N/A [1]
> remote newer    yes [3]             no  [4]
> local newer     no  [4]             yes [3]
> unrelated       no  [5]             no  [5]
> 
> 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)

Yes, thanks, that's a much clearer version than the one I whipped up on my way out of my office last evening. :) The only small distinction to be made is that in [2] in the `pull` case, moving the bookmark is only probably wrong, while in [2] in the `push` case it's almost _certainly_ wrong.

>> 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.
> 
> Actually, I don't think we can infer that a command that destroys a
> bookmarked cset should move the cset back. If I qnew a patch to add a
> feature, bookmark it 'feature', then qpop it, I probably don't want the
> cset before it labeled as a feature.


Right, I remember having this discussion recently, which is why I didn't take a strong stance on it... was there ever a patch queued for this?

Not sure even how to create a table for this. Let me instead attempt a modification to my original rule: Commands that create changesets locally should _always_ advance the current bookmark; commands that _destroy_ changesets should move the bookmark back iff the bookmark was originally (or with -f) set on an ancestor of the bookmarked changeset being destroyed.

Come to think of it, that suggests a similar table to the above:

x       x       x       x       x       x       x       x
original is:    move back or drop?
ancestor        move
destroyed       drop
unrelated       drop?

Would tracking the _first_ revision a bookmark was set on (or the last it was set on with -f) be sufficient to implement the right behavior? The tracking probably needs to be in core so that MQ can share it with histedit, etc.

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



More information about the Mercurial-devel mailing list