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

[David Soria Parra]

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.