11–20 of 32 posts
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.
Or you could, you know, clone the repository into a local working tree.
Earlier quoted context omitted.
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
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.
Or you could, you know, clone the repository into a local working tree.
Earlier quoted context omitted.
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.
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...
Maybe to use existing file-based indexing and search tools? I must be missing prime use-cases here.
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.
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...
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.
Or you could, you know, clone the repository into a local working tree.
> 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.
Any plans to add support for gists to Hubfs?
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?