Fetching latest commit…
Cannot retrieve the latest commit at this time.
|Failed to load latest commit information.|
*** 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 <email@example.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?)