[PATCH V2] revset: add "matching" keyword

Angel Ezquerra angel.ezquerra at gmail.com
Tue Apr 3 18:25:11 CDT 2012


On Apr 4, 2012 1:01 AM, "Angel Ezquerra" <angel.ezquerra at gmail.com> wrote:
>
> On Wed, Apr 4, 2012 at 12:56 AM, Angel Ezquerra
> <angel.ezquerra at gmail.com> wrote:
> > # HG changeset patch
> > # User Angel Ezquerra <angel.ezquerra at gmail.com>
> > # Date 1333282334 -7200
> > # Node ID 3e65ae4b56dbc669c90613be40fb5b0f7cbe30e2
> > # Parent  f350021ee32ed22b8bd7d3211a8899df0e3d6552
> > revset: add "matching" keyword
> >
> > This keyword can be used to find revisions that "match" one or more
fields of a
> > given set of revisions.
> >
> > A revision matches another if all the selected fields (description,
author,
> > files, date, parents and/or substate) match the corresponding values of
those
> > fields on the source revision.
> >
> > By default this keyword looks for revisions that whose metadata match
> > (description, author and date) making it ideal to look for duplicate
revisions.
> >
> > matching takes 2 arguments (the second being optional):
> >
> > 1.- rev: a revset represeting a _single_ revision (e.g. tip, ., p1(.),
etc)
> > 2.- [field(s) to match]: an optional field or list of fields to match.
> >  By default matching will match the metadata fields (description,
author and
> >  date). When matching more than one field, they must be input as a
list. When
> >  matching a single field there is no need to surround it in () to make
it a
> >  list.
> >
> > Examples:
> >
> > 1.- Look for revisions with the same metadata (author, description and
date)
> > as the 11th revision:
> >
> > hg log -r "matching(11)"
> >
> > 2.- Look for revisions with the same description as the 11th revision:
> >
> > hg log -r "matching(11, description)"
> >
> > You do not need to type the whole 'description' word. You could also use
> > 'descript' or 'desc' but not 'd' because 'd' also matches 'date' and
'date'
> > takes prefecedence because fields are matched in alphabetical order.
> >
> > 3.- Look for revisions with the same author as the current revision:
> >
> > hg log -r "matching(., author)"
> >
> > You could use 'user' rather than 'author' to get the same result.
> >
> > 4.- Look for revisions with the same description _AND_ author as the
tip of the
> > repository:
> >
> > hg log -r "matching(tip, (author, desc))"
> >
> > 5.- Look for revisions touching the same files as the the tip of the
repository
> >
> > hg log -r "matching(tip, files)"
> >
> > 6.- Look for revisions whose subrepos are on the same state as the
parent of the
> > tip of the repository
> >
> > hg log -r "matching(p1(tip), substate)"
> >
> > 7.- Look for revisions whose author and files both match the tip or the
parent
> > of the tip of the repository:
> >
> > hg log -r "matching(p1(tip):tip, (a, f))"
>
> This is a new version of a recent pathc of mine that used to be called:
>
> revset: add "similar" keyword
>
> This tries to address the comments made by Matt.
> Changes compared to the first version are:
>
> 1. renamed keyword from "similar" to "match" to emphasize that the
> field matching is not fuzzy.
>
> 2. allow matching multiple revisions at a time:
> You can pass a revset as the first argument to matching, and if the
> revset has more than one revision you'll get all revisions that match
> at least _one_ of the revisions in the input revset.
>
> 3. allowing passing a _list_ of fields to match:
> If a list of fields is passed, the function will show revisions that
> match _ALL_ the selected fields. You can still pass a single field to
> match (or none), in which case the field does not need to be a list
> (i.e. it can be a string).
>
> See the examples in the commit message for more info.
>
> Cheers,
>
> Angel

BTW, I'm sure that the performance of the matching function could be
greatly improved by not checking all fields at a time. Instead we could
match one field, then match the matching revisions against the next field,
etc.

That can and should be done, but right now I'm most interested on whether
the name and the interface of the matching function and its functionality
are ok.

Angel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20120404/c46c5539/attachment.html>


More information about the Mercurial-devel mailing list