Skip to content

search: fix type:repo behavior

Warren Gifford requested to merge backend-dry-run/rvt/type-repo-rewrite into main

Created by: rvantonder

Addresses https://github.com/sourcegraph/sourcegraph/issues/19239.

This is a fairly complex and intentional behavioral change to type:repo. Considering it was basically broken for 3 months on Sourcegraph.com and hindering unfamiliar users I'm pretty aggressive about the behavioral changes here.

What did type:repo do before?

When it did work, it would behave roughly as:

  • type:repo foo bar means repo:"foo bar". I.e., if a user typed type:repo facebook react they are basically guaranteed to not get any results on Sourcegraph.com, since hardly any repos on GH contain a space (zero?)

  • type:repo foo bar in regex mode means repo:foo.*bar, as we take the convention of interpolating .* for spaces in regex mode.

What does type:repo do now?

There's a comment in the code, but basically:

  • type:repo any thing is translated to repo:any repo:thing. This means we will do an and search for space-separated patterns (as opposed to content searches, where spaces are significant for ordering). The and search is more suited when the user expects to search for repositories containing all these keywords. type:repo facebook react will give a lot of results (not necessarily the order we want, but we'll get hits).

  • type:repo a or not b is translated to repo:a or -repo:b. Basically, any and or or operator is preserved when translating patterns with a repo: prefix, and additionally, not works as is

  • caveat: because of the complex behavior must restrict the use of type:repo to only allow type:repo in isolation, it cannot be combined with other type: queries. I.e., (type:repo or type:file) an example is not supported. This because we want type:repo to interpret "the rest" of the query at translation stage different to any other query shape, where other query shapes are understood as ordered patterns as-is, or otherwise rely on whatever inlined behavior we have elsewhere in the backend). It's not that it's not supportable. It's that it would take me 2 weeks+ to modify parsing so that it now takes into account context from something like type within a particular scope, which I would prefer not exist in the first place.

Merge request reports