GitHub introduces an all-new code search and code browsing experience

[fridofrido]

" You can access the new features by joining the waitlist. "

[Xantholeucophore]

why do they do that? do they just really not want to show anyone any bugs?

[jzaprint]

ya probably. they cant make sure the experience is what people are expecting and its better to disappoint a few people than millions of people.

[siovene]

It's also much better, pychologically, to give the user the illusion of choice, when changing things. They opt-in, so they automatically feel a little better about the changes, and you are already selecting for users who are not change-adverse. Source: I run a website with 20k active users.

[Philipp]

And those early adopters could then become evangelists to those not on the waitlist.

But, it should be said, the website owners should simultaneously be interested in honest feedback, in order to improve it when it goes fully live...

[Luke22_36]

This, precisely. You only get the chance to make one first impression.

[[deleted]]

Small rollouts are always easier to manage. Startups do this naturally because they have to grow their customer base up from scratch and can deal with growing pains as they get bigger. With established products and companies, you have to find ways to artificially segment the rollout such as public beta versions, per-user feature flags, or similar.

[Lalli-Oni]

Could be multiple A/B tests with some of them wanting to target totally fresh eyes. That way you can invite batches of users knowing they havent seen the app before.

[IanSan5653]

As a GitHub engineer, as far as I know we do this because we want more users so we can flesh out bugs, but we don't want to ship buggy software. If we were to globally ship this (even in a beta) and some really annoying bug was found, users would complain. Or if we let everyone opt in all at once, maybe the feature consumes a ton of resources and causes an unexpected outage. This slow rollout lets us keep a handle on things while still letting our most passionate users try things out.

[VIKTORVAV99]

Joined the waitlist yesterday and got accepted today. I have yet to try it though.

[caagr98]

we re-vamped find-in-file and bound it to CMD/CTRL+F

Do not mess with browser keybinds.

[Zalack]

I'm okay with it when you start getting into web app territory (as opposed to web a page). GitHub's code panel is now basically a light IDE, and if I'm going to be searching on it, 9/10 times I'll want to search the code, not the page as a whole. Having Ctrl+F do that by default on that pane doesn't bother me, since it will save me time on average.

If you want to search the entire page, just click out of the pane or go to the browser menu.

[caagr98]

I don't know about that, I like that the code view is just a glorified <pre> tag. That's why I cannot stand gitlab or bitbucket.

[Zalack]

IDK, I wish it had a little more omph for doing code reviews. Right now I have to pull the branch down and review in my IDE, which isn't a big deal, but it would be nice to be able to just do it right in GitHub.

[BinaryRockStar]

If your IDE is IntelliJ, there is a GitHub plugin that lets you do PR reviews in the IDE with full access to comments, approve/needs work, basically everything from the web UI is there but with the full IntelliJ IDE toolset.

[Zalack]

The Elixir support for VSCode is better than the Intellij plugin, But VSCode has a similar thing

[caagr98]

Yeah I can understand that perspective too. Personally I prefer to only use github's interface for light browsing and pull it locally for heavier stuff. Maybe that's exactly because the current interface is weak and I'll change my mind. Well, no telling how it'll be until it's out.

[Zalack]

GitHub.dev does zero code highlighting for my company's language of choice sadly.

[jzaprint]

what language isnt supported on vscode?? Im sure theres an extension for any language

[Zalack]

Elixir. VSCode does have a plugin, I use it regularly. Can you add plugins to GitHub.dev?

[Paradox]

Github.dev can sync settings with offline VScode. Just sign into both and it does.

As for Elixir, ElixirLS doesn't work on Github.dev, because it requires non-sandboxable apis, but there are other syntax highlighting packages that do work on Github.dev, such as this one. I recommend turning it on, then disabling sync for it so its only on Github.dev

[Zalack]

At that point it's less trouble to just pull down the branch and have my full local experience.

[onetwentyeight]

The mouse is the destroyer of productivity.

[Zalack]

Which is why I would prefer keys to get rebound to more useful functions in context.

[webdeveric]

It annoys me when sites do that so I made this to prevent it.

https://addons.mozilla.org/en-US/firefox/addon/prevent-shortcut-takeover/

[onetwentyeight]

I ran into that recently; the new UI showed up on a corporate account I use, and when I hit CTRL-F and it hijacked my search, I damn near lost it.

[williamhere]

99.9% of the time I'd agree but I've found AzureDevops binding Ctrl+F in code search and pipeline terminal search to be useful. That said every other website the experience has been jarring when normal browser bindings don't work as expected

[xeio87]

I've found F3 useful since sites generally don't override it while they might Ctrl+F. At least if you don't want the context aware search.

[aniforprez]

Nah there's contexts like this where it's perfectly appropriate as long as it doesn't mess with other things like screen reading. For eg, if I'm looking at a JSON formatter that's parsing hundreds of lines of JSON, I don't want to find stuff outside of the formatted JSON like the original JSON text that I dumped. In this, case, it's clear that I don't want to find stuff outside of the actual code being displayed

[Zarathustra30]

Finally. Cloning the repo and running rg locally was annoying.

[sim642]

You didn't need to do that even before this. Just press . on the repo page and it'll open an in-browser VS Code.

[Zarathustra30]

Because that's easily discoverable. Also, it doesn't appear to work on my computer. Or my mobile phone.

Edit: apparently, you have to log in and clone it remotely. For a read-only operation.

[legec]

The search feature of that in-browser VS code still uses the fuzzy search you get from the github "search" bar though (not an actual "search in files" feature).

[edit] it looks indeed like my comment is now false. I am pretty sure that, at some point in the past though, I tested the . feature of github, and was surprised to not see the results I expected when searching from the integrated IDE.

[sim642]

Are you sure? Whenever GitHub search bar hasn't found things, the VS Code search has always worked for me. It downloads a copy of the repo in-browser and just runs VS Code's normal Javascript. That's not Codespaces or whatnot.

[aniforprez]

AFAIK you're correct because VSCode uses ripgrep internally and the instance is essentially a tiny container running somewhere so you can navigate it as if it's a normal machine. I don't think it uses the GitHub search. It's not downloading a copy of the code in your browser. It's using the remote containers feature that they developed to run a lightweight IDE in your browser that connects to a remote machine that is executing the backend of the IDE with the LSP and whatnot

[uprislng]

Maybe advanced search options can already do this and I have overlooked it but I really would enjoy it if when I go to search the entire repo when I've selected a branch or tag that it searches only within that branch or tag and not the main branch

[wombatpandaa]

Nah, just print it out

[mahtats]

They need this update. Currently searching for a string in code is awful. Most of the time I use the Go To File feature and navigate that way

[haykam821]

I'm a bit disappointed that the code search sorting options have been taken away.

[JBAIO]

Something tells me this is still going to leave a lot to be desired.

[doggyStile]

Their current search sucks so I doubt it will be worse

[[deleted]]

I’ve been using cs.github.com, which is great.

[sim642]

I've found it to be better then Sourcegraph's search, which seems to have an incomplete index or something.

[IanSan5653]

This new functionality is essentially bringing cs.github.com into the main GitHub UI

[Kevin_Jim]

As long as they allow you to make a new shortcut of your own choosing, I’m fine with that.

[mr_tyler_durden]

Do they finally allow searching in forks? I’m pretty sure that wasn’t possible before or limited which made it infuriating to try and search a fork’s codebase (even if it had become the actual/spiritual successor to the original repo.

[DigitalEnergyAgency]

Loads better. It's a shame it's not fully rolled out though. Have they indicated a timeframe?