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

[Sean Farley]

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.

> 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.
-------------- 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/20170531/6bad597c/attachment.sig>