I've uploaded another pre-release of my gitfs tool. I haven't had much time
to work on it lately, so not much has changed since the last release a
year ago:
http://www.gelato.unsw.edu.au/archives/git/0511/12617.html
However that version no longer works (or even compiles against :-) the
FUSE API in recent linux kernels so I figured a fresh tarball would
be nice.
Changes:
* Added a configuration subsystem. Isn't used for much yet
* At the top of each tree there's now a synthetic ".git" directory
which includes some symlinks and a "HEAD" file that points to
the currently viewed root. The idea is to allow some simple git
commands to work inside of a gitfs directory. Unfortunately this doesn't
work yet since git no longer recognizes a non-symbolic ref in "HEAD".
I'll try to work around this soon.
* Various bug-fixes, etc
As usual tarballs are available at:
http://www.sfgoth.com/~mitch/linux/gitfs/
Sorry, I still haven't set up a git repository for it yet.
Jakub Narebski wrote:
Not true. Symlink HEAD still works, and we have even core.preferSymlinkRefs
configuration variable.
Yes, but it has to be a symlink pointing into "refs/", not just a regular
file holding a hash value. Which is fine for most purposes but sort of a
pain for me.
I'll probably have it be a symlink to "refs/gitfs-dynamic" or something and
then have "refs" be populated with that synthetic file and symlinks to
any of the normal contents of the refs directory. Not too bad, but will
take a little bit of code.
Mitchell Blank Jr wrote:
* At the top of each tree there's now a synthetic ".git" directory
which includes some symlinks and a "HEAD" file that points to
the currently viewed root. The idea is to allow some simple git
commands to work inside of a gitfs directory. Unfortunately this doesn't
work yet since git no longer recognizes a non-symbolic ref in "HEAD".
I'll try to work around this soon.
Not true. Symlink HEAD still works, and we have even core.preferSymlinkRefs
configuration variable.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
Mitchell Blank Jr wrote:
Jakub Narebski wrote:
quoted
Not true. Symlink HEAD still works, and we have even core.preferSymlinkRefs
configuration variable.
Yes, but it has to be a symlink pointing into "refs/", not just a regular
file holding a hash value. Which is fine for most purposes but sort of a
pain for me.
I'll probably have it be a symlink to "refs/gitfs-dynamic" or something and
then have "refs" be populated with that synthetic file and symlinks to
any of the normal contents of the refs directory. Not too bad, but will
take a little bit of code.
You would have to wait a bit. There was talk on git mailing list about
allowing HEAD to point to non-head ref, or even bare sha1, only forbidding
committing to such HEAD (but allowing checkout of arbitrary revision,
not only branch, but also remote branch, tag, or branch~n).
--
Jakub Narebski