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.
|
|
|
|
|
|
2018-04-09 18:17:31 +00:00
|
|
|
* `--to=here`
|
|
|
|
|
|
|
|
|
|
Copy the content of files from all reachable remotes to the local
|
|
|
|
|
repository.
|
|
|
|
|
|
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
|
|
|
|
2018-04-04 03:12:04 +00:00
|
|
|
* `--all` `-A`
|
2015-03-23 19:36:10 +00:00
|
|
|
|
|
|
|
|
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
|
make --batch honor matching options
When --batch is used with matching options like --in, --metadata, etc, only
operate on the provided files when they match those options. Otherwise, a
blank line is output in the batch protocol.
Affected commands: find, add, whereis, drop, copy, move, get
In the case of find, the documentation for --batch already said it honored
the matching options. The docs for the rest didn't, but it makes sense to
have them honor them. While this is a behavior change, why specify the
matching options with --batch if you didn't want them to apply?
Note that the batch output for all of the affected commands could
already output a blank line in other cases, so batch users should
already be prepared to deal with it.
git-annex metadata didn't seem worth making support the matching options,
since all it does is output metadata or set metadata, the use cases for
using it in combination with the martching options seem small. Made it
refuse to run when they're combined, leaving open the possibility for later
support if a use case develops.
This commit was sponsored by Brett Eisenberg on Patreon.
2018-08-08 16:03:30 +00:00
|
|
|
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.
|
2017-08-15 16:39:10 +00:00
|
|
|
|
|
|
|
|
Since the usual output while copying a file is verbose and not
|
|
|
|
|
machine-parseable, you may want to use --json in combination with
|
|
|
|
|
--batch.
|
|
|
|
|
|
added -z
Added -z option to git-annex commands that use --batch, useful for
supporting filenames containing newlines.
It only controls input to --batch, the output will still be line delimited
unless --json or etc is used to get some other output. While git often
makes -z affect both input and output, I don't like trying them together,
and making it affect output would have been a significant complication,
and also git-annex output is generally not intended to be machine parsed,
unless using --json or a format option.
Commands that take pairs like "file key" still separate them with a space
in --batch mode. All such commands take care to support filenames with
spaces when parsing that, so there was no need to change it, and it would
have needed significant changes to the batch machinery to separate tose
with a null.
To make fromkey and registerurl support -z, I had to give them a --batch
option. The implicit batch mode they enter when not provided with input
parameters does not support -z as that would have complicated option
parsing. Seemed better to move these toward using the same --batch as
everything else, though the implicit batch mode can still be used.
This commit was sponsored by Ole-Morten Duesund on Patreon.
2018-09-20 20:09:21 +00:00
|
|
|
* `-z`
|
|
|
|
|
|
|
|
|
|
Makes the `--batch` input be delimited by nulls instead of the usual
|
|
|
|
|
newlines.
|
|
|
|
|
|
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.
|
|
|
|
|
|
2018-02-19 18:28:17 +00:00
|
|
|
* `--json-error-messages`
|
|
|
|
|
|
2018-02-19 19:33:59 +00:00
|
|
|
Messages that would normally be output to standard error are included in
|
|
|
|
|
the json instead.
|
2018-02-19 18:28:17 +00:00
|
|
|
|
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.
|