Hacker News Reader

Comment by welder | Hacker News Reader

They list things like "Fast" and "Regular Expressions", but what about correct results? I often use GitHub web search and it never finds terms which I know for a fact exist. After it fails to return results, I have to instead manually navigate to the file containing the search term and yes it's there.

View on HN

(I gave this talk and work on code search.)

Sorry you've had a frustrating experience with the product. When we look into complaints about missing results, it's almost always one of two things. First, the repository is not indexed yet, but searching triggers indexing. Future searches work. Second, the files or the repo hit our documented limitations (https://docs.github.com/en/search-github/github-code-search/...). I think these limits are pretty reasonable, but we need to do a better job making it clear why content isn't in the index.

When a user search includes a non-indexed repository, GitHub needs to include a warning message along with the search results, something similar to what you just mentioned:

"One or more repositories of this search is not yet indexed, please try your search later for accurate results."

Likewise for the 2nd case.

For the repositories not in the index, we do show a message to try again later. For documents that have been excluded, we agree we need better visibility.

Do you list the repos not in the index?

What does "Exhaustive search is not supported" mean? (that phrase is from your link, in the bullet-points near the top)

It means that we have a result limit. If a term matches in a lot of files, not all the hits will be shown.

> First, the repository is not indexed yet

I understand this is important. But the issue I have is that it’s hard or maybe impossible to know what’s been indexed and what isn’t.

I run a few orgs with hundreds of repos. Which are indexed? I don’t know.

This makes your search suck for my organization. I understand the reasons. They aren’t reasonable for me. I don’t want to search using your tool if it won’t work for my org.

Code search isn’t just for what’s popular. It needs to be for what is real and accurate.

Yeah, we need to do better on the visibility of this for owners. And we're trying to scale the system so it's not a problem at all. In the meanwhile, you can ask support to index all the repos in your orgs and we can take care of it.

The new UX does a really bad job of helping you realize when you're logged out and search results are being suppressed. It very much implies "zero results" when in fact it means to say "zero results, except in code, where there might be results, but you need to log in first to find out".

Weird, I've never found that to be the case. There's a "flash" sort of message right at the top of the search results that says "Sign in to see results in the `x` org"

Sure but I was talking about incorrect results when logged in, and for public repos.

Yup I was about to write something about how I quite literally clone & grep code bases after GitHub search fails probably half the time.

For repository wide search

   1. Press dot "."
   2. CTRL + SHIFT + F
   3. Enjoy results powered by rg (ripgrep)

I just use sourcegraph it's faster than cloning usually.

Source graph is nice but completely overpriced. I have 500 people who want to search, maybe 1000. I’m not paying $100/user/year forever when I can just clone all thousand repos onto a drive and let people grep it.

Grep is not as good, but the cost is like $500/year for infinite users vs $50m/year with a marginal cost for new users.

Also, my general comment on pricing applies here. Copilot is $100/year. So I’m supposed to think being able to search my code is the same price as being able to write the code.

Also, they are kind of in trouble because this will exactly be replaced once I just fork over $500/user/year for superchatgpt and it will definitely cover code search.

GitHub search used to be amazing, then circa 2019(?) they nerfed it, I think because of security credential leakage.

Nah, it's always been unreliable. Around 2016 a coworker wrote a code indexer for our private repos and we used that to find occurrences of things which were critical.

We've been burnt sooo many times ('are you sure we changed all the occurrences of this in all our 3252 microservices?').

Between shoddy UX (the + being part of the code you were copying!), blatantly missing features for years (ZenHub, late GitHub actions), GitHub really succeeded only because of timing and network effect. The developers' community is quite powerful.

I'm happy for the original team, but now it's just another MS acquisition I hope we'll stop using.

Reply on news.ycombinator.com