3 ms·

We're always listening. 1. We're working on the speed. It has gotten a lot better with the last few releases. The release of tomorrow is another big step, espe

We're always listening. 1. We're working on the speed. It has gotten a lot better with the last few releases. The release of tomorrow is another big step, especially for diffs. We have a number of issues for this, I'm linking one of the meta issue here, but be sure to check the release of tomorrow for graphs and whatnot [0] 2. It's definitely an interesting idea. I made an issue [1]. Love it if you would provide some feedback. I wonder whether we'd be allowed to do such a thing, but it seems to be in the interest of the end-user, which is a good thing. [0]: https://gitlab.com/gitlab-com/infrastructure/issues/59 https://gitlab.com/gitlab-com/infrastructure/issues/59 [1]: https://gitlab.com/gitlab-org/gitlab-ee/issues/903 https://gitlab.com/gitlab-org/gitlab-ee/issues/903

sdesol 10y ago
If you are serious about doing [1] and are willing to throw the hardware resources behind this initiative, I can probably work with you guys to make GitLab, a central point for searching all open source projects that are versioned by Git. I've probably indexed over 100,000 public repos from GitHub as part of testing, and to be honest, one of the biggest problem has always been finding repos worth indexing. You can learn more about my search technology at https://gitsense.com/blog https://gitsense.com/blog However, it's worth noting that GitSense is not optimized for searching across 1000+ repositories at once and to be honest, this is never a good thing in my opinion. When it comes to code searches, I believe it should be curated, where some domain expert can say if you are working on release x, for open source project y, these are the branches/repos you will probably be interested in and so forth. Until we have artificial intelligence, like we see in movies, nobody is going to produce relevant code search results, by searching tens of thousands of repos. Software development is completely context driven and what mattered for one release, can become completely irrelevant in the next. What GitSense is optimized for, is searching across logical groupings of code at the branch level. This can be 1000 branches from 1000 repos or 1000 branches from the same repo/forks. If GitLab is serious about being a central point for all open source code searches and are okay with providing logical searches at the branch level, let me know. You can contact me via my email in my HN profile. And it's probably worth noting, since the GitSense indexing engine/search engine are completely separate from the frontend, it'll be easy enough for GitLab add their own interface.
- ptman 10y ago
  Google Code Search was awesome, and it searched from all indexed projects at once. As does https://codesearch.debian.net/ https://codesearch.debian.net/
  - sdesol 10y ago
    The problem with Google Code Search and the one that you mentioned is, you can never be certain the match is relevant/correct. And the reason for this is, you are always searching against a single branch/timeline. Definitions can change from one release to another. Function behavior can change from one release to another and so forth. Searching across millions of repos is not difficult, if you are willing to accept the matches returned may or may not be relevant. What is extremely difficult, is building a search solution that can take into consideration all the changes, on every branch, from the millions of repos. And this is the problem nobody is going to solve anytime soon.

sdesol 10y ago

If you are serious about doing [1] and are willing to throw the hardware resources behind this initiative, I can probably work with you guys to make GitLab, a central point for searching all open source projects that are versioned by Git. I've probably indexed over 100,000 public repos from GitHub as part of testing, and to be honest, one of the biggest problem has always been finding repos worth indexing. You can learn more about my search technology at https://gitsense.com/blog https://gitsense.com/blog However, it's worth noting that GitSense is not optimized for searching across 1000+ repositories at once and to be honest, this is never a good thing in my opinion. When it comes to code searches, I believe it should be curated, where some domain expert can say if you are working on release x, for open source project y, these are the branches/repos you will probably be interested in and so forth. Until we have artificial intelligence, like we see in movies, nobody is going to produce relevant code search results, by searching tens of thousands of repos. Software development is completely context driven and what mattered for one release, can become completely irrelevant in the next. What GitSense is optimized for, is searching across logical groupings of code at the branch level. This can be 1000 branches from 1000 repos or 1000 branches from the same repo/forks. If GitLab is serious about being a central point for all open source code searches and are okay with providing logical searches at the branch level, let me know. You can contact me via my email in my HN profile. And it's probably worth noting, since the GitSense indexing engine/search engine are completely separate from the frontend, it'll be easy enough for GitLab add their own interface.

ptman 10y ago
Google Code Search was awesome, and it searched from all indexed projects at once. As does https://codesearch.debian.net/ https://codesearch.debian.net/
- sdesol 10y ago
  The problem with Google Code Search and the one that you mentioned is, you can never be certain the match is relevant/correct. And the reason for this is, you are always searching against a single branch/timeline. Definitions can change from one release to another. Function behavior can change from one release to another and so forth. Searching across millions of repos is not difficult, if you are willing to accept the matches returned may or may not be relevant. What is extremely difficult, is building a search solution that can take into consideration all the changes, on every branch, from the millions of repos. And this is the problem nobody is going to solve anytime soon.