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

[Oben Sonne]

On Fri, Mar 25, 2011 at 11:08 PM, Kevin Bullock
<kbullock+mercurial at ringworld.org> wrote:
> 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

Do we have a consensus here? Except the theoretical symmetry issue
mentioned by Matt, opinions in this thread in an issue 1877 favor to
_not_ merge in bookmarks. If these arguments aren't sufficient or if
there are reasonable use cases where merged bookmarks are preferable,
we could still add an option do control the merge behavior.

Anyway, if this is going to be accepted, we probably should use the
patch posted by dsp some days ago [1], though he also adds a complete
new test case.

[1]: http://www.selenic.com/pipermail/mercurial-devel/2011-March/028990.html

Oben