(BTW: Passionate about a language and want to help us build Sourcegraph support for it, or know someone who'd be interested? Email me at firstname.lastname@example.org. We can sponsor you. The latest requirements for adding a new language are not yet publicly documented, so contact us before getting started.)
If your search on GitHub isn’t fruitful, consider giving Debian Code Search a spin.
Disclaimer: I built it. Happy to answer questions if you have any.
$ curl -s http://ftp.ch.debian.org/debian/dists/sid/main/source/Source... | zgrep '^Package: git$' | wc -l
If we didn’t index Debian sid, you’d only get one version per package, but also the results wouldn’t be as fresh.
You can follow one of these two issues:
https://github.com/Debian/dcs/issues/40 (at most 1 result per package)
https://github.com/Debian/dcs/issues/49 (limit by suite, where you could search something else than Debian sid)
If you have any other ideas about how to address the issue, please let me know.
Check out https://people.debian.org/~stapelberg//2016/08/08/debian-cod... for details on the most recent bigger change.
I search for ".2f}%'.format(100" and then send a push request to simplify the code.
personally, i dislike such spammy prs. it adds nothing to my code, and its not like accepting the pr is going to attract you as a developer on my code.
Something else I would add is that you should try to find well known OSS contributors that work on projects that use tech/languages you use. If you monitor their projects you can pick up great habits from reading through their code.
Apache Arrow (https://github.com/apache/arrow/) is very interesting and promising project. It is in early state; you can watch the design decisions taken and how they are implemented. Plus it is multi-language project, you can find code in C++, Java and Python.
I think it works fine for simple searches mentioned in the post, but anything even slightly more advanced doesn't work very well. I also wish there was a way to search in branches other than master
This is actually an insanely hard problem to solve, given current technology. Right now, you can either try to index a little bit of everything, which is what GitHub and others (GitLab, Bitbucket, etc.) are doing. Or you can take the approach that I'm taking, which is make it possible for the user to search any branch they want, but limit the number of repositories they can search in parallel.
GitHub and my approach are definitely targeted at two different use cases. My background is Enterprise, which is why my search solution is based on "search relevance", while GitHub is more focused on "search discovery", which is more suited for finding random things.
It's a workaround to do search in different branches on 1 repo, but works fine
What may not be obvious from the video is, indexing additional branches is extremely efficient and fast, since most branches usually share 90 - 99% of the same content.
My indexing technology, also introduces a "group" concept, which makes it possible for you to share indices across similar repos, which makes indexing hundreds of forked repos, quite efficient and fast.
Apparently this is related to how the search index works, but cumbersome nevertheless.
I doubled down by offering the locally installable one which I then deployed at my workplace. It has been useful for finding how other teams implement bluebird promises and general auditing for checked in AWS keys and the like. Now I think about it it is used lot for code auditing. Probably something I should focus on for new release.
Just tried a simple search for a lib I use and found great ways to refactor my code.
I'm going to use this method when learning about a new package.
Still, if the user is aware of these pitfalls then it could be quite useful. Perhaps it could be improved if GitHub provided some incentive for developers to showcase their better work as 'known good' examples and let the community vote on the quality, similar to the Stack Overflow model.
For example, maybe the code sample has a section that formats and saves the result to a file using the standard library. From looking at that section, you have no way of knowing that the library offers a .saveToFile method that would have been better to use instead. Or if you search for "mysql" examples in PHP, you may find example usage of the hard-to-secure, deprecated mysql_real_escape_string function instead of the PDO library that is supposed to replace it.
There was a small lag between repo code and the dump done on Big Query (some days) last time I checked, but it seems that the delay has been getting smaller and smaller over time.
It could just as easily turn out to be no better than CASE or rational or any other junk that's come before.