21ec5872f4
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.
59 lines
2 KiB
Markdown
59 lines
2 KiB
Markdown
# NAME
|
|
|
|
git-annex initremote - creates a special (non-git) remote
|
|
|
|
# SYNOPSIS
|
|
|
|
git annex initremote `name type=value [param=value ...]`
|
|
|
|
# DESCRIPTION
|
|
|
|
Creates a new special remote, and adds it to `.git/config`.
|
|
|
|
Example Amazon S3 remote:
|
|
|
|
git annex initremote mys3 type=S3 encryption=hybrid keyid=me@example.com datacenter=EU
|
|
|
|
Many different types of special remotes are supported by git-annex.
|
|
For a list and details, see <https://git-annex.branchable.com/special_remotes/>
|
|
|
|
The remote's configuration is specified by the parameters passed
|
|
to this command. Different types of special remotes need different
|
|
configuration values. The command will prompt for parameters as needed.
|
|
|
|
All special remotes support encryption. You can either specify
|
|
`encryption=none` to disable encryption, or specify
|
|
`encryption=hybrid keyid=$keyid ...` to specify a GPG key id (or an email
|
|
address associated with a key).
|
|
|
|
There are actually three schemes that can be used for management of the
|
|
encryption keys. When using the encryption=hybrid scheme, additional
|
|
GPG keys can be given access to the encrypted special remote easily
|
|
(without re-encrypting everything). When using encryption=shared,
|
|
a shared key is generated and stored in the git repository, allowing
|
|
anyone who can clone the git repository to access it. Finally, when using
|
|
encryption=pubkey, content in the special remote is directly encrypted
|
|
to the specified GPG keys, and additional ones cannot easily be given
|
|
access.
|
|
|
|
# OPTIONS
|
|
|
|
* `--fast`
|
|
|
|
When initializing a remote that uses encryption, a cryptographic key is
|
|
created. This requires sufficient entropy. If initremote seems to hang
|
|
or take a long time while generating the key, you may want to Ctrl-c it
|
|
and re-run with `--fast`, which causes it to use a lower-quality source of
|
|
randomness. (Ie, /dev/urandom instead of /dev/random)
|
|
|
|
# SEE ALSO
|
|
|
|
[[git-annex]](1)
|
|
|
|
[[git-annex-enableremote]](1)
|
|
|
|
# AUTHOR
|
|
|
|
Joey Hess <id@joeyh.name>
|
|
|
|
Warning: Automatically converted into a man page by mdwn2man. Edit with care.
|