[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