[[!comment format=mdwn
 username="http://grossmeier.net/"
 nickname="greg"
 subject="comment 7"
 date="2013-12-05T21:20:54Z"
 content="""
>  How could git-annex update this NAS if it's not on the local network?

ssh and port forwarding, like any home server.

> I tend to think that a better use of a NAS in many cases is to put a directory or rsync (if it supports rsync) special remote on the NAS, and have git-annex on the individual client machines.

I'm thinking of this like the public view of a git-annex repository. I want anyone to be able to view/download the files as they normally would.

> The use case for having a mirrored directory tree on the NAS seems to be limited to when the clients using it are something that cannot run git-annex itself, but that still cares about filenames, as opposed to just operating on file contents.

That's exactly my use case.

> So far, the only reason that has been brought up that makes sense to me is locking.

Locking is actually tangential to the issue/use case. Direct mode would solve that issue, but git-annex isn't built for the Synology NAS platform, so it isn't an option.

> The other problem with this idea is that it seems to want the assistant to watch the file tree in the NAS, and make commits etc when files there are changed.

I think you read too much into that part. :) I only want git-annex to do things when I 'sync' or similar. I'm actually not wanting *the assistant* to do much in this case. This might even be a non-assistant applicable use case. (I don't use the assistant in my large repositories, like photos and videos and music.) I only mentioned the assistant to point out that it has some of the logic (what to do with changed/deleted files) already.

And honestly, I'd be fine with an implementation that overwrote all changes on this special remote on each sync (as needed). The response to that suggestion is \"just use rsync by itself to put the files on the NAS\" but that assumes I have all of the files on my local checkout (I don't).
"""]]