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

[Augie Fackler]

On Wed, May 31, 2017 at 10:49:09AM -0700, David Soria Parra wrote:
> On Wed, May 31, 2017 at 10:34:55AM -0700, Sean Farley wrote:
> > David Soria Parra <dsp at experimentalworks.net> writes:
> >
> > > On Wed, May 31, 2017 at 10:50:15PM +0900, Yuya Nishihara wrote:
> > >> On Mon, 29 May 2017 23:28:20 +0900, Yuya Nishihara wrote:
> > >> > On Mon, 29 May 2017 14:45:39 +0200, Denis Laxalde wrote:
> > >> >
> > >> > I agree it's a bit puzzling, but I also think it's an acceptable extension to
> > >> > the `~` operator as long as descendants history is linear. However, from
> > >> > implementation POV, it would be unnecessarily expensive to make sure there's
> > >> > no more than one child.
> > >>
> > >> So I'm against the current proposal. FWIW, if we can define the first
> > >> descendant as the nearest child in revision number space, the computation
> > >> will be cheaper.
> > >
> > > I considered this and decided to not introduce this notion of nearest
> > > child. I feel that the notion of revnumber as an ordering is unintuitive for
> > > users of a decentralized version control system as it adds an concept of
> > > ordering on the existing dag,
> >
> > But this is what Mercurial has always done.
>
> I think we have always used it as an optional method rather than a way to
> disambiguate.
>
> > > and rev numbers are rarely used by users for
> > > ordering (hence people use :: far more than : in revsets).
> >
> > I don't think that's sound reasoning. As a counter argument, Bitbucket
> > manually sorts each git repo so that it has a faux rev number. We then
> > use that number for children / descendant calculations.
> >
> > > I feel while the
> > > computation is faster it might often lead to unexpected results. The user must
> > > know the revision numbers of children in order to know what 'hg update .~-2'
> > > would do. That's why I felt restricting it the way i did in the patch was more
> > > sensibile for userbility.
> >
> > I'm unsure. On one hand, I'd like to get something through. But on the
> > other, we have years of precedence of using rev numbers.
>
> I don't mind changing the proposal if we agree. I prefer having something in and
> don't feel too strongly about my current approach, although i think it's much
> more user friendly than relying on revnumbers.

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.)

> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel at mercurial-scm.org
> https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel