To be clear on what this is, it allows you to mount a git repo and use writes to the filesystem to autocommit and push to the remote, effectively using git and a server to synchronize directories between remote hosts.
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.
I've done something that sounds similar with bash scripts and systemd path units. Every time I modify a configuration file from any of a number of paths I'm interested in versioning, I get a prompt to supply an optional commit message, and the change is automatically committed and pushed to remote. It's not the whole file system, but the commit messages on configuration file changes have come in handy at least once.
I used ClearCase for many years. It was a good version control system. It had a certain amount of complexity associated with it, but I thought it was fine and worked well.
I assume it’s still sold and supported, but I haven’t checked on it in ten years.
I think this is a great idea, but I would want to see it supported by the main Git maintainers (integrated into the Git Mainline —probably wouldn’t happen. It’s written in Python, and Git is C, so there’s a lot of structural issues).
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).
Git ships (usually, but technically depending on package I suppose) with 'contrib' stuff in Perl at least (e.g. diff-highlight).
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.
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.
Is the intent to turn Git into something like Jetbrains's Local History, an unbranched log of all changes on disk without commit messages? I don't think it can replace human-curated Git histories, cu but could be useful as a safety net to avoid losing uncommitted code. You probably wouldn't want to put a build directory in gitfs without a .gitignore rule though.
I don't know why most people are assuming this is mostly for enabling non-technical users to write to Git repositories.
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.
I'd be curious how well this performs with files that are changed often, and if the disk space needed to store snapshots of all the changes would grow a lot over time.
IIRC git stores copies at first - so interactive time performance is great. It later compresses a set of files into a pack - so long-term space performance is great.
It's like the perfect partner - at least, from afar.
I like the idea - does it support .gitignore though? I wasn't able to find anything in the documentation and GitHub issues seem to be confusing in that regards. If it doesn't, it might be hard to use with tools that create temporary or output files in the directory, such as compilers, LaTeX, some editors, etc.
This looks great!, but since a filesystem doesn't need most of the git features (decentralization, merging, etc). How does this compare to ZFS, btrfs, since they allow "snapshots" of filesystem to be stored and restored quickly similar to how git works.
It’s not meant for version controlling whole existing file systems. It’s for mounting git repos in the file system so that people can modify files in the repo and have them automatically committed. From what I understand from reading the readme.
I'm curious what behavior you'd expect from a git file system then? For devs and commits, understood, but for time machine like history of directories, etc seems useful for many folks.
When I clicked on "arguments" I was half-expecting it to be arguments like "--verbose" and "--noconfirm" and half-expecting it to be arguments like "why WOULDN'T I do this?" and "no this is actually a GREAT idea because...".
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.
Always thought modern oses shoukd have an on machine document management system. If vendors would implement this into their office applications we would nearly be there
Apple has had a similar feature for years in its OS. Its office suite makes use of it. https://www.makeuseof.com/tag/recover-word-pages-mac-documen...: “Every time you save changes to a document, iWork archives a copy that you can recover at a later date.”
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.
NixOS can also move between system generations seamlessly. The approach is entirely different though, the system is fully defined by its config files and will be recreated from scratch each time it is changed (except /home and /var, mostly).
VFS for Git solves the issue of having gigantic bloated monorepos used by thousands of devs, making sure user efficiently downloads only what is needed for him.
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.
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.
Sounds like it's intended for non-git-users to work on an existing git repo - editing docs, graphics, whatever and pretending it's just a bunch of files with no git - rather than particularly for a general purpose filesystem with git as automated backup / version history.
[+] [-] nonameiguess|4 years ago|reply
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.
[+] [-] tejohnso|4 years ago|reply
[+] [-] tooltower|4 years ago|reply
There, they used a filesystem interface to speed up checkouts for large repositories.
[+] [-] tn1|4 years ago|reply
I'm not sure how easy it is to use with anything that isn't the rest of the clearcase suite
[+] [-] analognoise|4 years ago|reply
Unintuitive, hard to maintain, absolutely unloved in industry, extremely expensive.
[+] [-] jes|4 years ago|reply
I assume it’s still sold and supported, but I haven’t checked on it in ten years.
[+] [-] j1elo|4 years ago|reply
[+] [-] ChrisMarshallNY|4 years ago|reply
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).
[+] [-] OJFord|4 years ago|reply
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.
[+] [-] woofie11|4 years ago|reply
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.
[+] [-] dang|4 years ago|reply
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)
[+] [-] nyanpasu64|4 years ago|reply
[+] [-] teitoklien|4 years ago|reply
On the other hand for syncing notes across devices , or things like that , id say its very handy
[+] [-] sofixa|4 years ago|reply
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.
[+] [-] yosito|4 years ago|reply
[+] [-] hyperpallium2|4 years ago|reply
It's like the perfect partner - at least, from afar.
[+] [-] krcz|4 years ago|reply
[+] [-] dmarinus|4 years ago|reply
[+] [-] codetrotter|4 years ago|reply
https://github.com/presslabs/gitfs/issues/333
Seems like conflicts are being resolved poorly.
[+] [-] Anunayj|4 years ago|reply
[+] [-] unknown|4 years ago|reply
[deleted]
[+] [-] Anunayj|4 years ago|reply
[+] [-] codetrotter|4 years ago|reply
[+] [-] hitpointdrew|4 years ago|reply
> 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.
[+] [-] gedy|4 years ago|reply
[+] [-] bastardoperator|4 years ago|reply
[+] [-] gpm|4 years ago|reply
Does this mean that every file write is a commit (which with the right tooling actually sounds very pleasant), or?
[+] [-] saulrh|4 years ago|reply
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.
[+] [-] pacifika|4 years ago|reply
[+] [-] Someone|4 years ago|reply
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.
[+] [-] hendry|4 years ago|reply
I don't know of any other systems that can roll back as easy and fine grained as what Webconverger can.
[+] [-] Valodim|4 years ago|reply
[+] [-] testing_1_2_3_4|4 years ago|reply
Well done!
[+] [-] jiggawatts|4 years ago|reply
https://github.com/microsoft/VFSForGit
[+] [-] mikevm|4 years ago|reply
[+] [-] vletal|4 years ago|reply
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.
[+] [-] unusual-name|4 years ago|reply
[+] [-] rrrrrrrrrrrryan|4 years ago|reply
Or will the file's history become unlinked?
[+] [-] kelvie|4 years ago|reply
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).
[+] [-] apichat|4 years ago|reply
[+] [-] seltzered_|4 years ago|reply
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.
[+] [-] DannyBee|4 years ago|reply
[+] [-] BiteCode_dev|4 years ago|reply
[+] [-] OJFord|4 years ago|reply