correct documentation, keyid= only works once

keyid+= can be used to add additional key ids later.

I wonder if this broke with changes to remote configs? But I think it's
always been a map, and so only one keyid can be stored and later ones
overwrite earlier ones.

Sponsored-by: Brett Eisenberg on Patreon

doc/encryption.mdwn

@@ -38,7 +38,7 @@ flexibility, it is the default and recommended encryption scheme.
 
 	git annex initremote newremote type=... [encryption=hybrid] keyid=KEYID
 
-The KEYID is passed to `gpg` to find gpg keys.
+The KEYID is passed to `gpg` to find a gpg key.
 Typically, you will say "keyid=2512E3C7" to use a specific gpg key.
 Or, you might say "keyid=id@joeyh.name" to search for matching keys.
 
@@ -89,9 +89,14 @@ it's exactly the way everyone else uses gpg.
 A disadvantage is that it is not easy to later add additional public keys
 to the special remote. While the `enableremote` parameters `keyid+=` and
 `keyid-=` can be used, they have **no effect** on encrypted files that
-are already stored in the remote.
+are already stored in the remote. 
 
-One use for these parameters is to replace a revoked key:
+So if you need other public keys to also have access, it's best to add them
+immediately after initializing the remote:
+
+	git-annex initremote newremote keyid+=788A3F4C
+
+Another use for these parameters is to replace a revoked key:
 
 	git annex enableremote myremote keyid-=2512E3C7 keyid+=788A3F4C
 

doc/special_remotes/git-lfs.mdwn

@@ -16,8 +16,7 @@ the git-lfs special remote:
 
 * `keyid` - Specifies the gpg key to use for encryption of both the files
   git-annex stores in the repository, as well as to encrypt the git
-  repository itself when using gcrypt. May be repeated when
-  multiple participants should have access to the repository.
+  repository itself when using gcrypt.
 
 ## efficiency note