[RFC] revision sets

[Dirkjan Ochtman]

On Tue, Apr 20, 2010 at 23:08, Greg Ward <greg-hg at gerg.ca> wrote:
> Responding to Dirkjan's comments:
>> 1. Lose "and" as a separator, use ',' or '&'
>
> Sure, but you also have to support "|" for "or".  IMHO this is
> screaming out for full boolean logic with nesting.

Sure, I wasn't debating that. I just think & and | would make nice
additions/replacements for and an or. In code I've grown to like
and/or, but in command-lines, which have much less re-use (and
complexity), I think the density is nicer.

>> 2. Allow non-ambiguous abbreviations like we do everywhere else
>
> Should be doable if everything is a keyword in this mini-language.
> But if predicates can be added dynamically (by an extension, say),
> then it might get tricky.

Even if they are, there'll probably be a central dict (like for
commands) where they have to jack in. Let's not assume that extensions
will actually extend the grammar...

>> 3. Optional parens if unambiguous
>
> Yuck.  Keep it simple and consistent -- keep the parens.

Okay, I'll concede that point.

>> Also, this proposal might perhaps benefit from a small list of use cases.
>
> How about, "anything I can do with git-rev-parse I should be able to
> do with hg". ;-)
>
> (Yeah, I know, that's a requirement not a use case.  Sue me.)

Well, I don't know what git-rev-parse can do. But I think it'd be nice
to have five examples of common things that we want to make much
easier than we have now.

Cheers,

Dirkjan