mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
git-annex/doc/git-annex-mirror.mdwn

104 lines
2.5 KiB
Text
Raw Normal View History

splitting up the man page Common command man pages all split out and often expanded. A few sections split out into their own pages. Still need to do all the other commands..
2015-03-23 19:36:10 +00:00
# NAME
git-annex mirror - mirror content of files to/from another repository
# SYNOPSIS
git annex mirror `[path ...] [--to=remote|--from=remote]`
# DESCRIPTION
This causes a destination repository to mirror a source repository.
Each specified file in the source repository is mirrored to the destination
repository. If a file's content is present in the source repository, it is
copied to the destination repository. If a file's content is not present in
the source repository, it will be dropped from the destination repository
when the numcopies setting allows.
Note that mirror does not sync the git repository, but only the file
expand manpages cross-references significantly i found that most man pages only had references to the main git-annex manpage, which i stillfind pretty huge and hard to navigate through. i tried to sift through all the man pages and add cross-references between relevant pages. my general rule of thumb is that links should be both ways unless one of the pages is a more general page that would become ridiculously huge if all backlinks would be added (git-annex-preferred-content comes to mind). i have also make the links one per line as this is how it was done in the metadata pages so far. i did everything but the plumbing, utility and test commands, although some of those are linked from the other commands so cross-links were added there as well.
2015-05-29 16:12:55 +00:00
contents. Use [[git-annex-sync]](1) for that.
splitting up the man page Common command man pages all split out and often expanded. A few sections split out into their own pages. Still need to do all the other commands..
2015-03-23 19:36:10 +00:00
# OPTIONS
* `--to=remote`
Use the local repository as the source repository, and mirror its contents
to the remote.
* `--from=remote`
Use the remote as the source repository, and mirror its contents to the local
repository.
get, move, copy, mirror: Concurrent downloads and uploads are now supported! This works, and seems fairly robust. Clean get of 20 files at -J3. At -J10, there are some messages about ssh multiplexing, probably due to a race spinning up the ssh connection cacher. But, it manages to get all the files ok regardless. The progress bars are a scrambled mess though, due to bugs in ascii-progress, which I've already filed. Particularly this one: https://github.com/yamadapc/haskell-ascii-progress/issues/8
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`
annex.jobs=cpus etc Added the ability to run one job per CPU (core), by setting annex.jobs=cpus, or using option --jobs=cpus or -Jcpus. Built with future expansion in mind, including not defaulting matching on Concurrency so more constructors can later be added, and using "cpu" instead of "0".
2019-05-10 17:24:31 +00:00
Setting this to "cpus" will run one job per CPU core.
document the -A shorthand for --all
2018-04-04 03:12:04 +00:00
* `--all` `-A`
splitting up the man page Common command man pages all split out and often expanded. A few sections split out into their own pages. Still need to do all the other commands..
2015-03-23 19:36:10 +00:00
Mirror all objects stored in the git annex, not only objects used by
currently existing files.
However, this bypasses checking the .gitattributes annex.numcopies
setting when dropping files.
finished splitting out man pages for all commands
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.
Like --all, this bypasses checking the .gitattributes annex.numcopies
setting when dropping files.
get, move, copy, mirror: Added --failed switch which retries failed copies/moves Note that get --from foo --failed will get things that a previous get --from bar tried and failed to get, etc. I considered making --failed only retry transfers from the same remote, but it was easier, and seems more useful, to not have the same remote requirement. Noisy due to some refactoring into Types/
2016-08-03 16:37:12 +00:00
* `--unused`
Operate on files found by last run of git-annex unused.
* `--failed`
Operate on files that have recently failed to be transferred.
--batch-keys New --batch-keys option added to these commands: get, drop, move, copy, whereis git-annex-matching-options had to be reworded since some of its options can be used to match on keys, not only files. Sponsored-by: Luke Shumaker on Patreon
2021-08-25 18:20:33 +00:00
* matching options
splitting up the man page Common command man pages all split out and often expanded. A few sections split out into their own pages. Still need to do all the other commands..
2015-03-23 19:36:10 +00:00
The [[git-annex-matching-options]](1)
--batch-keys New --batch-keys option added to these commands: get, drop, move, copy, whereis git-annex-matching-options had to be reworded since some of its options can be used to match on keys, not only files. Sponsored-by: Luke Shumaker on Patreon
2021-08-25 18:20:33 +00:00
can be used to control what to mirror.
splitting up the man page Common command man pages all split out and often expanded. A few sections split out into their own pages. Still need to do all the other commands..
2015-03-23 19:36:10 +00:00
copy, move, mirror: Support --json and --json-progress.
2016-09-09 20:24:26 +00:00
* `--json`
Enable JSON output. This is intended to be parsed by programs that use
--json-exceptions Added a --json-exceptions option, which makes some exceptions be output in json. The distinction is that --json-error-messages is for messages relating to a particular ActionItem, while --json-exceptions is for messages that are not, eg ones for a file that does not exist. It's unfortunate that we need two switches with such a fine distinction between them, but I'm worried about maintaining backwards compatability in the json output, to avoid breaking anything that parses it, and this was the way to make sure I didn't. toplevelWarning is generally used for the latter kind of message. And the other calls to toplevelWarning could be converted to showException. The only possible gotcha is that if toplevelWarning is ever called after starting acting on a file, it will add to the --json-error-messages of the json displayed for that file and converting to showException would be a behavior change. That seems unlikely, but I didn't convery everything to avoid needing to satisfy myself it was not a concern. Sponsored-by: Dartmouth College's Datalad project
2023-04-25 21:02:25 +00:00
git-annex. Each line of output is a JSON object corresponding to a file
being processed.
copy, move, mirror: Support --json and --json-progress.
2016-09-09 20:24:26 +00:00
* `--json-progress`
Include progress objects in JSON output.
add --json-error-messages (not yet implemented) Added --json-error-messages option, which includes error messages in the json output, rather than outputting them to stderr. The actual rediretion of errors is not implemented yet, this is only the docs and option plumbing. This commit was supported by the NSF-funded DataLad project.
2018-02-19 18:28:17 +00:00
* `--json-error-messages`
--json-exceptions Added a --json-exceptions option, which makes some exceptions be output in json. The distinction is that --json-error-messages is for messages relating to a particular ActionItem, while --json-exceptions is for messages that are not, eg ones for a file that does not exist. It's unfortunate that we need two switches with such a fine distinction between them, but I'm worried about maintaining backwards compatability in the json output, to avoid breaking anything that parses it, and this was the way to make sure I didn't. toplevelWarning is generally used for the latter kind of message. And the other calls to toplevelWarning could be converted to showException. The only possible gotcha is that if toplevelWarning is ever called after starting acting on a file, it will add to the --json-error-messages of the json displayed for that file and converting to showException would be a behavior change. That seems unlikely, but I didn't convery everything to avoid needing to satisfy myself it was not a concern. Sponsored-by: Dartmouth College's Datalad project
2023-04-25 21:02:25 +00:00
Adds an "error-messages" field to the JSON that contains messages that
would normally be output to the standard error when processing a file.
* `--json-exceptions`
Output additional JSON objects for some exceptions that are not
associated with a particular file.
add --json-error-messages (not yet implemented) Added --json-error-messages option, which includes error messages in the json output, rather than outputting them to stderr. The actual rediretion of errors is not implemented yet, this is only the docs and option plumbing. This commit was supported by the NSF-funded DataLad project.
2018-02-19 18:28:17 +00:00
split out common options to its own page and mention it on each subcommand page Sometimes users would get confused because an option they were looking for was not mentioned on a subcommand's man page, and they had not noticed that the main git-annex man page had a list of common options. This change lets each subcommand mention the common options, similarly to how the matching options are handled. This commit was sponsored by Svenne Krap on Patreon.
2021-05-10 19:00:13 +00:00
* Also the [[git-annex-common-options]](1) can be used.
splitting up the man page Common command man pages all split out and often expanded. A few sections split out into their own pages. Still need to do all the other commands..
2015-03-23 19:36:10 +00:00
# SEE ALSO
[[git-annex]](1)
expand manpages cross-references significantly i found that most man pages only had references to the main git-annex manpage, which i stillfind pretty huge and hard to navigate through. i tried to sift through all the man pages and add cross-references between relevant pages. my general rule of thumb is that links should be both ways unless one of the pages is a more general page that would become ridiculously huge if all backlinks would be added (git-annex-preferred-content comes to mind). i have also make the links one per line as this is how it was done in the metadata pages so far. i did everything but the plumbing, utility and test commands, although some of those are linked from the other commands so cross-links were added there as well.
2015-05-29 16:12:55 +00:00
[[git-annex-sync]](1)
splitting up the man page Common command man pages all split out and often expanded. A few sections split out into their own pages. Still need to do all the other commands..
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.
Reference in a new issue Copy permalink