Issue 670: Bug found in "Allow file:^regex to match affected files" feature
Status:  WontFix
Owner: ----
Closed:  Aug 2010
Reported by rafael.rabelosilva@sonyericsson.com, Aug 20, 2010
Affected Version: 2.1.4

What steps will reproduce the problem?
1. Go to Settings -> Watched Projects
2. Enter the following condition to an existing project:
    file:^FileM[a-z]tch.*\.java
3. Press Watch button

What is the expected output? What do you see instead?

It should accept the condition, since it is a regular expression one and this was introduced in the change https://review.source.android.com/#change,15873 . However, it does not accept, it claims the [ character was not a valid one.

Please provide any additional information below.

I have investigate it and it seems the problem is with the gerrit-server/src/main/antlr/com/google/gerrit/server/query/Query.g file. I understood this file is not automatically generated, so I changed its 185th line to be commented, so after my modification it was like:
     // | '[' | ']'

It solved the issue, but I am not sure if this was the correct solution. Please, if you all agree with this solution, let me know so I can push it.


Aug 20, 2010
#1 sop@google.com
Ugh.  We need to permit [ and ] in values?

Do we also need ( and )?  (Note that's going to get ugly!)

Or { and }?

Is it sufficient to just ask the user to wrap the value in
double quotes in these cases, e.g.:

  file:"^FileM[a-z]tch.*\.java"

If we want to expand the set of what we accept, yes, its
just a matter of uncommenting that '[' | ']' line in the
ANTLR grammar.  Likewise for '{' and '}'.  But I think its
far more complex to do '(' and ')' because those are
tokens handled elsewhere too.  Pulling them in as part
of a token may or may not work.
Status: AwaitingInformation
Aug 20, 2010
#2 rafael.rabelosilva@sonyericsson.com
Hi Shawn. I am sorry I did not notice the use of double quotes would solve the problem. We have repeated the tests using it and it is really ok. When Lincoln originally implemented it, we thought of not using the double quotes. So, this is not an issue :-)
Aug 20, 2010
#3 rafael.rabelosilva@sonyericsson.com
Shawn, still about my comments here. Something that maybe could be confusing to an user is that although (s)he would need to wrap the value in double quotes when using [], (s)he would not need  to use the double quotes in a value like: 

   file:^FileMatch.*\.java

Is that the way it was really supposed to be?
Aug 20, 2010
#4 sop@google.com
Yes.  I wanted to make the burden of double quotes optional
on simple obvious values, but provide them as an escape hatch
for an ugly value that might otherwise be ambiguous.

I guess we can tag this as WontFix then?
Or should we update the search docs better?
Aug 20, 2010
#5 rafael.rabelosilva@sonyericsson.com
Thanks a lot for your attention and explanation, Shawn. 

Maybe it could be a better idea to update the search docs in feature to avoid confusion from an user, but I do not see it as a priority. 

I have faced some questions about using the ^ to indicate use of regular expressions (as we have now when managing ref rights and as we have submitted changes to include merge strategy per branch): maybe, in documentation, it could be also a good idea clarifying the ^ still remains having same meaning it would have in a regular expression, so it could be used after a [ to indicate character(s) to be excluded. E.g.: 
    file:"^FileM[^b-z]tch.*\.java"

But, Shawn, as I told you, I do not see this as a priority, just some suggestions that could maybe help users when reading documentation. Maybe, if you prefer, I could talk to Ulrik so we could push to review a documentation update.

Anyway, I agree we can tag this as WontFix.
Aug 21, 2010
#6 sop@google.com
Sure, I'd be happy to take a documentation patch from
you guys too.  Sometimes it can be a lot more useful
to a user than a code patch.  It just usually isn't
as interesting to write.  :-)
Status: WontFix