Gitfs: Version Controlled File System
presslabs.com
presslabs.com
That is not the same thing I would think of as a version-controlled filesystem. That would be something more like the ClearCase MultiVersion Filesystem, which allows you to define versioned views of an entire filesystem. This gives you the holy grail of versioning, snapshotting, backup, restore, synchronizing entire systems, with equal treatment of text and binary files, in a way that is totally transparent to any higher-level tooling that reads and writes to these files, that developers have been trying to reinvent for 30 years because ClearCase is proprietary and very expensive.
There, they used a filesystem interface to speed up checkouts for large repositories.
Unintuitive, hard to maintain, absolutely unloved in industry, extremely expensive.
I assume it’s still sold and supported, but I haven’t checked on it in ten years.
I'm not sure how easy it is to use with anything that isn't the rest of the clearcase suite
I really like the idea of adding the work of non-tech team members (Graphic Design, Localization, Marketing, etc.) directly into Git (as opposed to requiring the devs to act as “gatekeepers”).
My main concern would be that this could end up “ballooning” a Git repo, and I’m not sure if this addresses the existing LFS issues, which would reduce its utility for some use cases (like media assets).
There’s a reason that some game studios still use Perforce (DISCLAIMER: I was a teenage Perforcer —I don’t miss it).
I think more of a barrier if they even considered it would be the FUSE dependency. I mean, of course it uses FUSE, but it makes it Linux and (with a bit of pain) macOS only.
Edit: also on HN’s front page right now: https://github.com/billziss-gh/winfsp
git is a clear, simple file format (with a horrible user space) which makes sense as the back end of far more things than it is used for. I feel like integrating this into mainline is a little bit like integrating a visual database design tool into a database server. They're complementary, but different.
Gitfs - https://news.ycombinator.com/item?id=10053176 - Aug 2015 (31 comments)
Show HN: Gitfs – mount Git repos as local folders - https://news.ycombinator.com/item?id=8735937 - Dec 2014 (62 comments)
More loosely related:
Show HN: A versioned filesystem inspired by Git - https://news.ycombinator.com/item?id=4443321 - Aug 2012 (46 comments)
Ask HN: Random idea ("gitfs") - https://news.ycombinator.com/item?id=3897817 - April 2012 (1 comment)
Git is an acceptable filesystem - https://news.ycombinator.com/item?id=3617072 - Feb 2012 (2 comments)
PhoenixFS - a versioning filesystem inspired by Git - https://news.ycombinator.com/item?id=2353162 - March 2011 (2 comments)
On the other hand for syncing notes across devices , or things like that , id say its very handy
A popular setup ( so popular it's (was?) the recommended way to setup Saltstack's configuration) is to use it to basically mount an autosynced folder from a central location ( with the benefits of revision history at that location).
IMHO it's a much better use case since you can't make conflicts and it won't result in poor (autocomitted) git history.
It's like the perfect partner - at least, from afar.
The compression into a packfile is where the diffs between files are computed and stored.
https://github.com/presslabs/gitfs/issues/333
Seems like conflicts are being resolved poorly.
> You can mount a remote repository’s branch locally, and any subsequent changes made to the files will be automatically committed to the remote.
This is not a “feature” I would ever want. That alone activity dissuades me from wanting to try this.
Explicit “commits” and pushes, like zfs?
Automatic commits are all noise.
If it’s a git client for non-technical users then it’s even less acceptable, that’s a guaranteed way to fuck up your repository.
I never thought about or considered a “git file system” before today. While a neat thing conceptually and even technically, I can’t imagine a situation where I would want a git file system. I never want to auto commit to the remote repo. I want to make sure my local changes aren’t complete shit before I committing to the remote. For me this is a solution to a problem that I don’t have.
Does this mean that every file write is a commit (which with the right tooling actually sounds very pleasant), or?
That said, this is pretty neat and I can see a couple use cases for it. If this ran on Windows there're more than a few programs worth of config directory that I'd love to use it to handle.
Time Machine and Dropbox (only in the paid version, I think) also keep copies, but (important for documents that consist of many files on disk) can’t really know which files ‘belong together’ isn a series of file writes.
Both, of course, also potentially are data leaks waiting to happen. Not only can’t you be sure that a Save overwrites an old document, you can’t even be sure that the program you’re using is giving the system that opportunity. On the plus side, these make it impossible to accidentally send out a file with (partial) content from an old version.
I don't know of any other systems that can roll back as easy and fine grained as what Webconverger can.
Well done!
> Virtual File System for Git: Enable Git at Enterprise Scale
Does it sound any similar to what this particular project tries to tackle?
I usually understand that people read mostly titles. It was a bit funny though that someone likely managed not to read both the posted site and a link in a comment they replied to.
This is basically Git checkout with an autocommit feature, making sure your grandma will be able to do check grammar in your thesis without teaching her how to Git.
Or will the file's history become unlinked?
https://github.com/presslabs/gitfs/blob/cf92acc1fdb0bf93d599...
called by: https://github.com/presslabs/gitfs/blob/cf92acc1fdb0bf93d599...
So it'll be tracked as a rename (renames in git are tracked heuristically anyway, as long as they're part of the same commit).
It's different from git-annex in that it's using git itself (git-annex just uses git to track metadata/hash to facilitate large files), but there's a similarity to git-annex's 'Git-annex Assistant' in how it "any subsequent changes made to the files will be automatically committed to the remote".
From a brief experience with git-annex assistant, I've been finding the experience of having things automatically 'synced' to be confusing and prone to issues when doing things manually somewhere else. Think it's real power may be in evolving it's user interface to be pervasive within file browers, projects like https://github.com/andrewringler/git-annex-turtle are an example.