1. There doesn't appear to be any relevancy sorting. It appears only the exact term is returned. If it’s not exact, I am not sure how to control whether or not it looks for an exact match and/or what strategy it uses to fuzzy match. Does it tokenize? Use some kind of levenstein distance algorithm?
2. The query results are hugely wasteful in terms of screen space. This means searching for a minorly common term in a large codebase is prohibitively time consuming compared to cloning + ripgrep or whatever.
3. There's no way to search file names + file content. It took me 7 years after github's creation to realize you could search for filenames if you press 't' on the repository.
4. No regex or globbing support, to my knowledge.
This is before listing all the tooling (like sourcegraph) I would hope would be built into a source code repository to assist browsing but are strangely missing--every IDE and editor out there is much faster at casually browsing code because navigation is so much cheaper and frictionless.
I mean overall it's not broken, it's just way less useful for searching a tree of code files than find/xargs/grep is, let alone ack/thesilversearcher/ripgrep. If the capabilities I'm describing are there, they're well-hidden. Github just isn't a good place to browse code.
1. I never really noticed that because I mainly use Sourcegraph's code-intelligence on open source projects and as a result search is something that I have to rarely rely on.
2. You can stylize any page using something like stylebot or a homebrew browser extension.
3. Although not something that I do often, I find the filename search on google (for OSS projects) quite accurate and then the chrome extension allows you to open that file on sourcegraph.com or inject code intelligence within the github page as well.
2) isn’t about style, it’s about the fact that the results are paginated. You end up needing to search the damn search results, which is super slow when you’re paginated and it could have been a screen scan if you could fill the screen with results and scroll rapidly through the rest.
this is just honest feedback, not a value judgement.
I don’t think the person you replied to is complaining about Sourcegraph. He is talking about how he dislikes GitHub code search, and it seems that he likes Sourcegraph.
I dislike github search too, especially the pagination part but the issues GP mentioned can be avoided by using some google-foo and Sourcegraph for Chrome :)
So, you end up having to clone all repos locally and grep for the word.
Just pointing out that limitation of search in GitHub, not saying that this other tool is actually reliable to do this kind of things (I haven't used it before)
To compare GitHub to Sourcegraph search, here is that same query on Sourcegraph.com (which is Sourcegraph Server running for all open-source code on GitHub):
If your needs are met by GitHub's search, then I would still suggest using the Sourcegraph Chrome extension (also available for Firefox), which adds code intelligence to code you view on GitHub: https://chrome.google.com/webstore/detail/sourcegraph-for-gi....
Did you get permission from SourceGraph to post this comment to HN?
> You may not release the results of any performance or functional evaluation of any of the Software to any third party without prior written approval of Sourcegraph for each such release.
We just removed that clause (also replied to your other comment about it). Didn’t intend for it to be in there; I agree it’s silly. Thanks for pointing it out.
I don't really get the pricing on code intelligence. So if I have 50 users and want Javascript, Python, and PHP, that's $750/month, even if 25 users only ever use Python?
If you want 3 or more languages, then contact us (at https://about.sourcegraph.com/pricing) and we can give you a package discount. Overall, if pricing is a concern, I'd love to learn more. I'll email you.
I think it really boils down to a perception issue. I think more people would be happy paying a flat fee for a language package then deal with the angst of "wasted" money paying for languages that some users don't leverage. The package as it currently stands would "work" if I could assign languages to users and have that reflect back up to pricing, but that's cumbersome to manage from a customer perspective and sounds pretty painful to implement from the provider perspective.
It may be useful to consider a baseline two-language deal, as Javascript + one server side language covers a huge amount of use cases.
That said, you cover 2 out of 3 of the following scenarios pretty well with the existing model, I just happen to fall into the third, which is probably the smallest sector for you guys anyway:
1 - Small startups, probably standardized on one or two languages, 8-10 people
2 - Larger orgs (200+) where the cost is negligible compared to revenue.
3 - Medium-sized, microservice/squad based orgs, with heterogenous language support but focused within teams.
Personally, I find it to be absolutely horrendous. It’s so much faster to clone the repo and search it locally.