[PATCH] bookmarks: do not move merged bookmarks (issue1877)

[Kevin Bullock]

On 25 Mar 2011, at 10:12 AM, Matt Mackall wrote:

> On Fri, 2011-03-25 at 16:05 +0100, Martin Geisler wrote:
>> Matt Mackall <mpm at selenic.com> writes:
>> 
>>> I'm not entirely sure if this is the right behavior. Merges are
>>> generally symmetric. Currently the only exception to this is branch
>>> names, and perhaps this is similar enough to that case that it makes
>>> sense, but I'd like to see an actual argument for it.
>> 
>> One argument could be that leaving the bookmark in place makes pulling
>> bookmarks easier in the future. That is, when I pull in a branch with
>> bookmark X from you and merge it into my own line of development, then I
>> end up with
>> 
>>   ... o --- o --- M
>>          \       /
>>           o --- o
>>                 X
>> 
>> Some time later I pull from you and pull your new X bookmark:
>> 
>>   ... o --- o --- M
>>          \       /
>>           o --- o --- o --- o
>>                             X
>> 
>> If the X bookmark had moved to M when I merged, then I believe the
>> bookmark code would not let is jump back to your branch tip since the
>> tip is not a descendent of M.

This corresponds to the case of re-opening a merged line of development. It might be a place to allow a switch to forcibly pull a bookmark that does this.

> Yes, but what I'm looking for is an argument that explains why we should
> _break the symmetry_. In other words, I can turn your graphs
> upside-down, doesn't that tell us we should do the opposite of this
> patch?


+1 to the argument by analogy to named branches. If I'm on a feature branch, then I update to mainline and merge in the feature, it seems to make most sense to keep the bookmark on the now-'inactive' 'head' of the feature branch, until such time as I manually update or remove the bookmark.

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