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

[Sean Farley]

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?).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 800 bytes
Desc: not available
URL: <http://www.mercurial-scm.org/pipermail/mercurial-devel/attachments/20170611/daf3fa8e/attachment.sig>