Wouldn't be nice to press <C-x C-f> (find-file) and instead of a file path, give it a GitHub URL, and then just browse the repo in Dired?
Comments
Pay08•3h ago
Really neat. Out of curiosity, does this need to use the Github API? I hoped something like this could be done with plain http.
iLemming•2h ago
Of course it needs to use the API. How are you otherwise read the private repos?
necovek•2h ago
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.
iLemming•2h ago
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.
v9v•28m ago
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).
Pay08•3h ago
iLemming•2h ago
necovek•2h ago
iLemming•2h ago
- 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.
v9v•28m ago