(I put this in a separate topic because it is a different question)
I still do not fully understand when (in direct mode!) a file is in the work copy and when in the repository. Because what git-annex always refers to a "repository" is actually a repository (i.e., the server part for subversion) and a work copy (the client part in subversion), right? (except for bare repositories which have only the former)
When I change a file in the work copy, I still need to "git annex sync", right? But do I also need to "git annex sync --content" to move the changes from the work copy to the repository?
Because I have a headless server where the annex should also be accessed via samba. When files are added/changed, the annex clients do not see the changes until I manually do a couple of "git annex sync" and "git annex sync --content" (it's not deterministic yet for me how often).
Is this the intended behavior? If yes, is there a better way to automatically sync the changes on the headless server other than a cron job?
A git repository is a
.gitdirectory (orgit.barefor a bare repository).A working tree is the directory that contains the
.gitdirectory.That is standard git terminology; git-annex does not change this at all really. The only difference is that a file added to git-annex is in both the repository and the working tree at the same time, rather than their being 2 local copies of the file (which would need twice the disk space so not good for large files).
git annex synccommits any changes to files in the working tree, and pushes those changes to other remotes. You need to pass --content to also make git-annex upload the files to other remotes. Once a remote has been pushed to, you can rungit annex mergein it to update its working tree to reflect the pushed changes (git annex syncalso does that merge).To automatically sync changes to remotes, you can run the git-annex assistant.