# 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. A
few parameters that are supported by all special remotes are documented in
the next section below.

Once a special remote has been initialized once with this command,
other clones of the repository can also be set up to access it using
`git annex enableremote`.

The name you provide for the remote can't be one that's been used for any
other special remote before, because `git-annex enableremote` uses the name
to identify which special remote to enable. If some old special remote
that's no longer used has taken the name you want to reuse, you might
want to use `git annex renameremote`.

# 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)

* `--sameas=remote`

  Use this when the new special remote uses the same underlying storage
  as some other remote. This will result in the new special remote having
  the same uuid as the specified remote, and either can be used to access
  the same content.

  The `remote` can be the name of a git remote, or the description
  or uuid of any git-annex repository.

  When using this option, the new remote inherits the encryption settings
  of the existing remote, so you should not specify any encryption
  parameters. No other configuration is inherited from the existing remote.

  This will only work if both remotes use the underlying storage in
  compatible ways. See this page for information about known
  compatabilities.
  <http://git-annex.branchable.com/tips/multiple_remotes_accessing_the_same_data_store/>

# COMMON CONFIGURATION PARAMETERS

* `encryption`

  All special remotes support encryption. You will need to specify
  what encryption, if any, to use. 

  If you do not want any encryption, use `encryption=none`

  To encrypt to a GPG key, use `encryption=hybrid keyid=$keyid ...`
  and fill in the GPG key id (or an email address associated with a GPG key).
  
  For details about this and other encrpytion settings, see
  <https://git-annex.branchable.com/encryption/>

* `autoenable`

  To avoid `git annex enableremote` needing to be run,
  you can pass "autoenable=true". Then when [[git-annex-init]](1)
  is run in a new clone, it will attempt to enable the special remote. Of
  course, this works best when the special remote does not need anything
  special to be done to get it enabled.

* `uuid`

  Normally, git-annex initremote generates a new UUID for the new special
  remote. If you want to, you can specify a UUID for it to use, by passing a
  uuid=whatever parameter. This can be useful in some unusual situations.
  But if in doubt, don't do this.

# SEE ALSO

[[git-annex]](1)

[[git-annex-enableremote]](1)

[[git-annex-renameremote]](1)

# AUTHOR

Joey Hess <id@joeyh.name>

Warning: Automatically converted into a man page by mdwn2man. Edit with care.