This is the command git-annex-enableremote that can be run in the OnWorks free hosting provider using one of our multiple free online workstations such as Ubuntu Online, Fedora Online, Windows online emulator or MAC OS online emulator
PROGRAM:
NAME
git-annex-enableremote - enables use of an existing special remote
SYNOPSIS
git annex enableremote name|uuid|desc [param=value ...]
DESCRIPTION
Enables use of an existing special remote in the current repository, which may be a
different repository than the one in which it was originally created with the initremote
command.
The name of the remote is the same name used when originally creating that remote with git
annex initremote. Run git annex enableremote without any name to get a list of special
remote names. Or you can specify the uuid or description of the remote.
Some special remotes may need parameters to be specified every time they are enabled. For
example, the directory special remote requires a directory= parameter every time.
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.
Use git-annex-enableremote online using onworks.net services