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

[Matt Mackall]

On Fri, 2011-03-25 at 16:32 +0100, Martin Geisler 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.

*facepalm*

You can't be serious. 

    ... o --- o --- M
          \       /
           o --- o
                 X

becomes

                 X
           o --- o
          /       \
    ... o --- o --- M


Now, given that these graphs are identical, except that X now comes in
from the top rather than the bottom in M (ie p1 and p2 are swapped),
explain why the behavior of the merge at M should be different in these
mirror images. In other words, why should symmetry be broken?

-- 
Mathematics is the supreme nostalgia of our time.