I think this kind of file system would do well to power platforms that AREN'T for programmers. While this may not seem useful for programmers (because they are so involved in git usage in the first place), I think others might benefit<p>I've had the idea to make an interative design/architecture plugin for programs like photoshop/3dmax/etc rolling around in my head for a while now. Git is a perfect way to store/save the progress people make in those programs (as files change over time, or as they save), and gitfs seems like it would be the fs to run on the backing server.<p>Instant branching (like when an artist decides to riff on a new idea), undo/rollback, progress tweens/reports.
Does it batch changes, i.e. if 5 files are saved within a few seconds of each other?<p>It would also be interesting if that was combined with naming commits based on language processing (i.e. splitting on camel case and snake case, finding the word whose frequency in the current diff is most different from its frequency in the codebase overall). Then you could have human-readable history without any conscious need to maintain it - and this would be developer-friendly, just Save All in Sublime Text and fuhgettaboudit.
This seems very similar to SparkleShare: <a href="https://github.com/hbons/SparkleShare" rel="nofollow">https://github.com/hbons/SparkleShare</a>
This is reminiscent of Apple's Time Machine, except each save is the same as manually clicking "Back Up Now", and I assume that commits are more granular so directories can be committed individually rather than the whole tree.<p>I've often wondered if version control systems could be abstracted into a filesystem where each write is a commit, handling merges by choosing the local copy.<p>My primary dissatisfaction with git is that it lacks layers of abstraction. For example it should have had at least the first two distinct components listed below, something like:<p>1) git-fs (versioned filesystem, only supporting commit, clone and permissions)<p>2) git-merge (diff utility to handle merge conflicts)<p>3) git-local (two repositories wrapped in an abstraction to provide local and remote - the special sauce of git)<p>4) git-util (everything else like repair, reports, statistics, etc)<p>5) git (umbrella executable above previous layers)<p>I’m not super familiar with git console use so if it already is organized this way, great. But since it is not presented this way in its documentation, I feel that a great opportunity has been missed. We could have used git-fs the same way that people use Dropbox. Instead we have something with a lot of warts (things like .gitignore files interspersed with other files that continue the same mistakes that cvs and svn made, and the inability to save empty directories). I think git’s pattern of pull/commit/push is fantastic, but its shortcomings are so numerous that I’m going to stop knocking it right here before I get myself in trouble.<p>If gitfs ran on the Mac, I’d probably be using it right now to avoid frequent headaches where git interferes with the simplest pattern of pulling, merging by hand and pushing all files back if nobody else has committed in the meantime. I think that’s the motivation behind a library like this, because so many version control systems get the filesystem metaphor wrong and create two much friction by touting their various levers.
Nice. It looks like something I tried a while ago, but never got it stable enough for someone to actually use: <a href="https://github.com/seppo0010/gitfuse" rel="nofollow">https://github.com/seppo0010/gitfuse</a>
Awesome, I have been looking for something like this for ages. I have already two use-cases:<p>1. At work we store a bunch of IPython notebooks in a git repository (with a hook to strip them from any output and other non-essential varying data). Up until now I had to manually or via a scheduled task run "git -A; git commit -m 'Current State.'" on regular intervals.<p>2. I'm so gonna use this for my portage-tree, which is taking up a lot of disk-space on my SSD :).
Looks to have a similar use case scenario in mind with <a href="https://github.com/commandline/flashbake" rel="nofollow">https://github.com/commandline/flashbake</a>, but implemented in a different way. Hopefully it takes off.
How does it handle merge conflicts?<p>Seems like an interesting idea, my concern would be that the abstraction of a filesystem on top of git would break down really quickly once multiples users started editing things.
Why would somebody use such a file system? To make life easier when working with configuration files?
I wish they also described their motive for creating it.
Is this an alternative to cloning a repo and pushing changes or is this supposed to be used as a full filesystem? I don't quite understand the blurb.