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.

1 files changed, 26 insertions, 0 deletions

diff --git a/doc/bugs/git_annex_enableremote_ignoring_encryption_changes/comment_2_5b36cd7f8ec4dd4f8787b60959512157._comment b/doc/bugs/git_annex_enableremote_ignoring_encryption_changes/comment_2_5b36cd7f8ec4dd4f8787b60959512157._comment
new file mode 100644
index 000000000..22a6cdf60
--- /dev/null
+++ b/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!
+"""]]