HUBFS is a file system for GitHub and Git. Git repositories and their contents are represented as regular directories and files and are accessible by any application, without the application having any knowledge that it is really accessing a remote Git repository. The repositories are writable and allow editing files and running build operations.

Have you ever read this HN comment from 2007 before? [0]

> I have a few qualms with this app...

Different paths towards the same outcome should multiply, so we can increase the surface area of the bandages on the different pain points along the way.

[0] https://news.ycombinator.com/item?id=9224

Snarky drive-by comments like this are the worst part of HN.

that's why lobste.rs was created.

Any chance you have an invite and are feeling generous?

That works well for small repos or a few repos but if you want to find all cc files, at all release branch's, in your entire company and check for some exploit it is helpful to have a VFS. Makes it so you could also support N SCMs through one API. You just need to make a new VFS.

Isn't there already a good way to push computation closer to the data?

GmailFS and pyfilesystem (userspace FUSE) and rclone are neat as well.

https://stackoverflow.com/questions/1960799/how-to-use-git-a... explains about the `git push` step that git-remote-dropbox enables: https://github.com/anishathalye/git-remote-dropbox

GitHub also has a code search now: https://cs.github.com

Needing to tie into a specific API (like codesearch) couples you to the specific storage backend (Github). If you build your software to operate on a POSIX-y file system, you can support anything that shows up as a file system. For example: A local working tree of files, an NFS share, or now a remote git repository.

Running the code where the data already is saves network transfer: with data locality, you don't need to download each file before grepping.

Locality_of_reference#Matrix_multiplication explains how the cache miss penalty applies to optimizing e.g. matrix multiplication: https://en.wikipedia.org/wiki/Locality_of_reference#Matrix_m...

Stop for a moment and consider what the tradeoffs of that could be and why it might not work well in some situations.

- Higher latency

- Less efficient use of bandwidth, as the git protocol is optimised for bulk transfers

- Not resilient against unreliable connectivity

- No support for repositories not hosted on GitHub

Yes, I can think of some.

I've often thought of using git/github as a document store to replace google drive. I might experiment with this and rsync to see if that makes it possible.

So this is allowing remote git repositories to be treated as a regular filesystem. I really cannot think for good use-cases for this.

Maybe to use existing file-based indexing and search tools? I must be missing prime use-cases here.

Browsing source code of third party libraries that you're using?

This could be especially nice with some debugger integration, if you could just step into a library function, and have the corresponding file opened via hubfs...

Just………clone the repo?

Yes, and then locate the correct file in it etc.

Or, we could just have the computer do it all for us.

Your company keeps some things on GitHub but not everyone in the company wants to learn git, the command line, the concepts around git.

Like ssh into your server with GitHub actions

Very cool! I love using GitHub repos and gists for managing my personal notes/code snippets, and currently use GistPad as an editor-level virtual file system (for VS Code). But having an OS-level equivalent is _super_ useful.

Any plans to add support for gists to Hubfs?

Gists are just repos under the hood, it should work natively.

Yeah good point! Though I was also thinking about the ability to easily create/edit/delete gists, by means of file system operations. For example, it would be pretty cool if you could create a directory in some “gists” mount point, and have it transparently create a gist for it. Then, as you add/edit/delete files in that directory, those changes are reflected in the gist’s repo.

I don't think the filtering they mention for security actually works? Anybody who clones a repo on GitHub can make their own commits appear under the original org url when accessed by ref.

This is cool. I often want to open random files from random GitHub repos in a proper text editor but can't be bothered to pull the whole repository just for that.

If you are signed in, you can hit '.' on your keyboard when browsing a GitHub repo to open it in VS Code in your browser.

I do not understand what problem solves

Does it support snapshots?