484a74f073
Try to enable special remotes configured with autoenable=yes when git-annex auto-initialization happens in a new clone of an existing repo. Previously, git-annex init had to be explicitly run to enable them. That was a bit of a wart of a special case for users to need to keep in mind. Special remotes cannot display anything when autoenabled this way, to avoid interfering with the output of git-annex query commands. Any error messages will be hidden, and if it fails, nothing is displayed. The user will realize the remote isn't enable when they try to use it, and can run git-annex init manually then to try the autoenable again and see what failed. That seems like a reasonable approach, and it's less complicated than communicating something across a pipe in order to display it as a side message. Other reason not to do that is that, if the first command the user runs is one like git-annex find that has machine readable output, any message about autoenable failing would need to not be displayed anyway. So better to not display a failure message ever, for consistency. (Had to split out Remote.List.Util to avoid an import cycle.)
120 lines
4 KiB
Markdown
120 lines
4 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, so consult the documentation of a special remote for
|
|
details. The command will prompt for any required parameters you leave out;
|
|
you can also pass --whatelse to see additional parameters.
|
|
|
|
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
|
|
|
|
* `--whatelse` / `-w`
|
|
|
|
Describe additional configuration parameters that you could specify.
|
|
|
|
For example, if you know you want a S3 remote, but forget how to
|
|
configure it:
|
|
|
|
git annex initremote mys3 type=S3 --whatelse
|
|
|
|
* `--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`
|
|
|
|
Almost 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/>
|
|
or --whatelse
|
|
|
|
* `autoenable`
|
|
|
|
To avoid `git annex enableremote` needing to be run,
|
|
you can pass "autoenable=true". Then when git-annex 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.
|