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

Oben Sonne obensonne at googlemail.com
Fri Mar 25 16:01:06 UTC 2011


On Fri, Mar 25, 2011 at 4:32 PM, Martin Geisler <mg at aragost.com> wrote:
> Matt Mackall <mpm at selenic.com> writes:
>
>> On Fri, 2011-03-25 at 16:05 +0100, Martin Geisler wrote:
>>> Matt Mackall <mpm at selenic.com> writes:
>>>
>>> > On Fri, 2011-03-25 at 14:36 +0100, Oben Sonne wrote:
>>> >> # HG changeset patch
>>> >> # User Oben Sonne <obensonne at googlemail.com>
>>> >> # Date 1301058026 -3600
>>> >> # Branch stable
>>> >> # Node ID 4e046b57caf4f2e282bddbb93c7e192ae00788ba
>>> >> # Parent  913c2c66a555934cab9bcdac3412703256f9cdf2
>>> >> bookmarks: do not move merged bookmarks (issue1877)
>>> >
>>> > An excellent first patch submission. But we generally try to avoid
>>> > adding a whole new test script to add a simple test. If every
>>> > bugfix needed to create its own trivial repo to run its test on,
>>> > the test suite would take an hour to to run. Instead, try to find
>>> > somewhere else in the bookmark tests that is already creating a
>>> > repo with branches and test merging those.
>>> >
>>> > 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.
>>
>> 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?
>
> Hmm... I'm not sure how you can turn my graphs upside-down. This use
> case is one example of how breaking the symmetri is helpful, that's all.
>
> If the merge between M and X is to be symmetric and we start with
>
>              M
>    ... o --- o
>         \
>          o --- o
>                X
>
> then we can either move both bookmarks or none of them. Moving both
> breaks the use case above since your X will no longer be a descendent of
> my X.
>
> Moving none of them feels odd since your current bookmark stops being
> current after commit.
>
>
> --
> Martin Geisler
>
> aragost Trifork
> Professional Mercurial support
> http://aragost.com/en/services/mercurial/blog/
>

It looks like I've not thoroughly checked previous patch submission,
i.e. apparently a similar patch already has been posted by dsp:
http://www.selenic.com/pipermail/mercurial-devel/2011-March/028990.html
.. sorry for the noise.

Nevertheless, to provide an argument for the proposed change:
bookmarks often are used as lightweight respectively temporary branch
names and in that they should have the same asymmetry as persistent
branch names.

Oben



More information about the Mercurial-devel mailing list