I still think the changes made to only index repos that had activity during the last year [1] was the wrong call, and potentially makes code search dangerous for those that do not understand this.<p>At least for me a common use case for org-wide code searches is to answer questions like "is the library x still used somewhere?"<p>To not have this include old potentially low-traffic repos is a very bad thing. I don't understand why they would do this for enterprise customers. Like we would pay extra to not have it be this way.<p>[1] <a href="https://github.blog/changelog/2020-12-17-changes-to-code-search-indexing/" rel="nofollow">https://github.blog/changelog/2020-12-17-changes-to-code-sea...</a>
Sounds like it would have been very difficult to implement this without some excellent open source projects. Is github planning to open-source other parts of the system?
=(
I joined last week but still no preview<p>> Join the GitHub Code Search Waitlist
Access is limited during the technology preview of GitHub’s future code search. Sign up today for your chance to try it and give your feedback.<p>You’re already on the waitlist for GitHub Code Search! We’ll email you when we’ve enabled it on your account. Make sure your primary email address is up-to-date.
Given that this is a "history" I can't believe they don't mention grep.app. It's pretty much <i>the</i> way to search entire github.<p>There probably aren't as many drill-down features as the new official way, but speed and simplicity of UI more than make up for it.
I personally don't care about wait time that much for search. I would have for years loved a simple grep that you could do from a browser. Even if it took a minute, that would still be faster than what I've had to do: manually clone the repo locally and run a grep on it on my machine.
I don't remember what my problems are with GitHub search, only that it almost never finds what I'm looking for. I've had to resort to cloning the repo and grepping for what I need more times than I can count.