1git-annex-initremote(1) General Commands Manual git-annex-initremote(1)
2
3
4
6 git-annex-initremote - creates a special (non-git) remote
7
9 git annex initremote name type=value [param=value ...]
10
12 Creates a new special remote, and adds it to .git/config.
13
14 Example Amazon S3 remote:
15
16 git annex initremote mys3 type=S3 encryption=hybrid keyid=me@exam‐
17 ple.com datacenter=EU
18
19 Many different types of special remotes are supported by git-annex.
20 For a list and details, see <https://git-annex.branchable.com/spe‐
21 cial_remotes/>
22
23 The remote's configuration is specified by the parameters passed to
24 this command. Different types of special remotes need different config‐
25 uration values. The command will prompt for parameters as needed. A few
26 parameters that are supported by all special remotes are documented in
27 the next section below.
28
29 Once a special remote has been initialized once with this command,
30 other clones of the repository can also be set up to access it using
31 git annex enableremote.
32
33 The name you provide for the remote can't be one that's been used for
34 any other special remote before, because git-annex enableremote uses
35 the name to identify which special remote to enable. If some old spe‐
36 cial remote that's no longer used has taken the name you want to reuse,
37 you might want to use git annex renameremote.
38
40 --fast
41
42 When initializing a remote that uses encryption, a cryptographic
43 key is created. This requires sufficient entropy. If initremote
44 seems to hang or take a long time while generating the key, you
45 may want to Ctrl-c it and re-run with --fast, which causes it to
46 use a lower-quality source of randomness. (Ie, /dev/urandom
47 instead of /dev/random)
48
49 --sameas=remote
50 Use this when the new special remote uses the same underlying
51 storage as some other remote. This will result in the new spe‐
52 cial remote having the same uuid as the specified remote, and
53 either can be used to access the same content.
54
55 The remote can be the name of a git remote, or the description
56 or uuid of any git-annex repository.
57
58 When using this option, the new remote inherits the encryption
59 settings of the existing remote, so you should not specify any
60 encryption parameters. No other configuration is inherited from
61 the existing remote.
62
63 This will only work if both remotes use the underlying storage
64 in compatible ways. See this page for information about known
65 compatabilities. <http://git-annex.branchable.com/tips/multi‐
66 ple_remotes_accessing_the_same_data_store/>
67
69 encryption
70
71 All special remotes support encryption. You will need to specify
72 what encryption, if any, to use.
73
74 If you do not want any encryption, use encryption=none
75
76 To encrypt to a GPG key, use encryption=hybrid keyid=$keyid ...
77 and fill in the GPG key id (or an email address associated with
78 a GPG key).
79
80 For details about this and other encrpytion settings, see
81 <https://git-annex.branchable.com/encryption/>
82
83 autoenable
84 To avoid git annex enableremote needing to be run, you can pass
85 "autoenable=true". Then when git-annex-init(1) is run in a new
86 clone, it will attempt to enable the special remote. Of course,
87 this works best when the special remote does not need anything
88 special to be done to get it enabled.
89
90 uuid Normally, git-annex initremote generates a new UUID for the new
91 special remote. If you want to, you can specify a UUID for it to
92 use, by passing a uuid=whatever parameter. This can be useful in
93 some unusual situations. But if in doubt, don't do this.
94
96 git-annex(1)
97
98 git-annex-enableremote(1)
99
100 git-annex-renameremote(1)
101
103 Joey Hess <id@joeyh.name>
104
105 git-annex-initremote(1)