1e31bf8122
Implementation was simple because it's equivilant to --from=foo --to remote for each other remote, followed by --to remote when there's a local copy. (Or, in the edge case of --from-anywhere --to=here, it's the same as --to=here.) Note that, when the local repo does not have a copy, fromToPerform gets it from a remote, sends it to the destination, and drops the local copy. Another call to that for a second remote will notice that the dest now has a copy, and simply drop from the second remote, avoiding a second transfer. Also note that, when numcopies doesn't allow dropping it from everywhere, it will drop it from the cheapest remotes first (maybe not ideal) up to more expensive remotes, and finally from the local repo. So the local repo will generally end up holding a copy. Maybe not ideal in all cases either, but it seems no worse to do that than to end up with a copy undropped from a remote. And I'm not entirely happy with the output, eg: copy bigfile (from r3...) ok copy bigfile ok That makes sense if you think of the second line as being the same as what is output by `git-annex copy bigfile --to bar`, but it's less clear in this context. Maybe add "(from here...)"? Also the --json output doesn't have a machine-readable field for the "from" uuid, and maybe it should? Sponsored-by: Dartmouth College's DANDI project
151 lines
3.7 KiB
Markdown
151 lines
3.7 KiB
Markdown
# NAME
|
|
|
|
git-annex copy - copy content of files to/from another repository
|
|
|
|
# SYNOPSIS
|
|
|
|
git annex copy `[path ...] [--from=remote|--to=remote]`
|
|
|
|
# DESCRIPTION
|
|
|
|
Copies the content of files from or to another remote.
|
|
|
|
With no parameters, operates on all annexed files in the current directory.
|
|
Paths of files or directories to operate on can be specified.
|
|
|
|
# OPTIONS
|
|
|
|
* `--from=remote`
|
|
|
|
Copy the content of files from the specified
|
|
remote to the local repository.
|
|
|
|
Any files that are not available on the remote will be silently skipped.
|
|
|
|
* `--to=remote`
|
|
|
|
Copy the content of files from the local repository
|
|
to the specified remote.
|
|
|
|
* `--to=here`
|
|
|
|
Copy the content of files from all reachable remotes to the local
|
|
repository.
|
|
|
|
* `--from=remote1 --to=remote2`
|
|
|
|
Copy the content of files that are in remote1 to remote2.
|
|
|
|
This is implemented by first downloading the content from remote1 to the
|
|
local repository (if not already present), then sending it to remote2, and
|
|
then deleting the content from the local repository (if it was not present
|
|
to start with).
|
|
|
|
* `--from-anywhere --to=remote`
|
|
|
|
Copy to the remote files from the local repository as well as from any reachable
|
|
remotes.
|
|
|
|
* `--jobs=N` `-JN`
|
|
|
|
Enables parallel transfers with up to the specified number of jobs
|
|
running at once. For example: `-J10`
|
|
|
|
Setting this to "cpus" will run one job per CPU core.
|
|
|
|
Note that when using --from with --to, twice this many jobs will
|
|
run at once, evenly split between the two remotes.
|
|
|
|
* `--auto`
|
|
|
|
Rather than copying all specified files, only copy those that don't yet have
|
|
the desired number of copies, or that are preferred content of the
|
|
destination repository. See [[git-annex-preferred-content]](1)
|
|
|
|
* `--fast`
|
|
|
|
When copying content to a remote, avoid a round trip to check if the remote
|
|
already has content. This can be faster, but might skip copying content
|
|
to the remote in some cases.
|
|
|
|
* `--all` `-A`
|
|
|
|
Rather than specifying a filename or path to copy, this option can be
|
|
used to copy all available versions of all files.
|
|
|
|
This is the default behavior when running git-annex in a bare repository.
|
|
|
|
* `--branch=ref`
|
|
|
|
Operate on files in the specified branch or treeish.
|
|
|
|
* `--unused`
|
|
|
|
Operate on files found by last run of git-annex unused.
|
|
|
|
* `--failed`
|
|
|
|
Operate on files that have recently failed to be transferred.
|
|
|
|
* `--key=keyname`
|
|
|
|
Use this option to copy a specified key.
|
|
|
|
* matching options
|
|
|
|
The [[git-annex-matching-options]](1)
|
|
can be used to specify what to copy.
|
|
|
|
* `--batch`
|
|
|
|
Enables batch mode, in which lines containing names of files to copy
|
|
are read from stdin.
|
|
|
|
As each specified file is processed, the usual progress output is
|
|
displayed. If a file's content does not need to be copied, or it does not
|
|
match specified matching options, or it is not an annexed file,
|
|
a blank line is output in response instead.
|
|
|
|
Since the usual output while copying a file is verbose and not
|
|
machine-parseable, you may want to use --json in combination with
|
|
--batch.
|
|
|
|
* `--batch-keys`
|
|
|
|
This is like `--batch` but the lines read from stdin are parsed as keys.
|
|
|
|
* `-z`
|
|
|
|
Makes batch input be delimited by nulls instead of the usual newlines.
|
|
|
|
* `--json`
|
|
|
|
Enable JSON output. This is intended to be parsed by programs that use
|
|
git-annex. Each line of output is a JSON object.
|
|
|
|
* `--json-progress`
|
|
|
|
Include progress objects in JSON output.
|
|
|
|
* `--json-error-messages`
|
|
|
|
Messages that would normally be output to standard error are included in
|
|
the JSON instead.
|
|
|
|
* Also the [[git-annex-common-options]](1) can be used.
|
|
|
|
# SEE ALSO
|
|
|
|
[[git-annex]](1)
|
|
|
|
[[git-annex-get]](1)
|
|
|
|
[[git-annex-move]](1)
|
|
|
|
[[git-annex-drop]](1)
|
|
|
|
# AUTHOR
|
|
|
|
Joey Hess <id@joeyh.name>
|
|
|
|
Warning: Automatically converted into a man page by mdwn2man. Edit with care.
|