Colin here (I'm the "named employee"). I don't mind being called out, FWIW. I'm proud of what we built.
We would definitely have implemented sorting by recency if it was trivial to implement. But as I said before, our data shows that it is infrequently used, and to scale our search index, we designed it in a way that makes this kind of sorting tricky.
Sometimes to ship products like this, tradeoffs have to be made, and I continue to think we made the right one. Nevertheless, it's good for me and the team to hear feedback like this so we can continue to improve the product.
It would be really awesome if code search could one day consume LSIF for precise results in its index similar to source graph. The symbol search is good now, but approximate. Having more precise code search by allowing devs to upload LSIF data in their CI pipelines would allow for precise symbol search (go to definition / find usages actually being accurate) and remove irrelevant result.
Great point. Yes, we initially focused on zero-config approximate code navigation. But we do intend to support build-based code navigation in the future, since the approximate code navigation experience can be pretty poor for some languages (e.g. C/C++).
Great stuff, is there any update on searches which include code in branches? I often manually find interesting work done in development branches of cloned repos of the one I'm focused on but which never sees the light of day and not found in search. I imagine having the network also part of the search would be a good facet.
I've been using it for a few weeks, and it's a great improvement, congrats on the launch.
(Pleeeease make the right click context menu just be the normal default menu though, I (apparently) "Right-click > Back" a lot when using a mouse rather than a trackpad and I keep getting that goofy Emoji dialog.)
Loving the new Code Search! Might be super specific, but is there any syntax for searching attributes in HTML elements. For example if a React Component called <Button ...some-props color="red" /> what's the best way to find all the buttons that are red?
I imagine a future in which this is integrated into vscode so I can go from an error message in the terminal to a search through my code + third-party modules that my code is importing
Hey saagarjha, thanks for the feedback. It's our goal to make the experience as good as possible, and we're aware of shortcomings with cmd+F and `t`, among other things. We're working on it, and your feedback helps us a lot.
We read all the feedback on the forum here: https://github.com/orgs/community/discussions/38692, so please keep providing it. Videos and screenshots are super helpful too. Thanks for bearing with us as we continue to polish the UX!
Hey everyone, I'm Colin from GitHub's code search team: happy to answer any questions people have about it. Also, you can sign up to get access here: https://github.com/features/code-search
Hi Colin, I’m curious as to how you search repeated letters through ngram index? I understand the example search with the string “limits” (find intersection of “lim”, “imi”, “mit” and “its”). However, if the user wants to search the string “aaaaa” how would you go about searching that?
Good question. We still construct ngrams for it, exactly the same way. So for example, we might extract `aaa`, `aaa`, and `aaa`. Or we may extract `aaaa` and `aaaa`, or perhaps `aaaaa`. Then we deduplicate to find the unique ngrams and look them up in the index.
So it's possible that a document containing `aaa` might match our ngram search, but we double check after retrieving them and exclude them from the result set.
Have you considered using an index directly on language tokens (eg. the abstract language tree representing the file) instead of ngrams on the source text?
Actually, our search engine is so fast that syntax highlighting the search results is often slower than finding them... so if we store the language tokens directly in the index, we'll be able to directly emit syntax highlighted snippets and make it even faster.
It may also enable some interesting search capabilities in the future, like searching within comments or by code structure.
We're not using server side rendering extensively at GitHub (yet) but are experimenting with it on some React pages. Hoping to make the pages even faster than the previous Rails/ERB pages
I'm one of the engineers at GitHub who was behind this new UI, let me know if you have any questions. We chose React for this code search/code view because it has a lot of interactivity, and it has worked well so far.
And we do intend to write a blog post with more details in the coming weeks.
I was not expecting to see this comment at the top of this thread but since it is here… this UI really sucks on mobile (at least on iOS).
A couple of immediate problems:
1) I am no longer able to visually distinguish folders from files, where did the folder icon disappear?
2) Swiping back is weird, sometimes it does work, sometimes it doesn’t. When it doesn’t, it either leaves me with a blank screen, or loads back what I just swiped away.
3) This really aggravates me, swipe back doesn’t preserve scroll position on long file listings, it renders the contents and scrolls to the top. This is really bad.
4) Where’s the footer?!
5) The whole thing just feels slow.
GitHub ui is getting worse on mobile as time goes. For example, why can’t I fork a repo from the mobile page?
I don’t know how you measure how your UI is used but I don’t think me browsing the code while sitting on the throne, or looking up a piece of code while laying in bed is so unusual. Maybe some of you should try that before such half baked stuff is released with much fanfare. Because the way I read it is “we’re excited to announce that we have broken your GitHub experience”.
Yep, aware of these mobile issues and are actively fixing them, will hopefully improve in the next week or so.
And thanks for the feedback. We're in Beta right now exactly so we can get feedback so please don't hesitate to reach out (in-app, via Discussions https://github.com/orgs/community/discussions/categories/cod..., or any other way you can reach us), even if it's something minor
We have fixed it behind a feature flag that isn't yet rolled out. Still experimenting with it. But expect to see that resolved in the next couple weeks
Positive feedback feels nice, but negative is way more useful to making a great product.
We're changing an website that millions of people use every day. Hopefully we mostly have a positive impact. But if we're making it worse, even in a small way, that matters a lot to be aware of.
Very true. I love “negative” feedback. But I don’t know how to not take it personally sometimes. It often feels like a failure. Especially when it’s a “darn I should have caught that!”
Everyone fails sometimes. Take every failure as a learning experience. Taking it personally and feeling emotions doesn’t actually help the problem - that you made a mistake and need to just learn and move on. Focus on the future, on the problem, on now, not the past. If however you make a mistake and get defensive and don’t learn anything then yeah it’s only a toxic thing on you. Learning from it helps you grow.
Masters of subjects don’t learn overnight. They learn over years, decades, a lifetime. In that time they make countless mistakes. But they persevere and don’t let it affect them emotionally and they grow into those masters.
I make mistakes daily. I’ve thrown away hundreds of thousands of lines of code in my career because it didn’t work as expected. But each time I grew a little and learned something to make the next iteration better.
When viewing code I like the feature, however, when browsing folder structures it is a completely redundant feature. And just adds visual clutter. This feels like a half-step between an editor and a static file listing. I would personally prefer either a very static view of the core, in pure html, or an interactive experience (Ctrl+.) for opening vs-code on the repo.
Secondly, the code search feature is nice, but is there a reason why it has to be a column to the right, couldn't it be part of the editor, like we're used to in most editors nowadays.
A gripe I've had recently with github, is just that it all seems so slow. It feels like trudging through mud, it may be, because I don't live in the US. But this is getting out of hand, and makes me want to consider leaving it for something else.
Sorry for the rant, I like progress, I just don't like unneeded complexity, especially for a tool I love =D
Not sure what you mean by that, can you elaborate?
FWIW we are working to more tightly integrate code search into the code view.
And absolutely, performance matters a lot to us. Sorry for the slow experience, you're not the only one, particularly outside the US. Only thing I can say is we're working on it.
Sorry miss-spelled. Meant static view of the _code_. Ie. Just a file listing with the option to view the code, like you've always had.
Anyways best of luck to you. It hasn't been an easy year for github with the downtime earlier in the year, and what I would expect to be a nasty migration from a monolith =D
How much, if at all, has anticipated and/or apparent stabilization of React Server Components factored into this [expanded] technology choice? Can you speak to considerations of other component frameworks?
I… guess I offended someone by asking what I thought were totally innocuous, curious questions that they invited. Of all the fucking things to downvote! I mean, by all means tear this’n to shreds. But if anyone has a problem with my questions above could you please be bothered to say why?
GitHub has been investing in React for a while (e.g. see our accessible React design system https://primer.style/react/). Many developers at GitHub have experience with React, which helps. And the tooling is just more mature (IMO)
Marko is tailored for that. Solid has mostly focused on highly interactive SPAs until very recently. Solid’s creator also worked on Marko and has written a lot on the subject. But even so he mostly deferred to Astro for mostly static use cases with Solid until the most recent release (Solid/SolidStart) officially supported partial hydration.
This is just the first step of using React within GitHub.com, so we still use a lot of traditional Rails/ERB, even on the React pages (e.g. for the header/footer).
Hey, I’m the developer of a popular tool for searching all of public GitHub for sensitive information (GitHub.com/tillson/git-hound) … would love to get access to play with it and see how it can improve secret detection. github.com/tillson
Interesting because on https://lsif.dev/ I see that LSIF support for C++, which basically is just a wrapper around clangd AFAIU, is deprecated. Is there something else that replaced it?
Hey, I'm on the GitHub code search team. We've had a ton of people join the waitlist, sorry it's taking so long to get through everyone! We're hoping to get most people access early in the new year. Stay tuned!
Is there a list I can sign up to stay on the old code search forever? I'm really sad about the loss of old repos - I found that invaluable for finding interesting projects to learn from.
We would definitely have implemented sorting by recency if it was trivial to implement. But as I said before, our data shows that it is infrequently used, and to scale our search index, we designed it in a way that makes this kind of sorting tricky.
Sometimes to ship products like this, tradeoffs have to be made, and I continue to think we made the right one. Nevertheless, it's good for me and the team to hear feedback like this so we can continue to improve the product.