Show HN: Gitfs – mount Git repos as local folders
presslabs.com
presslabs.com
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.
Instant branching (like when an artist decides to riff on a new idea), undo/rollback, progress tweens/reports.
Pulls won't be so bad if your machine already has all the commits, but cloning would be a nightmare. And it'll be taking up a lot of space on your git server.
git stores full blobs, not deltas.
In the context of the discussion, since we're interested in the on-disk format, it's more accurate to say that git will try to diff binary blobs, fail at that and so store the full content of blobs.
These tend to be things which are compressed or encrypted, where a small semantic change can cascade into a lot of bytes changing. Of course, binary formats often do both of those things. And the larger the files, the more painful it is when it happens.
Also, if the person is working with SVG (for example), then it's less of a problem.
Also, given the cheapness of disk, I don't think it would be a limiting cost. And since git is open source, if I were to actually make this thing, it would definitely incentivize me (or others) to make git less bad for storing binary files :)
With git packing, the full repo with a bit of history (mostly adding some php and a few images) ended up smaller than the original windows native folder. Version control and compression; nice :)
Hah, same idea here. I used to live with 3d artists, and I asked "How do you live without Git?!", they said they version their files into milestones (e.g. environment-milestone1.3ds) and upload them all to Dropbox.
I think Git wouldn't gain as much traction as you'd expect, there's just easier (for non-programmers) alternatives with a large userbase.
Yeah, I'm not really planning on introducing them to git, more using git behind the scenes to get all those good qualities (undos, infinite history, instant backup) that someone might think was hard (that didn't know git)
You generally have the option of either using lots of data and bandwidth (think: storing rendered 4/8K jpeg2000 frames of animations, for each new version/cut/render you want to keep) -- or tight integration with the various software involved (ie: only keep latest "render" -- and a track of changes/a "script/log" that can be used to render/generate all the missing versions).
I'd think in general 3d meshes shouldn't be too hard -- but good luck finding someone doing media that don't use some big bitmaps somewhere (textures, backgrounds, etc).
This is also a pretty crowded market place with pixelapse, layervault, etc.
And yeah, I know it's been done before -- but that only proves that the market is there, and more importantly investors (notably YC) think it's worth it to pursue.
I doubt I could do as great a job as some of these products and their engineering teams, but then again, I don't know that I have to. I think it'd be a fun open source project.
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.
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.
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:
1) git-fs (versioned filesystem, only supporting commit, clone and permissions)
2) git-merge (diff utility to handle merge conflicts)
3) git-local (two repositories wrapped in an abstraction to provide local and remote - the special sauce of git)
4) git-util (everything else like repair, reports, statistics, etc)
5) git (umbrella executable above previous layers)
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.
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.
What is mount.fuse?
I installed Python fuse.py... still poking around...
I double checked the install - that everything linked properly etc.
For OS X users do this:
/usr/local/bin/gitfs <remote repo or local git parent folder> <any/mount/folder>
and then you'll see a new volume mount on the desktop like "OSXFUSE Volume 0 (python 2.7)"
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.
2. I'm so gonna use this for my portage-tree, which is taking up a lot of disk-space on my SSD :).
I hope it puts "update" as the commit message ;)
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.
Do you have in mind a particular use case?
Reading on "history" has a small performance penalty since if you are reading files which are packed they need to be unpacked on the fly.
Listing the "history" is quite fast. We tested on the WordPress repository that has around 17k commits and it takes ~4s first time and less than 1s afterwards.
Here's the use case I have in mind: let's say I'm a programmer extending a game [1] built on Undum [2] engine, together with a writer who is writing a story at the same time [3]
[1] The Play, A dress rehearsal gone horribly wrong, by Deirdra Kiai. http://squinky.me/theplay/
[3] Story file: view-source:http://squinky.me/theplay/theplay.js