As far as I can see the only difference in this perspective that btrfs can't do merges or rebases. Though for the simple usecase mentioned on the site I think btrfs is well suitable too (website deployment with easy rollbacks).
It's great that git is super fast, but it seems like it would be pretty horrible at handing the binary files that would be needed for actual filesystem applications.
It depends on your usecase, I guess. Of course it won’t work for an entire operating system, but it doesn’t have to work for an entire operating system: It’s enough if it works for your current coding project, your directory of private documents or even dotfiles in your home directory.
That's not the intended use, though. It is intended as an alternative interface to ordinary git repos, not as an alternative way to store ordinary file systems.
For write support you obviously have to mount a branch. Can you mount tags or commits read-only? It would be really useful actually.
Actually I can't see a use case where I would mount it read-write. For developing a website you possibly do not want to commit on every write. Possibly git's limitations on large files still apply to this implementation. For large number of small files: what does it do when I cp like 1000 files into it? Does it create 1000 commits?
Since it is a fuse filesystem you don't mount it with mount but with the command gitfs (note that there is no single instruction on the main page how to mount, not even in the demo), then unmount with fusermount -u.
Their main motivation to write this was to give their clients (publishers) a way to interact with a git-versioned project tree without having to force them to use git directly. Overall pretty amazing work!
So apparently you can mount remotes, not only local .git dirs. This is really handy and it should be listed on the main page, really.
I raises an other question: can I mount remotes where I don't have write access read-only?
For the directory structure the history directory makes sense for mounted projects that are edited with gitfs. For other projects, not so much. What about having a read only tags/ and commits/ directory too?
I agree, the main page is a little bit outdated.
You can mount remotes with where you have only read access, gitfs will fail to push something on the remote, and will put the entire repository in read-only. Right now, you don't have a read-only option, but it would be nice to have :)
Great idea about tags and commits directories. It would be nice to specify at mount point, if you also want tags and/or commits etc.
interesting to see this! the first thing that came to mind was irmin, from the good folks at MirageOS. unikernels provide an interesting opportunity to rethink block storage, as you're no longer bound the rest of your operating system.
Yeah...we know, but there is a plan of rewriting / refactoring some parts and we hope to port as much as we can from Python 2 to 3 by the end of this summer.
I accidentally upvoted your comment which is annoying as I think your attitude stinks. This is a useful project, what language it was or wasn't written in should be irrelevant. You'd already pointed out that it disappointed you, a pointless comment but fair enough, then you went on to rub it in further - was there a need for that? No.
This could be useful, especially with extended "gits" that allow for easy manipulation of large binaries, when working with creative departments who aren't used to source-code control workflows. (Even in 2015, most art departments are still a mess of external drives and drop boxes)
Nice! I wish they support fetching changes from the remote repo upon an file change event. I'd written a dropbox equivalent using git as the storage mechanism that does something similar - https://github.com/prashanthellina/pullbox. It works well, but I like hiding the interaction behind FUSE.
33 comments
[ 240 ms ] story [ 837 ms ] threadIt will probably start to be the default in Linux distros "shortly".
https://en.wikipedia.org/wiki/Btrfs#Features
Actually I can't see a use case where I would mount it read-write. For developing a website you possibly do not want to commit on every write. Possibly git's limitations on large files still apply to this implementation. For large number of small files: what does it do when I cp like 1000 files into it? Does it create 1000 commits?
I'm wondering how this would work with Git Large File Storage https://git-lfs.github.com/
https://ep2015.europython.eu/conference/talks/gitfs-building...
Their main motivation to write this was to give their clients (publishers) a way to interact with a git-versioned project tree without having to force them to use git directly. Overall pretty amazing work!
For some reason, this scares me. Is there more info on that somewhere?
Also, you can see how conflicts are solved, directly in the implementation (https://github.com/PressLabs/gitfs/blob/master/gitfs/merges/...).
Do you want to know something more specific?
https://www.presslabs.com/gitfs/docs/usage/
https://www.presslabs.com/gitfs/docs/arguments/
So apparently you can mount remotes, not only local .git dirs. This is really handy and it should be listed on the main page, really.
I raises an other question: can I mount remotes where I don't have write access read-only?
For the directory structure the history directory makes sense for mounted projects that are edited with gitfs. For other projects, not so much. What about having a read only tags/ and commits/ directory too?
You can fork it https://github.com/PressLabs/gitfs and start hacking around.
curious to see how gitfs and irmin develop.
https://github.com/mirage/irmin
Thanks for reminding us ^_^
I think a quote by the SVN developers is appropriate - "patches welcome".
Error: No available formula for gitfs
Help me please