[PATCH] revset: add regular expression support to 'desc()'

Sean Farley sean at farley.io
Sat Jan 7 23:34:51 EST 2017


Matt Harbison <mharbison72 at gmail.com> writes:

> On Sat, 07 Jan 2017 22:55:02 -0500, Sean Farley <sean at farley.io> wrote:
>
>> Matt Harbison <mharbison72 at gmail.com> writes:
>>
>>> # HG changeset patch
>>> # User Matt Harbison <matt_harbison at yahoo.com>
>>> # Date 1483842392 18000
>>> #      Sat Jan 07 21:26:32 2017 -0500
>>> # Node ID 7347f75339503a8266285ac12412ac5f104d4df0
>>> # Parent  4ab19763d71c2bb9a239dff523b18ed860e34563
>>> revset: add regular expression support to 'desc()'
>>>
>>> The legacy behavior of doing a case insensitive match for literals is  
>>> preserved
>>> for BC.  This includes with the new 'literal:' prefix for user  
>>> simplicity.
>>>
>>> There are two other revsets that do case insensitive matches- 'user()'  
>>> (and its
>>> alias 'author()'), and 'keyword()'.  The 'keyword()' predicate only  
>>> supports
>>> literals, so its behavior isn't interesting right now.  The 'user()'  
>>> predicate
>>> is documented to support regex, but ends up lowercasing both the needle  
>>> and the
>>> haystack, effectively making it a case insensitive regex.  That  
>>> surprised me,
>>> since it's the only instance of that behavior.  I'm not sure if this  
>>> should
>>> conform to that because we are stuck with BC, or if that should be  
>>> considered a
>>> bug and changed.  If we can't change it, that probably precludes adding  
>>> an
>>> insensitive regex matcher [1].
>>>
>>> [1]  
>>> https://www.mercurial-scm.org/pipermail/mercurial-devel/2017-January/092070.html
>>
>> I was a bit confused before because I was mixing up templates with
>> revsets. If I follow your previous patch, you want to have a revset that
>> just searches the first line of the description, correct?
>
> Correct.
>
>> If that's correct, it would seem that our choices with template
>> functionality might be a precedent for this, no?
>
> Ideally. But I'm not sure how to apply that here.  Are you suggesting a  
> new predicate 'firstline()' (instead of 'summary')?  I assumed the  
> template filter was generically named because it's a generic filter  
> (though realistically I'm not sure what else you would want to limit to  
> the first line).
>
> If you mean the filtering functionality ("{desc|firstline}"), I'm not sure  
> how that helps.  Obviously you can filter _revisions_ by chaining  
> predicates, but what this needs to do is narrow down the _field_ being  
> tested within one predicate.  I don't know of any revset mechanism to do  
> that.

Yeah, that makes sense. I was just trying to think out loud. One of the
reasons we went with 'firstline' in the template engine was because it
was so damn hard to write a regex (not to mention all the escaping
needed for quoting on the command line) for just the first line.

I'm not really suggesting a change here, just bringing to light some of
the reasoning before.


More information about the Mercurial-devel mailing list