gcrypt: Support re-enabling to change eg, encryption parameters.

This was never supported before. And it doesn't re-encrypt the
gcrypt repo to the new gcrypt-participants, but it does at least now not
crash, and set gcrypt-participants.

This commit was sponsored by andrea rota.

CHANGELOG

@@ -14,9 +14,11 @@ git-annex (6.20170322) UNRELEASED; urgency=medium
     the parameters that git passes.
   * enableremote: When enabling a non-special remote, param=value
     parameters can't be used, so error out if any are provided.
-  * enableremote: Fix re-enabling of existing gcrypt remotes, so
+  * enableremote: Fix re-enabling of special remotes that have a git
-    that eg, encryption key changes take effect. They were silently
+    url, so that eg, encryption key changes take effect. They were silently
     ignored, a reversion introduced in 6.20160527.
+  * gcrypt: Support re-enabling to change eg, encryption parameters.
+    This was never supported before.
 
  -- Joey Hess <id@joeyh.name>  Wed, 29 Mar 2017 12:41:46 -0400
 

Remote/GCrypt.hs

@@ -31,7 +31,6 @@ import qualified Git.Command
 import qualified Git.Config
 import qualified Git.GCrypt
 import qualified Git.Construct
-import qualified Git.Types as Git ()
 import qualified Annex.Branch
 import Config
 import Config.Cost
@@ -176,11 +175,18 @@ gCryptSetup _ mu _ c gc = go $ M.lookup "gitrepo" c
 	go Nothing = giveup "Specify gitrepo="
 	go (Just gitrepo) = do
 		(c', _encsetup) <- encryptionSetup c gc
-		inRepo $ Git.Command.run 
+
-			[ Param "remote", Param "add"
+		let url = Git.GCrypt.urlPrefix ++ gitrepo
-			, Param remotename
+		rs <- fromRepo Git.remotes
-			, Param $ Git.GCrypt.urlPrefix ++ gitrepo
+		case filter (\r -> Git.remoteName r == Just remotename) rs of
-			]
+			[] -> inRepo $ Git.Command.run 
+				[ Param "remote", Param "add"
+				, Param remotename
+				, Param url
+				]
+			(r:_)
+				| Git.repoLocation r == url -> noop
+				| otherwise -> error "Another remote with the same name already exists."		
 
 		setGcryptEncryption c' remotename
 

doc/bugs/git_annex_enableremote_ignoring_encryption_changes.mdwn

@@ -116,3 +116,5 @@ Yes, definitively. I enjoy using annex to backup and manage my data. I would lov
 Thanks
 
 Jörn
+
+> [[fixed|done]] --[[Joey]]

doc/bugs/git_annex_enableremote_ignoring_encryption_changes/comment_2_5b36cd7f8ec4dd4f8787b60959512157._comment

@@ -0,0 +1,26 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2017-04-07T16:58:42Z"
+ content="""
+Huh, so it seems that for gcrypt remotes, enableremote just doesn't
+call their setup function at all!
+
+Ah, it's because it sees the remote has an url, so it is not treated
+as a special remote, but as a regular git remote, and so the
+special remote encryption changes are ignored. (Since 6.20160527)
+
+So, enableremote needs to fail when it thinks it's enabling a regular git
+remote and has been passed some parameters which cannot apply to such a
+remote. Done.
+
+And, enableremote needs fixed to treat existing gcrypt remotes as special
+remotes. Done.
+
+Also, gcrypt special remotes didn't actually support being re-enabled
+either. I made that work. When an encryption key is added, that
+automatically makes it change the gcrypt-participants, too.
+
+I suppose enableremote could even be made to do the `GCRYPT_FULL_REPACK`
+and forced push, but that seems like too much for it to do!
+"""]]