sync --content: New option that makes the content of annexed files be transferred.

Similar to the assistant, this honors any configured preferred content
expressions.

I am not entirely happpy with the implementation. It would be nicer if
the seek function returned a list of actions which included the individual
file gets and copies and drops, rather than the current list of calls to
syncContent. This would allow getting rid of the somewhat reundant display
of "sync file [ok|failed]" after the get/put display.

But, do that, withFilesInGit would need to somehow be able to construct
such a mixed action list. And it would be less efficient than the current
implementation, which is able to reuse several values between eg get and
drop.

Note that currently this does not try to satisfy numcopies when
getting/putting files (numcopies are of course checked when dropping
files!) This makes it like the assistant, and unlike get --auto
and copy --auto, which do duplicate files when numcopies is not yet
satisfied. I don't know if this is the right decision; it only seemed to
make sense to have this parallel the assistant as far as possible to start
with, since I know the assistant works.

This commit was sponsored by Øyvind Andersen Holm.

2 files changed, 12 insertions, 6 deletions

diff --git a/doc/git-annex.mdwn b/doc/git-annex.mdwn
index a3c52458f..e8058720c 100644
--- a/doc/git-annex.mdwn
+++ b/doc/git-annex.mdwn
@@ -156,8 +156,12 @@ subdirectories).
   are pushed to the remote, so they can be merged into its working tree
   by running "git annex sync" on the remote.
 
-  Note that sync does not transfer any annexed file contents from or
-  to the remote repositories; it only syncs the git repositories.
+  With the `--content` option, the contents of annexed files in the work
+  tree will also be uploaded and downloaded from remotes. By default,
+  this tries to get each annexed file that the local repository does not
+  yet have, and then copies each file to every remote that it is syncing with.
+  This behavior can be overridden by configuring the preferred content of
+  a repository. See see PREFERRED CONTENT below.
 
 * `merge`
 
diff --git a/doc/preferred_content.mdwn b/doc/preferred_content.mdwn
index 2e12dce49..9c698c8ba 100644
--- a/doc/preferred_content.mdwn
+++ b/doc/preferred_content.mdwn
@@ -3,13 +3,15 @@ data always exist, and leaves it up to you to use commands like `git annex
 get` and `git annex drop` to move the content to the repositories you want
 to contain it. But sometimes, it can be good to have more fine-grained
 control over which repositories prefer to have which content. Configuring
-this allows `git annex get --auto`, `git annex drop --auto`, etc to do
-smarter things.
+this allows the git-annex assistant as well as 
+`git annex get --auto`, `git annex drop --auto`, `git annex sync --content`,
+etc to do smarter things.
 
 Preferred content settings can be edited using `git
 annex vicfg`, or viewed and set at the command line with `git annex wanted`.
-Each repository can have its own settings, and other repositories may also
-try to honor those settings. So there's no local `.git/config` setting it.
+Each repository can have its own settings, and other repositories will
+try to honor those settings when interacting with it.
+So there's no local `.git/config` for preferred content settings.
 
 The idea is that you write an expression that files are matched against.
 If a file matches, it's preferred to have its content stored in the