[PATCH 2 of 2] bookmarks: on a bare merge use config to choose target or choose @

[Matt Mackall]

On Fri, 2014-03-21 at 14:29 +1100, Stephen Lee wrote:
> On Wed, Mar 19, 2014 at 1:05 AM, Jordi Gutiérrez Hermoso
> <jordigh at octave.org> wrote:
> > On Wed, 2014-03-12 at 20:27 +1100, Stephen Lee wrote:
> >
> >> In a non-bookmark workflow, the new logic only triggers if you have an
> >> active bookmark and an @ bookmark (which should be rare in a
> >> non-bookmark workflow).
> >
> > It seems to me that you're failing to account the situation of both
> > bookmarks and named branches being used intentionally, which is a
> > common thing to do with Mercurial (named branches aren't anathema).
> > When on a named branch, `hg update` keeps you on that branch and moves
> > you to it head, if unique. I think this is what mpm is complaining
> > about, what if you're on the stable named branch with no active
> > bookmark?
> 
> As I said before if you have no active bookmark, there is no behaviour
> change - you will end up on the tip of the current branch.
> If you are using bookmarks with branches then that usually makes no
> sense - which branch head is the 'real' head and which are feature
> heads? The 'real' head is often not even at a branch head!
> 
> Also note that if the destination selected by the new logic is not a
> descendent, then update will abort anyway.
> 
> My patch currently requires bookmarks on a non-default branch to
> explicitly name the bookmark they want to track.
> By convention the @ bookmark is usually on default, so for other
> branches you would need a different bookmark for the 'real' head
> ("<branch name>@" has been suggested in the past).
> I can incorporate that behaviour into the patch(es).
> 
> I know named branches are not anathema. The workflow I advocated at my
> work uses named branches for release branches and bookmarks for
> feature branches.
> I'm trying to improve bookmarks in general - with or without named branches.

Sadly, this is all too complicated to discuss in this format because
there are too many cases and it's not clear that we're covering them
all. We really need to move this discussion into some summary table that
covers all the possible cases and shows both the old and new behavior.

I'm also wary of assigning any semantics to '@' beyond 'this is the
default checkout on clone if it exists'.

-- 
Mathematics is the supreme nostalgia of our time.