NAME

       git-annex-enableremote - enables git-annex to use a remote

SYNOPSIS

       git annex enableremote name|uuid|desc [param=value ...]

DESCRIPTION

       Enables  use  of  an existing remote in the current repository, that was set up earlier by
       git annex initremote run in another clone of the repository.

       When enabling a remote, specify the same name used when originally setting up that  remote
       with  git  annex  initremote. Run git annex enableremote without any name to get a list of
       remote names. Or you can specify the uuid or description of the remote.

       Some types of special remotes need parameters to be specified every time they are enabled.
       For  example, the directory special remote requires a directory= parameter every time. The
       command will prompt for any required parameters you leave out.

       This command can also be used to modify the configuration of an existing  special  remote,
       by  specifying  new  values  for  parameters  that  are usually set when using initremote.
       (However, some settings such as the as the encryption scheme  cannot  be  changed  once  a
       special remote has been created.)

       The  GPG  keys that an encrypted special remote is encrypted with can be changed using the
       keyid+= and keyid-= parameters. These respectively add and  remove  keys  from  the  list.
       However,  note  that  removing  a  key  does  NOT necessarily prevent the key's owner from
       accessing data in the encrypted special remote (which is by design  impossible,  short  of
       deleting the remote).

       One use-case of keyid-= is to replace a revoked key with a new key:

        git annex enableremote mys3 keyid-=revokedkey keyid+=newkey

       Also,   note  that  for  encrypted  special  remotes  using  plain  public-key  encryption
       (encryption=pubkey), adding or removing a key has NO effect on  files  that  have  already
       been  copied  to  the  remote. Hence using keyid+= and keyid-= with such remotes should be
       used with care, and make little sense except in cases like the revoked key example above.

       If you get tired of manually enabling a special remote in each new  clone,  you  can  pass
       "autoenable=true". Then when git-annex-init(1) is run in a new clone, it will 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.

       (This command also can be used to enable a git remote that git-annex has found didn't work
       before and gave up on using, setting remote.<name>.annex-ignore.)

OPTIONS

       --json

              Enable JSON output. This is intended to be parsed by programs that use git-annex.

       --json-error-messages
              Messages that would normally be output to standard error are included in  the  JSON
              instead.

       Also, the git-annex-common-options(1) can be used.

SEE ALSO

       git-annex(1)

       git-annex-initremote(1)

       git-annex-configremote(1)

       git-annex-renameremote(1)

AUTHOR

       Joey Hess <id@joeyh.name>

                                                                        git-annex-enableremote(1)