D3715: namespaces: allow namespaces whose symbols resolve to many nodes (API)
Sean Farley
sean at farley.io
Fri Jun 15 01:37:49 EDT 2018
--=-=-=
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:
> >
> > > durin42 (Augie Fackler) <phabricator at mercurial-scm.org> writes:
> > >
> > >> durin42 added subscribers: lothiraldan, smf, durin42.
> > >> durin42 accepted this revision as: durin42.
> > >> durin42 added a comment.
> > >>
> > >> I'm in favor, but feel like I've got enough conflict of interest I shouldn't land the patches.
> > >>
> > >> @smf @lothiraldan this might be of interest to both of you?
> > >
> > > Side note: I keep missing messages that I'm tagged in because I'm not
> > > explicitly mentioned in a CC field. Is it possible to add a CC to each
> > > person tagged in a message?
> > >
> > > Side note2: Phabricator emails are really non-trivial to parse and
> > > (worse!) search. The raw emails are not simple, raw text so I'm having
> > > trouble tagging these for higher priority.
> >
> > I think I got this ironed out now.
> >
> > > Thanks for alerting me of this series! I've had a discussion with Martin
> > > about this on IRC but I'm a bit out of time today to respond (but
> > > definitely do want to respond). (I'm going to try to spend some time in
> > > the mornings to do my email triaging so I can get back on top of this
> > > list.)
> >
> > 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.
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.
And yes, your patch only applies to topics. 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?
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?
Furthermore, what about the revset language? Should 'topic-foo' become
'topic(topic-foo)' in our AST? I was hoping the abstraction I made
between branches and topics was clear but I guess I am too terse
sometimes, so I apologize.
> > "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 D3715' to signify
that "I want all the commits of D3715" (e.g. --stack I think in
phabread).
And what about push? Should 'hg push -r D3715' push those other diffs as
well? I know it sounds silly but that's what being an AST means (at
least to me).
Hopefully this message was a bit more clear but if not, then I can try
to discuss in person if that's better.
--=-=-=
Content-Type: application/pgp-signature; name="signature.asc"
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCAAdFiEEXQX2nmDejz5RkkDD/9jcOZ+fO9YFAlsjUK4ACgkQ/9jcOZ+f
O9ZoZA//f5RD6iA9HnwYhXdt126V1cB5xmgkGaZoDNY54B+hkrmeBQ+/6w1PfQij
pSZToUwhANrrh3L4vnwQOL3al6HII+sftTSmd+sh8/ch1r59+L0f7RYSEPXqapuI
nEE8otm8V18KKvHu48smOl69EoB3UDASX3C2b7E27VF0hJQjPOZV8ai9KOhRZpti
5Tftwhkh7PKdyOdk7JzNkNKZKcfQO1294YIpOFtuhrXa0GH5GPfbVXDT5gIcsIX2
vT9uZ9UWSpQANT7UfIoCh0nMH90uLnG4Jb68Q6nL8F6ZPnmmDn7dO6LV5SdtZUe3
svNBqPU5lSvZKokBpRdhqjYoxCtZ1KBFSGHO/N5km44HckshpS2FhyiXpNJrSxK/
K6lAc0VKTFmj5WwL1VYQiv5pr2GMPppRi5TSkVlsXtDio79qKd31ER9Nkc/ZibEF
A+wn6hLjtgPZAl9BCvGNSAciOPlfC4C3BJ2k7BGcqMGxYir0Kyp1+sl7R68dZ5sm
DEPLLlCmKuuHCOQ+NgEmsavLpEvTO/uypCW3cOBNy8FfLxgLvJZkeXG0daHJJkA1
Jb4dNiNXXPo6c/EL+xpCIUgKJdPmGab/qs7z9WlyZhUUmzpcZgzPFuCImnebgeUW
ABUAk9yBB/thUrunM9QmMKu2QZ8ggUoPInlt5blMbRPUxeMPbJs=
=O0Nu
-----END PGP SIGNATURE-----
--=-=-=--
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://www.mercurial-scm.org/pipermail/mercurial-devel/attachments/20180614/eaae2300/attachment.sig>
More information about the Mercurial-devel
mailing list