Skip to content

Comment on Long Read: Lessons from Building Semantic Search for GitHub and Why I Failed

Comments

* No way to search across multiple repos within GitHub. > * No way to easily see open and closed issues in the same view.

I don't quite understand, because searching issues across all of Github and also within orgs is already supported. Those searches show both open and closed issues by default.

For searches on a single repo, just removing the "state" filter entirely from the query also shows open and closed issues.

I do think that semantic search on issues is a cool idea and the semantic/fuzzy aspect is probably the biggest motivator for the project. It just felt funny to see stuff that Github can actually already do listed at the top of motivating issues.

GitHub search is pretty unreliable from my experience. Search results are limited to 1000 items, and you never know if the index you’re searching against is up to date — unless a file has been opened recently in GitHub web UI there is a significant and unpredictable delay between a commit and the indexing.

So far I’ve been very happy with Livegrep, we are using it to search across ~10k repos, the index is rebuilt once an hour with a simple cron job. Searching is insanely fast, it’s using very little resources, just a simple computer engine instance. The main downside is the lack of multiline search, but so far that hasn’t been too much of a problem.

AboutSource Built by g1lg1l

Hackerly is an independent reader for Hacker News, built on the public HN API. Not affiliated with Y Combinator.