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

Matt Mackall mpm at selenic.com
Wed Mar 30 13:27:57 CDT 2011


On Mon, 2011-03-28 at 12:30 +0200, Oben Sonne wrote:
> 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

I've gone ahead and queued this.

-- 
Mathematics is the supreme nostalgia of our time.




More information about the Mercurial-devel mailing list