threads / announce / 43484

Re: [ANNOUNCE] gitfs pre-release 0.04

Subject: Re: [ANNOUNCE] gitfs pre-release 0.04

## tl;dr

4 messages between Dec 4, 2006 and Dec 4, 2006.

replies: 3people: 2as markdown or json

Mitchell Blank Jr· Dec 4, 2006, 19:40 UTC · lore

[ANNOUNCE] gitfs pre-release 0.04

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· Dec 4, 2006, 19:40 UTC · re: Mitchell Blank Jr · lore

Mitchell Blank Jr wrote:

Show 6 quoted lines

>   * 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· Dec 4, 2006, 20:03 UTC · re: Jakub Narebski · lore

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.

Jakub Narebski· Dec 4, 2006, 19:54 UTC · re: Mitchell Blank Jr · lore

Mitchell Blank Jr wrote:

Show 13 quoted lines

> 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.

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