As I mentioned some time ago (here and here), I've been using git for version control and such.
I've been wanting, for a while, a way to view a git repo as a filesystem, with a directory for each commit holding that commit's working tree and some overhead stuff like branch head links. There is an existing program that might be capable of that, but it's in python, it depends on FUSE, and getting it means using github. The last of those might not, in itself, stop me from using it, but it sure raises the bar, and combined with the other two they make it a nonstarter.
A little while ago, I started looking at NetBSD's puffs(3) facility, which is support for userspace-backed filesystems. Over this last weekend, I finished (by which I really mean, got working enough that I'm putting it into what for me passes for production use) a puffs-based filesystem that presents git repos as a filesystem.
You can find the result on ftp.rodents-montreal.org:/mouse/git-unpacked (or its HTTP view at http://ftp.rodents-montreal.org/mouse/git-unpacked, of course). It's exporting my world-clonable git repos, the same ones as are listed in the git-repos file I mentioned in the aforementioned posts. There's also a README file in that directory which outlines how each repo is presented.
I'm sure there are plenty of problems with it; this is fairly new software, so I think it's too much to hope that it doesn't have bugs. If you have reason to suspect you may have run into one, please feel free to drop me a line.
I've since used a work machine to clone the Presslabs gitfs repo (the "existing program" I mentioned above) from github and, while there's no way I could actually run it even if I wanted to because it depends on a pile of stuff I don't have, the documentation makes it look distinctly different from mine.
In particular, here are some of the differences. For brevity of language, PL means Presslabs' gitfs and MY means my gitfs.
PL presents a dumbed-down view of commit history; it appears to present it as a linear chain of commits, sorted by timestamp, even if that is misleading because of multiple branches in use in parallel. MY presents each commit as a directory containing overhead information (including links to its parent commit(s), if any) and a tree/ subdirectory containing that commit's tree.
PL supports writes: if you modify things, the changes are packaged up into commits and pushed. (I have not dug deep enough to know where it gets the commit messages for the new commits from.) MY is purely read-only.
PL appears designed to operate on a remote repo, but clones it locally. MY operates only on local repos.
PL tracks changes to the repo live (it polls the repo, at intervals specified in its config). MY does not notice changes to the repo (I would like to change this, but for my major use, exporting an FTPable view of my repos, it is of only minor importance).
PL is in python, with, I think, python bindings for various packages providing the FUSE and git support. MY is in (slightly extended) C, running git subprocesses for most of its queries, using, as I mentioned above, NetBSD's puffs(3) infrastructure for the filesystem interface.
PL handles one repo. MY handles (potentially) many.