5 ms·

It is a real cultural problem how engineers get more excited about machine learning than basic usability. GitHub search can't even search for a literal string,

It is a real cultural problem how engineers get more excited about machine learning than basic usability. GitHub search can't even search for a literal string, let alone a regex. It can't search a subdirectory. Ranking is indistinguishable from random. It's been this way for years. How about building an actual, usable, basic code search and then getting all fancy with your machine learning? I almost built my own "online git grep for GitHub" last year.

brian-armstrong 8y ago
Yes! When I read the post title I was really excited. The I clicked in and felt my heart sink a little. Engineers and PMs seem to be too easily swayed by shiny things.
kornish 8y ago
Agreed. Luckily, we as a community have tools like Sourcegraph which are based on battle-tested pragmatic systems from places like Google. Disclaimer: no affiliation, just love the team and product.
- dgreensp 8y ago
  Thanks for the recommendation
- welder 8y ago
  At first I thought this would replace Sourcegraph, but looks like it's just an experiment with NLP... Thank goodness we have Sourcegraph for searching GH but especially for searching GHEnterprise in an SOA environment where it's impossible to have every repo cloned locally for ripgrep. P.S. I'm not affiliated, we just use Sourcegraph at a company I work for.
- bryanrasmussen 8y ago
  Damn, Sourcegraph is very close to something I've been thinking of building.
  - sqs 8y ago
    Join us! We are hiring and growing quickly.
samlambert 8y ago
All I can say is that we know this. We know it should be better. There's definitely more to come.
Sir_Cmpwn 8y ago
I agree with this sentiment 100%. I can use traditional search engines for "how to ping a rest thing in python", but I can't grep Github for even basic snippets of code. I don't think their global code search has ever been useful. Glad they have their priorities straight /s
psychometry 8y ago
You also can't search a forked repository, which is pathetic.
- Deimorz 8y ago
  This limitation is especially frustrating when a fork becomes the "primary" repo for a project for some reason. It's probably not a common occurrence overall, but I've run into it at least a couple of times. A good example is that GitHub's own repo for their CommonMark implementation isn't searchable, because it's a fork of cmark: https://github.com/github/cmark/ https://github.com/github/cmark/
boyter 8y ago
To be fair its a hard problem to solve, especially with traditional search engine tools. Take for example, for(int i=0;i<100;i++) And then a search for i++ Due to the way almost every search tool works that would be split into tokens "for int i 0 100" which are not very useful. Even if you include the characters = ; < + ( ) in the search you break the ability to do things such as boolean queries or fuzzy search term~1 Its totally possible to solve these issues using tweaks of the input into your index, which is what I did with searchcode.com or with a different approach which is what Google Code Search did. However neither have a requirement to be 100% in sync with the repository which I suspect is something that the github team value. All the code search tools suffer from this in some way. At small scale its possible to just brute force the search. At scale you can do it by tweaking your algorithm and sacrificing accuracy. My feeling is that the github team chose accuracy.
- amelius 8y ago
  But people use grep on their code all the time ...
  - boyter 8y ago
    People use grep on their local code repository, which is generally less than 2 gigabytes of source. A tool like ripgrep can process that in under a second on any modern machine with a warm disk cache. Its when you get to hundreds of repositories or 10's of gigabytes of code that local tools cannot run fast enough. They are not designed for this use-case, and usually rely on the files being searched hitting the disk cache for repeated search performance. It may be possible for github to shell out to grep for a single repository search (I have no idea how the back-end works but I doubt its impossible) but, I suspect that almost everyone wants/expects this to work across multiple repositories or across all of the github repositories. Since its not easily possible to do so across everything they are not adding it to even a single repository to avoid search working differently for different situations, which is a fair approach in my opinion.
    - nerdponx 8y ago
mullikine 8y ago
I made a regex search for GitHub and emacs plugin. In theory I could put this on GitHub. It uses the bigquery ghtorrent table. There's only so much time in a day though. If you want it upvote me
neongreen 8y ago
I'm building one! https://codesearch.aelve.com https://codesearch.aelve.com Currently it runs on a fairly slow machine, so regex-heavy requests will take some time on big package repositories like Rubygems, but I plan to get a nicer machine soon. If you know Scala, you can even contribute (wink wink), just ping me. A lot of tasks we have at this stage are pretty basic.
- nh2 8y ago
  Nice! Next index all public Github repos?
karmakaze 8y ago
In full agreement. Every now and then I'll expect a search to work. My solution has been to run etsy/hound [0] for my active reps. [0] https://github.com/etsy/hound
bradleyjg 8y ago
Exactly this. I don’t understand why the-thing-I-searched-for.java is so rarely on the first page of results. Doesn’t that seem like an obvious thing I might be interested in?!?
VirenM 8y ago
I've honestly moved to Google, adding `{search query} -site:github.com/{repo}/{file i want to target}` Its much clearer and concise.
petters 8y ago
Could not agree more. Everyone who works for or have worked for Google in the last years knows that an excellent code search does not have to be fancy.
bitL 8y ago
So what? Here their only mistake is not to license/buy some search engine instead of wasting years on developing another "meh" one. What they are doing here with semantic search is the future and their chance to make all existing code search engines obsolete. Use your favorite Internet search engine to find GitHub's snippets of code instead. Those won't give you semantic code search though.

brian-armstrong 8y ago

Yes! When I read the post title I was really excited. The I clicked in and felt my heart sink a little. Engineers and PMs seem to be too easily swayed by shiny things.

kornish 8y ago

Agreed. Luckily, we as a community have tools like Sourcegraph which are based on battle-tested pragmatic systems from places like Google. Disclaimer: no affiliation, just love the team and product.

dgreensp 8y ago
Thanks for the recommendation
welder 8y ago
At first I thought this would replace Sourcegraph, but looks like it's just an experiment with NLP... Thank goodness we have Sourcegraph for searching GH but especially for searching GHEnterprise in an SOA environment where it's impossible to have every repo cloned locally for ripgrep. P.S. I'm not affiliated, we just use Sourcegraph at a company I work for.
bryanrasmussen 8y ago
Damn, Sourcegraph is very close to something I've been thinking of building.
- sqs 8y ago
  Join us! We are hiring and growing quickly.

samlambert 8y ago

All I can say is that we know this. We know it should be better. There's definitely more to come.

Sir_Cmpwn 8y ago

I agree with this sentiment 100%. I can use traditional search engines for "how to ping a rest thing in python", but I can't grep Github for even basic snippets of code. I don't think their global code search has ever been useful. Glad they have their priorities straight /s

psychometry 8y ago

You also can't search a forked repository, which is pathetic.

Deimorz 8y ago
This limitation is especially frustrating when a fork becomes the "primary" repo for a project for some reason. It's probably not a common occurrence overall, but I've run into it at least a couple of times. A good example is that GitHub's own repo for their CommonMark implementation isn't searchable, because it's a fork of cmark: https://github.com/github/cmark/ https://github.com/github/cmark/

boyter 8y ago

To be fair its a hard problem to solve, especially with traditional search engine tools. Take for example, for(int i=0;i<100;i++) And then a search for i++ Due to the way almost every search tool works that would be split into tokens "for int i 0 100" which are not very useful. Even if you include the characters = ; < + ( ) in the search you break the ability to do things such as boolean queries or fuzzy search term~1 Its totally possible to solve these issues using tweaks of the input into your index, which is what I did with searchcode.com or with a different approach which is what Google Code Search did. However neither have a requirement to be 100% in sync with the repository which I suspect is something that the github team value. All the code search tools suffer from this in some way. At small scale its possible to just brute force the search. At scale you can do it by tweaking your algorithm and sacrificing accuracy. My feeling is that the github team chose accuracy.

amelius 8y ago
But people use grep on their code all the time ...
- boyter 8y ago
  People use grep on their local code repository, which is generally less than 2 gigabytes of source. A tool like ripgrep can process that in under a second on any modern machine with a warm disk cache. Its when you get to hundreds of repositories or 10's of gigabytes of code that local tools cannot run fast enough. They are not designed for this use-case, and usually rely on the files being searched hitting the disk cache for repeated search performance. It may be possible for github to shell out to grep for a single repository search (I have no idea how the back-end works but I doubt its impossible) but, I suspect that almost everyone wants/expects this to work across multiple repositories or across all of the github repositories. Since its not easily possible to do so across everything they are not adding it to even a single repository to avoid search working differently for different situations, which is a fair approach in my opinion.
  - nerdponx 8y ago

mullikine 8y ago

I made a regex search for GitHub and emacs plugin. In theory I could put this on GitHub. It uses the bigquery ghtorrent table. There's only so much time in a day though. If you want it upvote me

neongreen 8y ago

I'm building one! https://codesearch.aelve.com https://codesearch.aelve.com Currently it runs on a fairly slow machine, so regex-heavy requests will take some time on big package repositories like Rubygems, but I plan to get a nicer machine soon. If you know Scala, you can even contribute (wink wink), just ping me. A lot of tasks we have at this stage are pretty basic.

nh2 8y ago
Nice! Next index all public Github repos?

karmakaze 8y ago

In full agreement. Every now and then I'll expect a search to work. My solution has been to run etsy/hound [0] for my active reps. [0] https://github.com/etsy/hound

bradleyjg 8y ago

Exactly this. I don’t understand why the-thing-I-searched-for.java is so rarely on the first page of results. Doesn’t that seem like an obvious thing I might be interested in?!?

VirenM 8y ago

I've honestly moved to Google, adding `{search query} -site:github.com/{repo}/{file i want to target}` Its much clearer and concise.

petters 8y ago

Could not agree more. Everyone who works for or have worked for Google in the last years knows that an excellent code search does not have to be fancy.

bitL 8y ago

So what? Here their only mistake is not to license/buy some search engine instead of wasting years on developing another "meh" one. What they are doing here with semantic search is the future and their chance to make all existing code search engines obsolete. Use your favorite Internet search engine to find GitHub's snippets of code instead. Those won't give you semantic code search though.