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

Fri Jun 15 02:55:37 EDT 2018

martinvonz added a comment.

  In https://phab.mercurial-scm.org/D3715#58729, @smf wrote:

  > --=-=-=
  >  Content-Type: text/plain
  >
  > martinvonz (Martin von Zweigbergk) <phabricator at mercurial-scm.org> writes:
  >
  > > martinvonz added a comment.
  > > 
  > >   In https://phab.mercurial-scm.org/D3715#58720, @smf wrote:
  > >   
  > >   > Sean Farley <sean at farley.io> writes:
  > >   >
  > >   > 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.
  > >   
  > >   Unfortunately, I think much of your comments below were based on this incorrect assumption about what this patch does. I've read through it, but it doesn't seem very relevant.
  >
  > No, I understand what you're trying to do. I was attempting to paint a
  >  picture of what it looks like to me in the sense of "this works for one
  >  type of object but not this other one". Why? Why does it work for topics
  >  and not branches? As a user, and believe me I have years of experience
  >  with angry ones, they do not understand the nuanced differences between
  >  branches and topics. They just lump them all together.

  As I said in the commit message, I'm aware of this argument, I just disagree. I think most users have never even tried to do `hg log -r default` and that's the only shipped-with-core namespace that behaves funny (IMO).

  > Topics is going out of its way to pretend they are in the same namespace
  >  as branches (that's the motivation of my mini rant in my previous
  >  message). The difference between branches and topics is lost on everyone
  >  outside this thread. When I tried to introduce them onto Bitbucket I
  >  only got headaches: "can I merge between a topic and branch? can I merge
  >  between a topic on branch A and another topic on branch B? if so, what
  >  does that mean? Why is branch B still open? I merged one topic into
  >  another and it closed the three topics it was based on, why?"
  > 
  > It solidified my stance that there should only be one namespace for most
  >  users: branches.

  Sounds more like a criticism of topics.

  > And yes, your patch only applies to topics.

  *Maybe* to topics. That will be up to that extensions developers.

  > My point is the cognitive
  >  load. Why is it '-r topic-foo' for one and not '-r branch-bar' for the
  >  other? To the average hg user, both topics and branches are treated
  >  (semantically) the same. Why one and not the other?

  For historical reasons (`hg log -r branch-bar` is protected by BC). Again, I think few users have even tried that command. If they did, perhaps they did it hoping that it would list all the commits on the branch?

  > Let's say you and I say a repo. I add a branch (because that's the only
  >  thing I use) and you add a topic. Cool. Another dev comes along. 'hg log
  >  -r martins-work' lists all the commits of his feature work, but, 'hg log
  >  -r seans-work' only lists the tip-most commit of my feature work. Why?
  >  Why should that dev be tripped up by this?

  See my commit message.

  > Furthermore, what about the revset language? Should 'topic-foo' become
  >  'topic(topic-foo)' in our AST?

  No. The way I did it in this patch was to make the symbol "topic-foo" itself resolve to multiple revisions.

  > I was hoping the abstraction I made
  >  between branches and topics was clear but I guess I am too terse
  >  sometimes, so I apologize.

  I think I see the similarities between them (and I did before your message too :)).

  > 
  > 
  >>   > "But what about topics?" you ask. Well,
  >>   >  personally, I think that extension should add -t to log if it wants that
  >>   >  functionality (-t is available to both 'push' and 'log' for those
  >>   >  curious).
  >>   
  >>   This is closer to the actual point of this patch. As I tried to say in the commit message, this patch allows an extension to indicate that the name->nodes mapping it provides should present in the plain revset symbol. For example, if the topics extension opts in to this behavior, then `hg log -r my-topic` would start including all nodes in the topic. More important to me (I don't use topics) is that our Google-internal extension could opt in (it would kind of lets you do something like `hg log -r D3715` and get current and past versions of https://phab.mercurial-scm.org/D3715). Again, I don't intend to change how `hg log -r stable` behaves.
  > 
  > Right, but as I tried to explain in my previous email I believe your
  >  extension should add another custom flag of '--phab https://phab.mercurial-scm.org/D3715' to signify
  >  that "I want all the commits of https://phab.mercurial-scm.org/D3715" (e.g. --stack I think in
  >  phabread).

  Revsets were invented to prevent that kind of things, no? What if I want `hg log -r 'only(D3715,@)::'`? We obviously don't want a flag for that.

  > And what about push? Should 'hg push -r https://phab.mercurial-scm.org/D3715' push those other diffs as
  >  well?

  Yes. Of course, things like `hg co D3715` will still need to resolve the revset (which "https://phab.mercurial-scm.org/D3715" is, and which "default" also is) to a single node. No change there.

  > I know it sounds silly but that's what being an AST means (at
  >  least to me).

  I'm not sure what that means, but I hope my replies clarified anyway.

  > Hopefully this message was a bit more clear but if not, then I can try
  >  to discuss in person if that's better.

  Sure, let me know if my replied don't clarify enough.

  Again, there should be no user-visible change in this patch. We could safely queue this patch and then let the topics people and the Google people experiment with the feature (or not) and ask them later if it was helpful or harmful.

REPOSITORY
  rHG Mercurial

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

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