What I want at this point is a classic.github.com which uses the old UI from 2013. That was perfect and fast.

Really neat. Out of curiosity, does this need to use the Github API? I hoped something like this could be done with plain http.

I use https://github.com/TxGVNN/github-explorer for this and even though it doesn't have a C-x C-f nicety (you just m-x github-explorer then type in the repo name) it works via http (or at least I don't recall giving it any API key or anything).

Authenticated HTTP or even SSH should allow it, especially if you are restricting to GH and know how their web URLs translate into git repo URLs.

Ah, okay. I get now what the question meant. Sorry, it's past midnight here and my brain is ketchup. Git's own protocols let you talk to a remote repo without cloning it, so why not use that, right? Multiple reasons:

- Tree listing. There's no raw HTTP URL that gives you a directory listing. raw.githubblabla.com can't do directory indexes. You'd have to shell out to git ls-tree ... etc over the ssh, which means essentially implementing a partial git client.

- Getting subtries is also problematic

- Branch listing and repo search - no git protocol equivalent for those - need the API

- Current approach fetches the entire tree in one API call. Doing the same over pack protocol means negotiating a fetch, receiving packfile data and parsing it. Much heavier, much more code.

We can only imagine a world where git's transport layer gives you a browsable filesystem interface. It doesn't - git's protocols are optimized for syncing object graphs, not random-access file browsing.

r/emacs discussion https://www.reddit.com/r/emacs/comments/1sutzz6/new_package_...