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

[Yuya Nishihara]

On Mon, 29 May 2017 14:45:39 +0200, Denis Laxalde wrote:
> David Soria Parra a écrit :
> > # HG changeset patch
> > # User David Soria Parra <davidsp at fb.com>
> > # Date 1495905909 25200
> > #      Sat May 27 10:25:09 2017 -0700
> > # Node ID 47c710c797624b6d5c84c493a873ea8beb563a74
> > # Parent  b647b923486f38d83b92089eafa9faafaa79785d
> > revset: lookup descendents for negative arguments to ancestor operator
> >
> > Negative offsets to the `~` operator now search for descendents. The search is
> > aborted when a node has more than one child as we do not have a definition for
> > 'nth child'. Optionally we can introduce such a notion and take the nth child
> > ordered by rev number.
> 
> My first though is that using a minus sign to move forward in history is
> also a bit puzzling...

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.

> > The current revset language does provides a short operator for ancestor lookup
> > but not for descendents. This gives user a simple revset to move to the previous
> > changeset, e.g. `hg up '.~1'` but not to the 'next' changeset. With this change
> > userse can now use `.~-1` as a shortcut to move to the next changeset.
> > This fits better into allowing users to specify revisions via revsets and
> > avoiding the need for special `hg next` and `hg prev` operations.
> 
> The :: operator comes to mind when one mentions "descendants", except
> that it does not only yield descendants only but also the source
> revision. So one might use `hg up 'limit(.::, 2)'` instead of `hg next`.
> With a revsetalias "next=limit(.::, 2)", it's quite handy I think. It's
> missing the abort in case of ambiguous destination / multiple children.
> On the other hand, while I think aborting makes sense when used with `hg
> update`, for log-like commands, I'm not sure it's very useful over .::,
> especially with graph-log output. (Also `hg up '.~1'` will not abort if
> . is a merge changeset with ambiguous destination; so this will not be
> symmetrical with `hg up '.~-1'`.)
> 
> > The alternative to negative offsets is adding a new operator. We do not have
> > many operators in ascii left that do not require bash escaping (',', '_', and
> > '/' come to mind). If we decide that we should add a more convenient short
> > operator such as ('/', e.g. './1') we can later add it and allow ascendents
> > lookup via negative numbers.

These characters can't be used. '_' and '/' are taken as symbols, and ','
would complicate the language.