Does git-annex (safely) handle detached work trees?
That is, in git I can set GIT_WORK_TREE=/dir/A and GIT_DIR=/dir/B in the environment and have all my .git stuff in /dir/B and all my files in /dir/A.
I can see this coming in useful for a few situations, but in particular for difficult file systems - like SMB or old implementations of NFS.
In my particular case I have a Drobo (something like a proprietary NAS). The Drobo is linux based, but by default mounts as a samba share or if you install unfsd it can be mounted via NFS. Unfortunately, the nfs is v3 and doesn't allow locks, so git-annex barfs. 
What I'd like to be able to do is have a direct mode annex on the drobo, with the git directory sitting on one of my linux machines. That machine would be the only one that would directly access the drobo data as an annex but other systems that look at the drobo would see what looks like a normal directory structure; for example my media centre - mythtv naturally! - would see "normal" names for my music collection, not SHA256 hashes...
I guess there would be an issue if there were different GIT_DIRs pointing to the one GIT_WORK_TREE, but that is a caveat emptor IMHO.
I'm trying to use git-annex with vcsh, and it doesn't seem to be respecting the GIT_WORK_TREE and GIT_DIR variables vcsh sets. If I try it manually, the same happens.
Any time I try to invoke a git-annex subcommand (init, add) via vcsh (vcsh $repo annex init/add/etc) it spits out an error that "git-annex: Not in a git repository."
I'd really like this to work, so that I can manage the bigger files in my home with topic-based annexes alongside plain-git repos for dotfiles.
So, I found and fixed that bug. It really seems to be working now. Although I've thought that at least twice before!
There is an important caveat though, with using
GIT_DIRand/orGIT_WORK_TREE.git-annex needs to check in symlinks that point at the git repository. If using
GIT_DIR, those symlinks do not look like "-> .git/annex/objects/"; they instead point off to some git repository elsewhere, as a relative path. For example they could look like "-> ../gitrepo/annex/objects/". Similar when usingGIT_WORK_TREE.But this is a problem if you want to use the same git repo elsewhere, with a git work tree and repo that are not set up the same relative to one-another, because the links will all be wrong. So, if you decide to use
GIT_DIRorGIT_WORK_TREEwith git-annex, any clone of the repository will need to place the git directory in the same place relative to the working tree.If you later want to change the relative paths between git directory and work tree, it would need to be changed in all clones of the repository, and then you could use
git annex fixto update the symlinks.Cool, thanks! The caveat shouldn't be much of a problem for my use case - with vcsh, the workdir is always $HOME, and I'm using the recommended mr-based workflow so the gitdir will always be ~/.config/vcsh/repo.d/$name.git in each clone.
EDIT: fix erroneous path
git ls-fileslists.Been using it a few hours now and it works like a charm - first thing I did was get a sitemap of the LCA and FOSDEM talks and use addurl --fast on them, since I've been wanting to do that since I saw the lightning talk last year at FOSDEM.
Thanks again for making this awesome utility!