[PATCH] revset: add "similar" keyword

[Matt Mackall]

On Tue, 2012-04-03 at 00:11 +0200, Angel Ezquerra wrote:
> On Mon, Apr 2, 2012 at 10:32 PM, Matt Mackall <mpm at selenic.com> wrote:
> > On Sun, 2012-04-01 at 14:21 +0200, Angel Ezquerra wrote:
> >> # HG changeset patch
> >> # User Angel Ezquerra <angel.ezquerra at gmail.com>
> >> # Date 1333282334 -7200
> >> # Node ID 5027b86b02e8285493fb359367dc36f3cf481688
> >> # Parent  b3fefbb95aad2a9b5b8e44e6fea4860d6690368b
> >> revset: add "similar" keyword
> >
> > Looks like my earlier reply to this got lost. Two comments:
> >
> > - "similar" implies "nearly equal" or fuzzy matching, so this name is
> > not quite right
> 
> You are right. I just went with Simon's suggestion. Do you have a
> better idea? What about 'matching'? English not being my primary
> language I'm sure someone else can come up with a much better name.

[getting to this late, going to answer some questions here]

'matching' seems fine.

> > - we probably want to allow a set as the first field, not just a single
> > rev
> 
> The first field can already be a revision set (e.g. p1(.)). The only
> limitation is that the set must contain a single item :P
> 
> I actually thought about supporting sets with more than one item, but
> I was unsure that you'd like it. It can be easily added if you think
> it is a good idea.
> 
> If we do, I'm thinking that it would do a simple loop, repeating the
> search on each item in the input set. Since the searches could return
> repeated results, we would need to convert everything into a python
> set to remove duplicates...
> 
> Is it assumed that revsets must return ordered lists of revisions?

Generally, yes, ordered 0 to tip. sort() and possibly a couple others
break this rule.

> > We already do something sort of like this with branch(), which can take
> > either a string or a set. Perhaps we want to make date, author, etc.
> > take sets.
> 
> That is a good idea. Even if we did that I think that having a
> "similar" (or "matching" or whichever name we choose) would be useful,
> since such a function could match more than a single field at a time
> (e.g. the "metadata" pseudo-field implemented on my patch).
> 
> Do you agree?

Yes.

-- 
Mathematics is the supreme nostalgia of our time.