diff options
| author |  Joey Hess <joeyh@joeyh.name> | 2017-04-07 14:10:21 -0400 |
|---|---|---|
| committer | Joey Hess <joeyh@joeyh.name> | 2017-04-07 14:10:34 -0400 |
| commit | e1e52ab130e4a67d001e0577010f8cd142860914 (patch) | |
| tree | 7f5346afa63d27de9b0c2013624a3e788402eb8f /doc | |
| parent | 536e5d9cc713d766690330668f6fb9b363d56d61 (diff) | |
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.
Diffstat (limited to 'doc')
| -rw-r--r-- | doc/bugs/git_annex_enableremote_ignoring_encryption_changes.mdwn | 2 | ||||
| -rw-r--r-- | doc/bugs/git_annex_enableremote_ignoring_encryption_changes/comment_2_5b36cd7f8ec4dd4f8787b60959512157._comment | 26 |
2 files changed, 28 insertions, 0 deletions
diff --git a/doc/bugs/git_annex_enableremote_ignoring_encryption_changes.mdwn b/doc/bugs/git_annex_enableremote_ignoring_encryption_changes.mdwn index e73b2ce8f..92a454c18 100644 --- a/doc/bugs/git_annex_enableremote_ignoring_encryption_changes.mdwn +++ b/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]] 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! +"""]] |