sync: Support --jobs

* sync: Support --jobs
* sync --content: Avoid unnecessary second pull from remotes when
  no file transfers are made.
This commit is contained in:
Joey Hess 2015-08-14 13:49:55 -04:00
parent 4a5fe93248
commit 87b4229b23
4 changed files with 51 additions and 15 deletions

View file

@ -65,6 +65,16 @@ by running "git annex sync" on the remote.
will only match the version of files currently in the work tree, but not
past versions of files.
* `--jobs=N` `-JN`
Enables parallel syncing with up to the specified number of jobs
running at once. For example: `-J10`
When there are multiple git remotes, pushes will be made to them in
parallel. Pulls are not done in parallel because that tends to be
less efficient. When --content is synced, the files are processed
in parallel as well.
# SEE ALSO
[[git-annex]](1)

View file

@ -1 +1,14 @@
As the subject says. I mostly use `git annex sync --content` to transfer files between repositories, as its easier than running `git annex sync`, a bunch of `git annex copy`s and then a `git annex get` to make sure I have all the files I should have. It would be good if the shortcut could also work in parallel.
As the subject says. I mostly use `git annex sync --content` to transfer
files between repositories, as its easier than running `git annex sync`, a
bunch of `git annex copy`s and then a `git annex get` to make sure I have
all the files I should have. It would be good if the shortcut could also
work in parallel.
> It also can be faster to push concurrent. OTOH, concurrent pulls
> can lead to the same git objects being downloaded redundantly, so best to
> avoid those I think.
>
> I've implemented this. It suffers from the same
> lack of support for displaying progress when running it parallel as
> documented on [[parallel_get]]. Other than that wart, this is [[done]].
> --[[Joey]]