Devs win when Sourcegraph and GitHub compete. And yes, Microsoft/GitHub will compete fiercely with us--and we'll compete back. Devs should cheer on the competition, rather than let Microsoft/GitHub get complacent.
There are 2 situations where Sourcegraph shines:
1. When you use something many times daily, then you need/deserve the best. We're 100% focused on being 100x better: speed, precise/cross-repo code nav, comprehensive result sets, all branches/commits, more code metadata, all code hosts (GitLab+Bitbucket+any others), way more languages, batch changes, insights, etc. GitHub's code search will be a good place to start if you're new to code search, but Sourcegraph is and will continue to be better for devs who rely on code search frequently, which in my experience is most devs once they get hooked on code search. :) (If we aren't much better than GitHub code search, we don't deserve to exist. Please give us direct feedback on how we can be better--the more competition Microsoft/GitHub feels, the better for everyone!)
2. For companies whose needs differ from what GitHub's core userbase wants, such as self-hosted deployment, single-tenant/managed-instance cloud deployment, massive codebases, numerous repositories, many languages, many code hosts, custom integrations, heavy API usage, etc.
Whether you use Sourcegraph or GitHub, we'll keep improving Sourcegraph to keep up the competitive pressure on GitHub to continue improving their code search. Everyone wins. :)
1. That means our product needs to be even better, and we're up for that challenge! Devs thankfully have a lot of choice over what tools they use, and a better product that devs demand will thrive even in the face of a Microsoft/GitHub distribution advantage.
2. Sourcegraph has plenty of advantages, too: we're 100% focused on this (vs. it just being one of Microsoft/GitHub's many features), our customers are extremely sophisticated eng teams with heavy usage who help us see and build the future of code search, we address a much larger market (not just companies with code exclusively on GitHub.com), etc.
3. Not all the world's code is on GitHub.com. Far from it! And thank goodness. GitLab, Bitbucket, and tons of other code hosts exist, which means that Microsoft/GitHub doesn't have a monopoly. Let's keep it that way.
4. To the extent Microsoft/GitHub has a distribution advantage for code on GitHub.com, that makes it all the more important to keep the competitive pressure on Microsoft/GitHub so they don't get complacent and exploit their advantage in one area (code hosting) to dominate another area. So even if you're using GitHub code search today, root for more competition!
edit: The person emailed me (thank you!), and we will get this resolved ASAP.
I say this as a big fan of SG, because issues like this ring like a big red alarm bell to me.
The GitHub monopoly stranglehold over OSS needs to be broken, not further enriched. You are one of our only hopes..
Since Google closed this project, I never used anything similar, but I think that I should be. I tried few times to use ordinary Github search, but it wasn't good enough to be useful. Hopefully this project will change it. Done properly it would be a very powerful tool.
What's not clear to me is whether that tool searches only on Github or on all repositories in the Internet? Hopefully it's the latter.
for more Google related projects
It's become my default option for API documentation: given basically any API I want to use, this gets me real-world examples of it in seconds - often far more useful than the official documentation.
• searchcode: https://searchcode.com/
• Debian Code Search: http://codesearch.debian.net/
• Python Code Examples: https://www.programcreek.com/python/
• Linux kernel code search: https://livegrep.com/search/linux
C and C++ code search: https://codesearch.isocpp.org/ (uses Debian as source)
Also one thing that has been missing from all these code search engines is tracking how a variable might traverse through the code. In cybersec this is called taint analysis. But for my purposes it greatly helps with just program understanding.
My .02 is whatever GitHub does here should be directly integrated into the main GitHub UI.
https://news.ycombinator.com/item?id=29487237 (217 comments)
Currently learning Rust and I use it multiple times a day to learn patterns of usage for different libraries and language features. Documentation examples may not be that great and with code search you can find actual use cases.
Absolute game changer for me.
I would be delighted to getfast-tracked and get access to better search. github.com/fiatjaf
The domain is a bit annoyingly long but other than that..?
The regular search results page usually has a few pre-set choices that you can quickly click on to refine the results, like a list of languages found. Code Search supports many such filters, and even supporting suggestions or completion in the search box would be a good improvement. With the new UI once you're on the search results page the examples of the home page are no longer visible, so I never know if I should use lang:py or language:python, or if it's path:*.txt or filetype:txt.
it has a few Modern Webdev™ quirks, like when you ^f for something on a result page, it'll respond to your “selection” (read: ^f highlight) with a popup prompting you to try that selection as another query, which of course will pop in and out of existence as you cycle through ^f results and i could go on but ugh
the public sourcegraph instance at sourcegraph dot com is honestly more useful. pro tip: `repo:^github\.com/.*` works as a filter. unfortunately since it's not a first-class citizen of github with access to whatever internal indexing they have, it's slower, but slow and useful is better than fast and infuriating
* surveillance capitalism: tracking and ads
* all of the above
Of course they must see a way to make money with it in the long term.
Like they did with GitHub itself: as a data source for CoPilot ;)
Also there is no money to be made in public code search. Take my word for it. However it is something that all code hosing repository should probably have as a useful too, even if it’s not a direct revenue stream.
I don’t think this will be a separate paid product, just a standard feature as part of paying for GitHub. Sourcegraph will be in the same position as every other SaaS vendor that tries to compete with Microsoft is: a bad one with a worse goto market strategy than MSFT.
Is this somehow fixed in the new codesearch?
If I need to replace or find something across all repos in my organisation, or god forbid, Github, then something went extremely wrong architecturally.
1. When your code is too big for your IDE's built in global search.
2. When you want to share searches with others.
#2 is great for design docs. You can say "<link> shows the bug is common in API usages" or "<link> shows x% of our files do this"
Edit 3. When something does go wrong.
> If I need to replace or find something across all repos in my organisation, or god forbid, Github, then something went extremely wrong architecturally.
If your plan B for messing something up is to not have a plan B you're going to have a bad time when plan A fails :)
Unfortunately, hope is not a strategy.
To give you just one example, recently I've been using it to find how people have written code to interface with e-ink displays. I usually have the datasheet which lists all the commands the protocol support, but building it all into a valid startup sequence of ~20 commands to activate the display is left as an exercise for the reader.
So the docs will look like this: https://www.waveshare.com/w/upload/6/6a/4.2inch-e-paper-spec...
And what I need is a sequence like this: https://github.com/joeycastillo/The-Open-Book/blob/5c5054c58...
That would be terrible indeed. But it might happen. Good to have a powerful tool at hand in that case.
As for searching all public repo code I am not sure I see the need unless maybe you have a super-specific error code to search for.
How do I get Safari to show as in screenshot without the Red / Yellow / Green buttons. The Z height of the title bar also seems to be thinner.
Or is that a different browser?