*** Little to NO testing has been done so far ****
*** Use at your own risk. ***
*** Currently not even Alpha Quality. ***

A FUSE based filesystem for using Git as a disconnected storage server
with local cache.  This is not designed to save space on the local
server.  It is designed to allow disconnect operation and still have a
hope of keeping files in sync across many devices.  There are likely
better ways to do this.

Now supports minimal ~/.gitfs/fstab.  The easiest way to get started
is to use gmkfs.py.

gmkfs.py <git-repository> <local-directory>

will create the shadow directory and a basic fstab entry in
~/.gitfs/fstab, and do a git pull to populate the shadow directory.

Then gmount.py <local-directory> should mount the filesystem and you
will be ready to go.

gsync.py stops the file-system server and does a commit, pull,
mergetool, push sequence to allow for manual merges and forcing a
repository to be up-to-date.  Useful if you plan on doing a remote
build.

To manually mount already existing git repo:

python GitFS.py <remote-name> <branch> <local_repo_dir> <local_dir>

To unmount use

umount <local_dir>

Licensed under the GPL V3 license.  See the file COPYING.GPL for more information.

Based on gitfs.py with the following copyright:

    Copyright (c) 2011 Sreejith K <sreejitemk@gmail.com>
    Licensed under FreeBSD License. Refer COPYING for more information

    http://foobarnbaz.com
    Created on 11th Jan 2011

Note that according to the original license, the above copyright notice must be preserved.

***** XXXXX Warning, design flaw: *****
It appears that the original gitfs was based on a simple example that
comes with fuse.py.  The example has a design limitation in that it
can really only work with fast repositories.  Otherwise, the kernel
fuse code will time out and disconnect the file system.  The obvious
solution is to separate the code that accesses git from the code that
accesses the data.  This requires creating a log so that the
filesystem can read and write while the files that git sees are
stable.  So a simple log is being implemented.  The first incarnation
will have nothing to prevent it from growing too large, or for
cleaning up caches.  Later implementations may contain such code.
***** Fix in progress, no ETA *****

Still very basic and untested, but as everything it has lofty goals.
It should be usable now.  The important thing to understand is that
currently certain characters are escaped when they appear at the
beginning of a filename.  Currently, the escape character is '@' and
the characters that are escaped are '@' and '.'.  This means that any
files in the git repository that you are mounting that start with '@'
or '.' will not exist in the mounted file system.  This makes it
possible to use git inside of a GitFS file-system.

Currently, any changes are committed after one minute if the repository
is on a reserved subnet, and 10 minutes if the repository is on a
public subnet.  Eventually this should all be configurable via a
configuration file stored under "@gtifs" in the root directory of the
mounted repository.

All the fancy features are relegated to git.  So if you have some idea
for a wiz-bang feature to add, odds are you are better off adding it
to git.

TODO:  Everything.  But in particular:
Finish support programs:
 gmount -- The command-line arguments will almost certainly cause problems right now.  Just use options.
 gmkfs -- Works in the simplest case, YMMV
 gumount -- the same as umount, so not a priority.
 gsync -- force a sync outside of GitFS.  Useful to do something like gsync && ssh build-host bash -c 'gsync && make'
 gbuild -- to wrap the above command line into something useable

and of course, lots of debugging.

Other ideas (in no particular order): 
    encryption at the fs level
    allow the local repository to be shallow without all the issues that normally causes (save local space)
    Allow gmount to mount the repository as it was at a certain point in time (auto branch?)