3 ms·

A little off topic, but does anybody else feel like GitHub's pace of feature development is...unusually slow? Admittedly, I have never used the paid Enterprise

A little off topic, but does anybody else feel like GitHub's pace of feature development is...unusually slow? Admittedly, I have never used the paid Enterprise version so I don't know if it has received more attention. But, seriously, why is the search so terrible (talking about a global search across repos)? Doesn't not having to worry about semantics (just focus on text matches) make this easier? Also, why is the mobile view so crippled (no way to sort or search issues or pull requests)? If anybody has a reasonable explanation, I'd be very interested to hear it.

derefr 9y ago
> But, seriously, why is the search so terrible Because it's not just a matter of configuration/input-munging, the way getting to "good search" for text is. The existing solutions for search at scale (ElasticSearch, Solr) just don't work well for a code-document corpus the way they work for a text-document corpus. Trying to trick them into doing so will only get you half-way there, and then you're stuck in molasses if you try to improve from there. You really have to build "code search" from the ground up, doing things like running language-specific parsers over each codebase and then building tries out of linearized AST node token sequences.
- sqs 9y ago
  There’s a big difference between code search over 20M repositories (GitHub’s goal, and what people need a few times per week) and code search over 1-50,000 repositories (what developers at companies need several times per day). Doing the latter lets you simplify the indexing a lot if you have a lot of memory available (shameless plug: https://about.sourcegraph.com/products/code-search/ https://about.sourcegraph.com/products/code-search/). But doing it over 20M repositories needs an index that takes weeks, if not months, to rebuild and severely limits your ability to ship improvements. I’m thankful they are doing the work of building that for the developer community, though!
yRetsyM 9y ago
Compared to bitbucket, definitely not. I've become increasingly frustrated by the lack of pace of development and feature improvements on bitbucket.
seanjregan 9y ago
From the Bitbucket Code Search Blog: Search indices built using traditional text indexers will usually return the usage result first because it contains a higher number of exact matches for your search term. In code bases where the same class or function is used many times, developers are often left trawling through page after page of usage results trying to hunt down the definition. Bitbucket took a different approach: by boosting the definitions matching your search term, the result you want is likely to rank much higher (usually #1) in the search results. Bitbucket's algorithm boosts definitions for a wide range of type categories including classes, functions, enums, structs, and interfaces. Bitbucket prioritized building a code aware search scoped to team and user accounts over a global search functionality. This way, we hope to quickly give users the relevant results they want instead of the hassle of checking out a repo locally and searching using an IDE. https://blog.bitbucket.org/2017/05/02/introducing-code-aware-search-for-bitbucket-cloud/ https://blog.bitbucket.org/2017/05/02/introducing-code-aware...

derefr 9y ago

> But, seriously, why is the search so terrible Because it's not just a matter of configuration/input-munging, the way getting to "good search" for text is. The existing solutions for search at scale (ElasticSearch, Solr) just don't work well for a code-document corpus the way they work for a text-document corpus. Trying to trick them into doing so will only get you half-way there, and then you're stuck in molasses if you try to improve from there. You really have to build "code search" from the ground up, doing things like running language-specific parsers over each codebase and then building tries out of linearized AST node token sequences.

sqs 9y ago
There’s a big difference between code search over 20M repositories (GitHub’s goal, and what people need a few times per week) and code search over 1-50,000 repositories (what developers at companies need several times per day). Doing the latter lets you simplify the indexing a lot if you have a lot of memory available (shameless plug: https://about.sourcegraph.com/products/code-search/ https://about.sourcegraph.com/products/code-search/). But doing it over 20M repositories needs an index that takes weeks, if not months, to rebuild and severely limits your ability to ship improvements. I’m thankful they are doing the work of building that for the developer community, though!

yRetsyM 9y ago

Compared to bitbucket, definitely not. I've become increasingly frustrated by the lack of pace of development and feature improvements on bitbucket.

seanjregan 9y ago

From the Bitbucket Code Search Blog: Search indices built using traditional text indexers will usually return the usage result first because it contains a higher number of exact matches for your search term. In code bases where the same class or function is used many times, developers are often left trawling through page after page of usage results trying to hunt down the definition. Bitbucket took a different approach: by boosting the definitions matching your search term, the result you want is likely to rank much higher (usually #1) in the search results. Bitbucket's algorithm boosts definitions for a wide range of type categories including classes, functions, enums, structs, and interfaces. Bitbucket prioritized building a code aware search scoped to team and user accounts over a global search functionality. This way, we hope to quickly give users the relevant results they want instead of the hassle of checking out a repo locally and searching using an IDE. https://blog.bitbucket.org/2017/05/02/introducing-code-aware-search-for-bitbucket-cloud/ https://blog.bitbucket.org/2017/05/02/introducing-code-aware...