[PATCH 7 of 8 V2] revset: add origins() predicate

[Matt Mackall]

On Wed, 2012-06-20 at 22:34 -0400, Matt Harbison wrote:
> A concrete example would be: 'hg graft 2' creates cset 3.  Then 
> origins(all()) == {2} while origin(all()) == {3}.

Then we have a terminology problem.

I read origin(x) as "the origin of x", not "things that have x as an
origin". Now, granted, there's no perfectly consistent way to convert
f(x) to English:

 heads(x): heads of the set x
 ancestors(x): ancestors of x
 parents(x): parents of x
 branch(x): all revs on (branch x OR branch of rev x)
 converted(x): converted FROM x [1]

(Here, "parents" is the closest predicate semantically, as it's directly
exposing edges recorded in our graph.[2])

For the most part, we go for the "foo of x" interpretation when it fits.
I claim that this is far more natural than a "things that have x as a
foo" interpretation, both from an English and a mathematics
perspective. 

In no case should we have a "foo" and "foos" with opposite semantics.
That's just way too confusing to live. And if we have origin and
destination that aren't opposites, we've also got a problem. At least
for simple grafts, I'd expect origin(destination(x)) = x and
destination(origin(y)) = y.

Lastly, we don't need any predicate of the form "baz(x)" which would be
equivalent to "x and baz(all())". So if something takes a set, it should
be filtering the input side, not the output side.

[1] As you noted, "converted TO" won't generally result in a valid rev,
this is the only reasonable definition.
[2] That edge is named parent in our schema, which suggests the
predicate here should be named "source" rather than origin. But I don't
know if we expose the "source" terminology anywhere.

-- 
Mathematics is the supreme nostalgia of our time.