1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
|
I have a NAS at home which I access both as AFP/SMB shares and thru ssh/rsync. Now, I'd like to keep on using the shares as before, i.e., browsable via AFP/SMB with conventional file names. Ideally, I'd also like to git-annex some NAS shares, preferably, in direct mode. However, it seems out of the question to install git-annex on the NAS (hopefully, I'm wrong about this in the long run).
Two **non-special remote setups** would be:
1. Mount the share and turn it into a direct mode git annex repo. Does anybody have experience with this? I'd suspect this to be very inefficient due to the use of all the files in .git over AFP/SMB. Configuration as a WORM backend seems to be advised? (Edit: Well, I just tried this and 'git annex init' failed as described in this [forum post](http://git-annex.branchable.com/forum/Can__39__t_init_git_annex/). So AFP/SMB seem to be non-starters. :-( Furthermore, AFP/SMB are immediately detected as crippled and set to direct mode automatically.)
2. Same as 1. but with a local GIT_DIR. This should work by having .git on the NAS link to the local GIT_DIR.
Alternatively, I could treat my NAS as a [**web special remote**](http://git-annex.branchable.com/tips/using_the_web_as_a_special_remote/). Some URL schemes come to mind:
* **file:** This would benefit from some wish list items ([recursive directory remote setup/addurl](http://git-annex.branchable.com/todo/wishlist:_recursive_directory_remote_setup__47__addurl/)).
* **rsync:** AFAIK not implemented (yet?) as an option for web special remotes.
* **sftp:** (Might also include ssh access.)
The problem is that the "web semantics" don't really work in my use case:
* Files might change/move on the NAS.
* I'd like changes (e.g., renamed files) in my local repo to propagate to the NAS. Currently, git-annex would use git push for this purpose IIUC, however that's not available on the NAS...
* the web semantics seem to imply that there is exactly one "web" repository (and the URL is fixed)
All of these indicate a mismatch between my use case and web special remotes.
Hence my question: **Would something like a "direct special remote" make sense?**
As a starting point I'd look at a setup similar to 2. above, i.e., a remote "working copy" with local GIT_DIR. Except that instead of a whole local .git directory a branch in an existing .git dir might be more appropriate...
--Chris
|
