D3715: namespaces: allow namespaces whose symbols resolve to many nodes (API)

[martinvonz (Martin von Zweigbergk)]

martinvonz added a comment.


  In https://phab.mercurial-scm.org/D3715#58736, @yuja wrote:
  
  > >   > This patch strikes me as a Seems-Like-A-Good-Idea-But-Could-Blowup type
  > >   >  of thing. So, what this patch does is conditionally change the behavior
  > >   >  of 'log -r' based on the type of object passed in.
  > >   
  > >   
  > >   No, it just allows namespaces to do that. As I said (or tried to say) in the commit message, `hg log -r stable` is protected by BC, so we can't change it. There should be no functional change from this patch.
  >
  > How about adding syntax to resolve multinode namespace symbols?
  >  `stable~`, for example, will be resolved to all revisions in the stable
  >  branch.
  
  
  I was also thinking we could do that, but it feels like a workaround to me. I think of bookmarks and tags as pointing to specific commits. I think of branches as being many commits. `hg help revisions` says this:
  
    Any other string is treated as a bookmark, tag, or branch name. A bookmark
    is a movable pointer to a revision. A tag is a permanent name associated
    with a revision. A branch name denotes the tipmost open branch head of
    that branch - or if they are all closed, the tipmost closed head of the
    branch. Bookmark, tag, and branch names must not contain the ":"
    character.
  
  It specifically mentions bookmarks, tags, and branches, and it describes how each name resolves to a commit. To me, that makes it sound like some symbols can resolve to multiple commits. And indeed, revset aliases can already resolve to multiple commits.
  
  Also, the namespace mechanism allows `namemap()` to return a collection of nodes. That also suggests to me (as a developer now, not a user) that a namespace name is supposed to be able to resolve to multiple nodes.
  
  I don't mind trying to figure out a cleaner implementation (I agree that this is a little ugly), but I don't want a clean implementation to be the reason we choose one UX or another.

REPOSITORY
  rHG Mercurial

REVISION DETAIL
  https://phab.mercurial-scm.org/D3715

To: martinvonz, #hg-reviewers, durin42
Cc: yuja, durin42, smf, lothiraldan, mercurial-devel