rename files containing :

This is mostly to let the repo check out on windows w/o using cygwin's git.

But, bash completion is also crap with : , so ..

8 files changed, 96 insertions, 0 deletions

diff --git a/doc/bugs/git-annex-shell__58___gcryptsetup_permission_denied/comment_1_f4584158b35b80ece1060308883e2dc4._comment b/doc/bugs/git-annex-shell__58___gcryptsetup_permission_denied/comment_1_f4584158b35b80ece1060308883e2dc4._comment
new file mode 100644
index 000000000..6312a58a5
--- /dev/null
+++ b/doc/bugs/git-annex-shell__58___gcryptsetup_permission_denied/comment_1_f4584158b35b80ece1060308883e2dc4._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.47"
+ subject="comment 1"
+ date="2013-11-02T19:46:28Z"
+ content="""
+It seems to me that the `git-annex-shell` on the remote system must be too old a version to support the gcryptsetup command. You can check this by running `git-annex-shell` there and seeing if it lists gcryptsetup in its usage message.
+"""]]
diff --git a/doc/bugs/git-annex-shell__58___gcryptsetup_permission_denied/comment_2_a4d7aae848340771a9b8e2c87abeea42._comment b/doc/bugs/git-annex-shell__58___gcryptsetup_permission_denied/comment_2_a4d7aae848340771a9b8e2c87abeea42._comment
new file mode 100644
index 000000000..f2fb4f14f
--- /dev/null
+++ b/doc/bugs/git-annex-shell__58___gcryptsetup_permission_denied/comment_2_a4d7aae848340771a9b8e2c87abeea42._comment
@@ -0,0 +1,26 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkbpbjP5j8MqWt_K4NASwv0WvB8T4rQ-pM"
+ nickname="Fabrice"
+ subject="comment 2"
+ date="2013-11-02T21:53:37Z"
+ content="""
+The git-annex version on the remote server is the same as the one on the client, the latest one available from the ppa (4.20131024). When I run git-annex-shell on both computers, I obtain:
+[[!format sh \"\"\"
+git-annex-shell: bad parameters
+
+Usage: git-annex-shell [-c] command [parameters ...] [option ...]
+
+Plumbing commands:
+
+commit       DIRECTORY          commits any staged changes to the git-annex branch
+configlist   DIRECTORY          outputs relevant git configuration
+dropkey      DIRECTORY KEY ...  drops annexed content for specified keys
+gcryptsetup  DIRECTORY VALUE    sets up gcrypt repository
+inannex      DIRECTORY KEY ...  checks if keys are present in the annex
+recvkey      DIRECTORY KEY      runs rsync in server mode to receive content
+sendkey      DIRECTORY KEY      runs rsync in server mode to send content
+transferinfo DIRECTORY KEY      updates sender on number of bytes of content received
+\"\"\"]]
+
+Both sides seem to understand the gcryptsetup action. Actually, the message gcryptsetup permission denied comes from git-annex-shell, as far as I understand (and from the haskell source linked in the report). 
+"""]]
diff --git a/doc/bugs/git-annex-shell__58___gcryptsetup_permission_denied/comment_3_06bda101ad584b4b882de8b2e202d679._comment b/doc/bugs/git-annex-shell__58___gcryptsetup_permission_denied/comment_3_06bda101ad584b4b882de8b2e202d679._comment
new file mode 100644
index 000000000..863f401ce
--- /dev/null
+++ b/doc/bugs/git-annex-shell__58___gcryptsetup_permission_denied/comment_3_06bda101ad584b4b882de8b2e202d679._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.47"
+ subject="comment 3"
+ date="2013-11-02T23:51:13Z"
+ content="""
+I should have looked at that error message more closely. The gcryptsetup command will print a permission denied if the repository it's being run in already has a annex.uuid or already has a gcrypt id. Probably that latter needs to be relaxed for enableremote to work.
+"""]]
diff --git a/doc/bugs/git-annex-shell__58___gcryptsetup_permission_denied/comment_4_4fc6b25401b645cabc04b510bdfa6863._comment b/doc/bugs/git-annex-shell__58___gcryptsetup_permission_denied/comment_4_4fc6b25401b645cabc04b510bdfa6863._comment
new file mode 100644
index 000000000..e1049ce60
--- /dev/null
+++ b/doc/bugs/git-annex-shell__58___gcryptsetup_permission_denied/comment_4_4fc6b25401b645cabc04b510bdfa6863._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.47"
+ subject="comment 4"
+ date="2013-11-03T00:15:30Z"
+ content="""
+While I've fixed this bug, in my testing the bug only caused git-annex to fall back to accessing the remote repository using rsync, rather than using git-annex-shell to talk to it, and so `git annex get --from encryptedrepo` was able to retrieve files that were stored in that remote despite the bug. That may have failed for you for some other reason.
+
+You can set git.encryptedrepo.annex-gcrypt to to \"true\" to make it use the degraded rsync mode, or to \"shell\" to make it use git-annex-shell. Setting it to shell should be all that you need to do to recover from (or indeed, work around this bug).
+"""]]
diff --git a/doc/bugs/git-annex-shell__58___gcryptsetup_permission_denied/comment_5_4e193306801680bba433e75eb4dcba05._comment b/doc/bugs/git-annex-shell__58___gcryptsetup_permission_denied/comment_5_4e193306801680bba433e75eb4dcba05._comment
new file mode 100644
index 000000000..137638aa5
--- /dev/null
+++ b/doc/bugs/git-annex-shell__58___gcryptsetup_permission_denied/comment_5_4e193306801680bba433e75eb4dcba05._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkbpbjP5j8MqWt_K4NASwv0WvB8T4rQ-pM"
+ nickname="Fabrice"
+ subject="comment 5"
+ date="2013-11-03T11:24:28Z"
+ content="""
+There is something very strange that I did not notice in my first report. When I try `git annex get --from encryptedrepo` nothing happens in the sense that git annex is not even trying to connect to the remote (no ssh connection attempt) while git.encryptedrepo.annex-gcrypt is set to true. When I set it to shell, nothing happens either. 
+
+Another thing I did not report is that I tried the exact same manipulations with another server on which git annex is not installed. The `gcryptsetup permission denied` message was replaced by a `git-annex-shell not found` (or something similar), as expected. But the rest of the behavior was the same: no way to get the actual content with `git annex get --from`. Again, all of this is with 4.20131024, not with the ongoing version. 
+
+I'll try got do more test with the new version. 
+"""]]
diff --git a/doc/bugs/git-annex-shell__58___gcryptsetup_permission_denied/comment_6_76ccdf0542e76e4dbd61f3b3228d40ba._comment b/doc/bugs/git-annex-shell__58___gcryptsetup_permission_denied/comment_6_76ccdf0542e76e4dbd61f3b3228d40ba._comment
new file mode 100644
index 000000000..0ad9768f6
--- /dev/null
+++ b/doc/bugs/git-annex-shell__58___gcryptsetup_permission_denied/comment_6_76ccdf0542e76e4dbd61f3b3228d40ba._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.47"
+ subject="comment 6"
+ date="2013-11-04T17:12:05Z"
+ content="""
+It's entirely normal for `git annex get --from remote` to skip files that it does not think are present on the remote. 
+
+What does `git annex whereis` say?
+"""]]
diff --git a/doc/bugs/git-annex-shell__58___gcryptsetup_permission_denied/comment_7_cd964d0a375c5cba299bf2bbbbb86acb._comment b/doc/bugs/git-annex-shell__58___gcryptsetup_permission_denied/comment_7_cd964d0a375c5cba299bf2bbbbb86acb._comment
new file mode 100644
index 000000000..3a24f4349
--- /dev/null
+++ b/doc/bugs/git-annex-shell__58___gcryptsetup_permission_denied/comment_7_cd964d0a375c5cba299bf2bbbbb86acb._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkbpbjP5j8MqWt_K4NASwv0WvB8T4rQ-pM"
+ nickname="Fabrice"
+ subject="comment 7"
+ date="2013-11-04T18:54:54Z"
+ content="""
+`git annex whereis` says the files are not on the remote git, while they are because of the copy. If I do _exactly_ what's on the tip, that is if I clone the encrypted git just after having done `git annex copy --to encryptedbackup`, the remotes seems to ignore that it has the data. To have it working, I had to call `git annex sync` (push will do, I guess) in the original remote after doing the `git annex copy`. Then I can `git pull` and `git annex whereis` knows where the files are (or I can clone the encrypted remote after doing the sync/pull). 
+
+It seems a bit strange that the copy command does not record the propagation of the file to the encrypted git. I guess this is because gcrypt is the only special remote that stores also the git part, right? Would that be a good idea (and possible) to handle it in a special way? 
+
+Thanks Joey for everything, by the way, both the software and the amazing support via email and the website.
+"""]]
diff --git a/doc/bugs/git-annex-shell__58___gcryptsetup_permission_denied/comment_8_9bac87c85deb5bb15795df28533d0cde._comment b/doc/bugs/git-annex-shell__58___gcryptsetup_permission_denied/comment_8_9bac87c85deb5bb15795df28533d0cde._comment
new file mode 100644
index 000000000..da2fef585
--- /dev/null
+++ b/doc/bugs/git-annex-shell__58___gcryptsetup_permission_denied/comment_8_9bac87c85deb5bb15795df28533d0cde._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.47"
+ subject="comment 8"
+ date="2013-11-04T19:14:04Z"
+ content="""
+Right -- Normally a special remote doesn't include a git repository. And when using a regular git remote, `git-annex-shell` is used to receive files into the repository and it records immediately that the repo has the file so there's no need to sync in that case. So gcrypt is special in this way.
+
+For now, I have fixed the tip to show syncing after sending files to gcrypt. It might be the case that it would make sense to do a push of the git-annex branch automatically in that case, will have to think about that and see if people get tripped up on this.
+"""]]