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

[Denis Laxalde]

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

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