Skip to content

Support unix-style globbing patterns for search field values

Created by: rvantonder

Example: file:*.go currently doesn't work (it's not valid regex).

Proposal is to add this in the new and/or query logic, which will subsume the current logic (and will be easier to implement). The implementation can fallback to trying globbing (e.g., by converting it to a regex) if the regex parsing fails. The idea is that this should apply to all fields that accept a regex.

Current RFC 198

Requested by customers

Guidance, copied over from previous issue:

Adding some additional context from slack convo:

  • This should probably apply to file and repo params
  • One idea: add syntax to disambiguate intent, e.g., field:substring field:=exactstring field:~regex (or field:/regex/) and field:%glob
    • feedback: not sure users would intuitively know to use field:%glob , default assumption of users is field:glob when it's file or repo filter but substring otherwise
    • feedback: support Kleene-star * syntax for globbing and don't think it'll significantly impact existing regex filters. Supporting other syntax should be done carefully (it's great to support "everything"), but syntactically richer can also mean bogging things down
  • feedback on a heuristic for implementing globbing versus just making it a consistent default, instead of extra syntax:

I value consistency since it avoid surprises / makes the interface easier. I think for example a regular expression for content but glob for file can be quite surprising (especially when you look at things like the * ). However, the argument could be made that all non content fields make much more sense as globs

  • There's a world where we can convert the query from regex to globs in the UI, and not the backend. Because the backend is currently the source of truth for parsing and validation, @rvantonder does not think this is where the logic should go right now.

Summary:

@stefanhengl you should feel free to propose a solution for the above and gather input. Revisiting the feedback I think we may actually have a strong case for treating repo: and file: filters as literal strings with glob support by default. The open question is how to support regular expressions if we change the default (maybe syntax, maybe a heuristic that detects regex metasyntax, maybe something else).