2015-03-23 19:36:10 +00:00
|
|
|
# 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.
|
|
|
|
|
|
|
|
# OPTIONS
|
|
|
|
|
|
|
|
* `--from=remote`
|
|
|
|
|
move --to=here
* move --to=here moves from all reachable remotes to the local repository.
The output of move --from remote is changed slightly, when the remote and
local both have the content. It used to say:
move foo ok
Now:
move foo (from theremote...) ok
That was done so that, when move --to=here is used and the content is
locally present and also in several remotes, it's clear which remotes the
content gets dropped from.
Note that move --to=here will report an error if a non-reachable remote
contains the file, even if the local repository also contains the file. I
think that's reasonable; the user may be intending to move all other copies
of the file from remotes.
OTOH, if a copy of the file is believed to be present in some repository
that is not a configured remote, move --to=here does not report an error.
So a little bit inconsistent, but erroring in this case feels wrong.
copy --to=here came along for free, but it's basically the same behavior as
git-annex get, and probably with not as good messages in edge cases
(especially on failure), so I've not documented it.
This commit was sponsored by Anthony DeRobertis on Patreon.
2017-05-31 20:57:27 +00:00
|
|
|
Copy the content of files from the specified
|
2015-03-23 19:36:10 +00:00
|
|
|
remote to the local repository.
|
2015-05-01 18:13:30 +00:00
|
|
|
|
|
|
|
Any files that are not available on the remote will be silently skipped.
|
2015-03-23 19:36:10 +00:00
|
|
|
|
|
|
|
* `--to=remote`
|
|
|
|
|
move --to=here
* move --to=here moves from all reachable remotes to the local repository.
The output of move --from remote is changed slightly, when the remote and
local both have the content. It used to say:
move foo ok
Now:
move foo (from theremote...) ok
That was done so that, when move --to=here is used and the content is
locally present and also in several remotes, it's clear which remotes the
content gets dropped from.
Note that move --to=here will report an error if a non-reachable remote
contains the file, even if the local repository also contains the file. I
think that's reasonable; the user may be intending to move all other copies
of the file from remotes.
OTOH, if a copy of the file is believed to be present in some repository
that is not a configured remote, move --to=here does not report an error.
So a little bit inconsistent, but erroring in this case feels wrong.
copy --to=here came along for free, but it's basically the same behavior as
git-annex get, and probably with not as good messages in edge cases
(especially on failure), so I've not documented it.
This commit was sponsored by Anthony DeRobertis on Patreon.
2017-05-31 20:57:27 +00:00
|
|
|
Copy the content of files from the local repository
|
2015-03-23 19:36:10 +00:00
|
|
|
to the specified remote.
|
|
|
|
|
2015-04-10 21:08:07 +00:00
|
|
|
* `--jobs=N` `-JN`
|
|
|
|
|
|
|
|
Enables parallel transfers with up to the specified number of jobs
|
|
|
|
running at once. For example: `-J10`
|
|
|
|
|
2015-03-25 21:06:14 +00:00
|
|
|
* `--auto`
|
|
|
|
|
|
|
|
Rather than copying all files, only copy files 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)
|
|
|
|
|
2015-03-23 19:36:10 +00:00
|
|
|
* `--fast`
|
|
|
|
|
2017-06-01 00:01:21 +00:00
|
|
|
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.
|
2015-03-23 19:36:10 +00:00
|
|
|
|
|
|
|
* `--force`
|
|
|
|
|
2017-06-01 00:01:21 +00:00
|
|
|
When copying content from a remote, ignore location tracking information
|
|
|
|
and always check if the remote has content. Can be useful if the location
|
|
|
|
tracking information is out of date.
|
2015-03-23 19:36:10 +00:00
|
|
|
|
|
|
|
* `--all`
|
|
|
|
|
|
|
|
Rather than specifying a filename or path to copy, this option can be
|
|
|
|
used to copy all available versions of all files.
|
|
|
|
|
2015-03-25 16:09:49 +00:00
|
|
|
This is the default behavior when running git-annex in a bare repository.
|
|
|
|
|
--branch, stage 1
Added --branch option to copy, drop, fsck, get, metadata, mirror, move, and
whereis commands. This option makes git-annex operate on files that are
included in a specified branch (or other treeish).
The names of the files from the branch that are being operated on are not
displayed yet; only the keys. Displaying the filenames will need changes
to every affected command.
Also, note that --branch can be specified repeatedly. This is not really
documented, but seemed worth supporting, especially since we may later want
the ability to operate on all branches matching a refspec. However, when
operating on two branches that contain the same key, that key will be
operated on twice.
2016-07-20 16:05:22 +00:00
|
|
|
* `--branch=ref`
|
|
|
|
|
|
|
|
Operate on files in the specified branch or treeish.
|
|
|
|
|
2015-03-23 19:36:10 +00:00
|
|
|
* `--unused`
|
|
|
|
|
|
|
|
Operate on files found by last run of git-annex unused.
|
|
|
|
|
2016-08-03 16:37:12 +00:00
|
|
|
* `--failed`
|
|
|
|
|
|
|
|
Operate on files that have recently failed to be transferred.
|
|
|
|
|
2015-03-23 19:36:10 +00:00
|
|
|
* `--key=keyname`
|
|
|
|
|
|
|
|
Use this option to move a specified key.
|
|
|
|
|
|
|
|
* file matching options
|
|
|
|
|
|
|
|
The [[git-annex-matching-options]](1)
|
|
|
|
can be used to specify files to copy.
|
|
|
|
|
2017-08-15 16:39:10 +00:00
|
|
|
* `--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
|
|
|
|
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.
|
|
|
|
|
2016-09-09 20:24:26 +00:00
|
|
|
* `--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.
|
|
|
|
|
2015-03-23 19:36:10 +00:00
|
|
|
# SEE ALSO
|
|
|
|
|
|
|
|
[[git-annex]](1)
|
|
|
|
|
2015-05-29 16:12:55 +00:00
|
|
|
[[git-annex-get]](1)
|
|
|
|
|
|
|
|
[[git-annex-move]](1)
|
|
|
|
|
|
|
|
[[git-annex-drop]](1)
|
|
|
|
|
2015-03-23 19:36:10 +00:00
|
|
|
# AUTHOR
|
|
|
|
|
|
|
|
Joey Hess <id@joeyh.name>
|
|
|
|
|
|
|
|
Warning: Automatically converted into a man page by mdwn2man. Edit with care.
|