git-annex-enableremote(1)

📦
version 10.20261026 · 7 versions
, in alpine 3.24, arch rolling

💖 git-annex-enableremote(1) 💖

ok so this is the git-annex manual page for git-annex-enableremote — yes bestie, the General Commands Manual one — and it's literally the glow-up your remote needed. let's go 🎀

✨ NAME ✨

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

🌸 SYNOPSIS 🌸

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

💅 DESCRIPTION 💅

okay so picture this: somebody already set up a remote with git annex initremote in another clone of the repo, and now you want in. this command enables use of that existing remote in the current repository. slay. 🫶

when you're enabling a remote, you gotta specify the same name that was used when it was originally set up with git annex initremote. not sure what the name was? just run git annex enableremote with no name at all and it'll hand you a list of remote names. or you can specify the uuid or the description of the remote instead — dealer's choice. ✨

important: some types of special remotes need parameters specified every time they're enabled. example: the directory special remote requires a directory= parameter every single time, no skipping. if you leave out any required parameters, the command will literally just prompt you for them. it's got you. 💖

this command can also be used to modify the config of an existing special remote, by specifying new values for parameters that are usually set when using initremote. (but heads up — some settings, such as the encryption scheme, cannot be changed once a special remote has been created. that ship has sailed, bestie. 😭)

the GPG keys that an encrypted special remote is encrypted with can be changed using the keyid+= and keyid-= parameters. they respectively add and remove keys from the list. but ngl, note this: removing a key does NOT necessarily prevent the key's owner from accessing data in the encrypted special remote — that's by design impossible, short of deleting the remote. so don't go thinking keyid-= is a magic little lock. 💀

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

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

also 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. so using keyid+= and keyid-= with such remotes should be used with care, and honestly makes 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 (ugh, the labor), 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. 🤷‍♀️

(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 🎀

  • --with-url — this configures the remote with an annex:: url, which allows git to push to and pull from it, using git-remote-annex. iconic.
  • --json — enable JSON output. this is intended to be parsed by programs that use git-annex, so it's giving robot-friendly. 🤖
  • --json-error-messages — messages that would normally be output to standard error are included in the JSON instead. no stray stderr, we keep it all in one place. ✨

also, the git-annex-common-options(1) can be used. yep, those ones too. 💜

🌈 SEE ALSO 🌈

👑 AUTHOR 👑

Joey Hess <id@joeyh.name> — the main character of this manpage, fr fr.

ok that's the whole page, no cap, every single flag and warning intact 💅✨ this was git-annex-enableremote(1) from the git-annex manual set — go enable something, bestie, you've got this 🦋💖

📦 where this page comes from