RFC: revset relation operator

[Sean Farley]

Ryan McElroy <rm at fb.com> writes:

> On 10/12/2015 2:26 PM, Matt Mackall wrote:
>> On Mon, 2015-10-12 at 10:07 -0400, Augie Fackler wrote:
>>> On Sun, Oct 11, 2015 at 05:45:24PM -0500, Matt Mackall wrote:
>>> I think the specific feedback I'm looking for here is how do folks 
>>> feel about: - using {} for the operator
>
> I think this is the best choice

Agreed.

>> - allowing empty {} to be children()
>
> I don't like the implicit syntax for children or other cases. Mercurial 
> get's it right, in my opinion, that rev~ is a syntax error (git says 
> this is equivalent to rev~1, which is surprising behavior to me). It's 
> hard to get implicit behavior right, so I'd suggest starting with 
> explicit behavior (ie, no implicit 1 in {}) and then moving towards 
> implicit only as it becomes super clear what the right path is (if that 
> ever happens). If we start out with the wrong implicit behavior, we'll 
> end up with the equivalent of `hg update` semantics.

Totally agree.

> However, a short form for children seems really important to me as well. 
> Things I've considered over the last year:
>
> foo{   # the opening curly brace looks like dag children coming out of 
> foo. But there are obvious parsing problems here.
> foo*  # the idea being that it's things "pointing" at foo (and it's one 
> character), with the obvious glob downside
> foo;   # parent's ^ points up, the semicolon kind of points down. Again, 
> terminal escpaing implications
> foo/   # kind of implies things descending from foo in the subdirectory 
> sense. One downside is that forwardslash is used in bookmarks often (but 
> so it - and we've been able to handle that, albeit imperfectly).
>
> Of these, I like the last, the forward slash, the best. But this maybe 
> should be a separate discussion.
>
>> - allowing bare "-" with no numeral
>
> Also dislike, same reason as above. It's not clear to me that this is 
> "right" and so I think we should avoid it until it's clear.

Also agree.

> Ah... ancestors and descendants... I think we already dedicate :: (as 
> well as ..) to the ancestor/descendent use cases, and a new syntax is 
> confusing and unnecessary. Also, star just doesn't feel like a character 
> we should introduce if it doesn't fit really well because it has so many 
> other well-understood semantics in the world (globs, regexes)
>
> However, the inclusive vs exclusive idea I feel *is* important and we 
> should figure out how to have exclusive versions of ::. I think that can 
> be a separate discussion, but since we're kinda bike-shedding anyway, 
> I'll throw this into the ring:
>
> (1) We may need only one "direction" of exclusivity because the parent 
> revset or children revset can provide the "other way".
> (2) Since a parent revset is more firmly established, I'd suggest that 
> exclusivity be established in the direction of "exclude the beginning rev"
> (3) As a concrete proposal, triple colon could be "exclude the starting rev:
>
> (A:::B) == (A::B - A)
>
> If you need A::B -B, it's easy enough to write A::B^ today anyway, so an 
> exclusive operator in that "direction" is less useful in my opinion.

Minor nit: that only works when B isn't merge (which might require
A::B^2).