[PATCH RFC] revset: lookup descendents for negative arguments to ancestor operator

Yuya Nishihara yuya at tcha.org
Mon Jun 12 10:04:25 EDT 2017


On Sun, 11 Jun 2017 12:36:51 -0700, Sean Farley wrote:
> Augie Fackler <raf at durin42.com> writes:
> 
> > On Tue, Jun 06, 2017 at 09:27:54PM +0900, Yuya Nishihara wrote:
> >> On Mon, 05 Jun 2017 11:55:21 -0700, Sean Farley wrote:
> >> > David Soria Parra <dsp at experimentalworks.net> writes:
> >> >
> >> > > On Wed, May 31, 2017 at 02:17:58PM -0400, Augie Fackler wrote:
> >> > >>
> >> > >> It's easy to allow child traversal only if it's unambigious, and come
> >> > >> back to it later and be more permissive later. It'll be hard to go the
> >> > >> other way though.
> >> > >>
> >> > >> (I'm lightly in favor of this series, +0-ish, but I need to re-read
> >> > >> mpm's operator plan and see how they overlap, it's been too long.)
> >> > >>
> >> > >
> >> > > What's the conclusion on the RFC patch? Is that something we want with the
> >> > > current restrictions? Of other people like greg, sid, etc need to weight in?
> >> >
> >> > I agree with Augie's error-now-easier-permissive-later argument, for
> >> > what it's worth. I can change my vote to a +0 as well.
> >>
> >> I don't strongly disagree with that. If people like it, please feel free to
> >> move forward. FWIW, calling children() repeatedly wouldn't be the best way
> >> to scan descendant revisions.
> >
> > In the name of not letting the perfect be the enemy of the good, I'm
> > moving forward and queueing this patch, on the following logic:
> >
> >  * This syntax doesn't seem like it would ever make sense for anything else
> >  * mpm's revset operator plan, while pretty well liked by everyone, is big
> >    enough I'm skeptical it'll get picked up in the near term by anyone
> 
> Could we maybe pick apart some of his proposal into smaller bites? For
> instance, the '{ }' operators might be doable in the shorter term
> (perhaps for subscripting?).

Sounds good. '{' n '}' operator should be easily implemented as long as n is
a plain int or symbol. I suggest keeping this feature experimental for a
couple of months so we can choose the best shorthand notation.


More information about the Mercurial-devel mailing list