martinvonz (Martin von Zweigbergk) <phabrica...@mercurial-scm.org> writes:
> martinvonz added a comment. > > > In https://phab.mercurial-scm.org/D3715#58729, @smf wrote: > > > --=-=-= > > Content-Type: text/plain > > > > martinvonz (Martin von Zweigbergk) <phabrica...@mercurial-scm.org> writes: > > > > > martinvonz added a comment. > > > > > > In https://phab.mercurial-scm.org/D3715#58720, @smf wrote: > > > > > > > Sean Farley <s...@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. It's not that this is a user-visible change, it's that we're opening the floodgates to confusing users. You haven't really addressed my questions about -r branch and -r topic/google/whatever in the sense that you haven't addressed the cognitive overload of a user. My point is that this is dangerous and more harmful to users than the benefits.
signature.asc
Description: PGP signature
_______________________________________________ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
