Recent changes to this wiki:

Add bug report about missing SHA3 support in the amd64 version
diff --git a/doc/bugs/SHA3__95____42___backends_missing_from_newest_official_amd64_Linux_builds.mdwn b/doc/bugs/SHA3__95____42___backends_missing_from_newest_official_amd64_Linux_builds.mdwn
new file mode 100644
index 0000000..b92e265
--- /dev/null
+++ b/doc/bugs/SHA3__95____42___backends_missing_from_newest_official_amd64_Linux_builds.mdwn
@@ -0,0 +1,51 @@
+### Please describe the problem.
+
+All the new wonderful SHA3_* backends are gone from the Linux AMD64 build of 5.20150825-g7826f84. They exist in the i386 version (5.20150824-g8529cb2), though. It's probably compiled without Cryptonite support or something.
+
+### What steps will reproduce the problem?
+
+Everything involving any of the SHA3_* backends result in an "unknown backend SHA3_*" error with the amd64 build (5.20150825-g7826f84). The i386 version (5.20150824-g8529cb2) works.
+
+    wget https://github.com/sunny256/utils/raw/master/tests/ga-fsck-size-files/annex-backends.tar.gz
+    tar xzf annex-backends.tar.gz
+    cd annex-backends
+    git annex fsck
+
+results in
+
+    [snip]
+    fsck SHA384.txt (checksum...)
+    ok
+    fsck SHA384E.txt (checksum...)
+    ok
+
+      skipping SHA3_224.txt (unknown backend SHA3_224)
+
+      skipping SHA3_224E.txt (unknown backend SHA3_224E)
+
+      skipping SHA3_256.txt (unknown backend SHA3_256)
+
+      skipping SHA3_256E.txt (unknown backend SHA3_256E)
+
+      skipping SHA3_384.txt (unknown backend SHA3_384)
+
+      skipping SHA3_384E.txt (unknown backend SHA3_384E)
+
+      skipping SHA3_512.txt (unknown backend SHA3_512)
+
+      skipping SHA3_512E.txt (unknown backend SHA3_512E)
+    fsck SHA512.txt (checksum...)
+    ok
+    fsck SHA512E.txt (checksum...)
+    ok
+    [snip]
+    fsck WORM.txt ok
+    (recording state in git...)
+
+### What version of git-annex are you using? On what operating system?
+
+Newest official builds from downloads.kitenet.net . Debian GNU/Linux all the way.
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+Oh, yes. It rules. :) One of the most important programs I use because I have all my valuable stuff in it. My files have never been safer.

diff --git a/doc/bugs/wget_invocation_should_get_timeout_options.mdwn b/doc/bugs/wget_invocation_should_get_timeout_options.mdwn
new file mode 100644
index 0000000..d78179d
--- /dev/null
+++ b/doc/bugs/wget_invocation_should_get_timeout_options.mdwn
@@ -0,0 +1,14 @@
+### Please describe the problem.
+
+Currently if download stalls the whole 'annex get' stalls -- I have been watching the terminal with 0% for an hour now ;)
+
+You could test that on http://github.com/datalad/mlbooks  annex, just get
+G.James_D.Witten_T.Hastie_R.Tibshirani-An_Introduction_to_Statistical_Learning_with_Applications_in_R.pdf
+
+original url for the file is http://www-bcf.usc.edu/~gareth/ISL/ISLR%20Fourth%20Printing.pdf
+and wgetting works for me on some boxes but not on the other, forgot why so
+
+### What version of git-annex are you using? On what operating system?
+
+5.20150706+gitgefc3bcd-1~ndall+1 and tried in clean debian sid docker with  5.20150812-2
+

diff --git a/doc/bugs/Windows:_git_annex_get_fails_with_rsync:_Failed_to_exec_ssh.mdwn b/doc/bugs/Windows:_git_annex_get_fails_with_rsync:_Failed_to_exec_ssh.mdwn
index 23932a5..b0f8b4e 100644
--- a/doc/bugs/Windows:_git_annex_get_fails_with_rsync:_Failed_to_exec_ssh.mdwn
+++ b/doc/bugs/Windows:_git_annex_get_fails_with_rsync:_Failed_to_exec_ssh.mdwn
@@ -26,8 +26,8 @@ On windows, fails getting files with the following error : "rsync: Failed to exe
 
 ### What version of git-annex are you using? On what operating system?
 
-Git for windows, from http://git-scm.com/downloads (referenced from https://git-annex.branchable.com/install/Windows/), i.e. Git 2.5.0
-Git annex gotten from https://downloads.kitenet.net/git-annex/windows/current/ as of 2015-08-19 08:43 (GitAnnexDistribution {distributionUrl = "https://downloads.kitenet.net/git-annex/windows/current/git-annex-installer.exe", distributionKey = Key {keyName = "76e06059fe0146d228578a1eef42d92f94f4d89b5b00798f317083f90a73e006.exe", keyBackendName = "SHA256E", keySize = Just 24420678, keyMtime = Nothing, keyChunkSize = Nothing, keyChunkNum = Nothing}, distributionVersion = "5.20150819", distributionReleasedate = 2015-08-24 21:24:56.240184 UTC, distributionUrgentUpgrade = Nothing})
+* Git for windows, from http://git-scm.com/downloads (referenced from https://git-annex.branchable.com/install/Windows/), i.e. Git 2.5.0
+* Git annex gotten from https://downloads.kitenet.net/git-annex/windows/current/ as of 2015-08-19 08:43 (GitAnnexDistribution {distributionUrl = "https://downloads.kitenet.net/git-annex/windows/current/git-annex-installer.exe", distributionKey = Key {keyName = "76e06059fe0146d228578a1eef42d92f94f4d89b5b00798f317083f90a73e006.exe", keyBackendName = "SHA256E", keySize = Just 24420678, keyMtime = Nothing, keyChunkSize = Nothing, keyChunkNum = Nothing}, distributionVersion = "5.20150819", distributionReleasedate = 2015-08-24 21:24:56.240184 UTC, distributionUrgentUpgrade = Nothing})
 
 
 ### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)

Added a comment: git 2.5 for windows seems the culprit whereas mysygit 1.9 works
diff --git a/doc/bugs/Windows:_git_annex_get_fails_with_rsync:_Failed_to_exec_ssh/comment_2_fddfc4c5a7428f924ec2ebbc7175a520._comment b/doc/bugs/Windows:_git_annex_get_fails_with_rsync:_Failed_to_exec_ssh/comment_2_fddfc4c5a7428f924ec2ebbc7175a520._comment
new file mode 100644
index 0000000..77d28f0
--- /dev/null
+++ b/doc/bugs/Windows:_git_annex_get_fails_with_rsync:_Failed_to_exec_ssh/comment_2_fddfc4c5a7428f924ec2ebbc7175a520._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="OlivierBerger"
+ subject="git 2.5 for windows seems the culprit whereas mysygit 1.9 works"
+ date="2015-08-27T15:02:14Z"
+ content="""
+I've removed Git for windows 2.5, and installed the latest msysgit 1.9, and it seems that this works much better.
+
+However, I have to invoke git-annex from the command-line through its full path with :
+    \"C:\Program Files\Git\cmd\git-annex.exe\" get .
+
+I guess this gives hope :-)
+"""]]

Added a comment: Using --debug gives this
diff --git a/doc/bugs/Windows:_git_annex_get_fails_with_rsync:_Failed_to_exec_ssh/comment_1_f8b55d954784346f2e97d1d3ec36bedb._comment b/doc/bugs/Windows:_git_annex_get_fails_with_rsync:_Failed_to_exec_ssh/comment_1_f8b55d954784346f2e97d1d3ec36bedb._comment
new file mode 100644
index 0000000..59282f6
--- /dev/null
+++ b/doc/bugs/Windows:_git_annex_get_fails_with_rsync:_Failed_to_exec_ssh/comment_1_f8b55d954784346f2e97d1d3ec36bedb._comment
@@ -0,0 +1,35 @@
+[[!comment format=mdwn
+ username="OlivierBerger"
+ subject="Using --debug gives this"
+ date="2015-08-27T14:26:54Z"
+ content="""
+Here's a transcript of the --debug output (edited to mask file name and servername)
+
+[[!format sh \"\"\"
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+
+$ git annex get big\ file --debug
+[2015-08-27 16:21:36.8295694] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"ls-files\",\"--cached\",\"-z\",\"--\",\"big file\"]
+get big file [2015-08-27 16:21:36.8495982] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"show-ref\",\"git-annex\"]
+[2015-08-27 16:21:36.8796414] process done ExitSuccess
+[2015-08-27 16:21:36.8796414] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"show-ref\",\"--hash\",\"refs/heads/git-annex\"]
+[2015-08-27 16:21:36.8996702] process done ExitSuccess
+[2015-08-27 16:21:36.8996702] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"log\",\"refs/heads/git-annex..f98a471b32f963a0bf816800d766690d53ef150d\",\"-n1\",\"--pretty=%H\"]
+[2015-08-27 16:21:36.919699] process done ExitSuccess
+[2015-08-27 16:21:36.9297134] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"log\",\"refs/heads/git-annex..15e7ab1f3b70629db852f8565bf988b25af02ec6\",\"-n1\",\"--pretty=%H\"]
+[2015-08-27 16:21:36.9497422] process done ExitSuccess
+[2015-08-27 16:21:36.9497422] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"log\",\"refs/heads/git-annex..1e04e80b99361e5b516d3a266bbc7b1d1478dff5\",\"-n1\",\"--pretty=%H\"]
+[2015-08-27 16:21:36.9897998] process done ExitSuccess
+[2015-08-27 16:21:36.9897998] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"cat-file\",\"--batch\"]
+(from origin...) [2015-08-27 16:21:37.0098286] read: rsync [\"--progress\",\"--inplace\",\"-e\",\"'ssh' '-T' 'gitolite3@server' 'git-annex-shell ''sendkey'' ''/~/testing'' ''--debug'' ''SHA256E-s264620717--23e70aae588a049d52909cd68067cf2885429ae557f52e3f2d6033260c3ad9ea.mp4'' --uuid f8ef7445-2ccc-4871-a95a-7e4325fc763d ''--'' ''remoteuuid=8fb9f88a-1105-4278-aa85-7b5c78a0e0e5'' ''direct=1'' ''associatedfile=big file'' ''--'''\",\"--\",\"dummy:\",\".git/annex/tmp/SHA256E-s264620717--23e70aae588a049d52909cd68067cf2885429ae557f52e3f2d6033260c3ad9ea.mp4\"]
+rsync: Failed to exec ssh: No such file or directory (2)
+rsync error: error in IPC code (code 14) at /home/lapo/package/rsync-3.0.9-1/src/rsync-3.0.9/pipe.c(84) [Receiver=3.0.9]
+rsync: writefd_unbuffered failed to write 4 bytes to socket [Receiver]: Broken pipe (32)
+rsync error: error in IPC code (code 14) at /home/lapo/package/rsync-3.0.9-1/src/rsync-3.0.9/io.c(1532) [Receiver=3.0.9]
+[2015-08-27 16:21:37.0799294] process done ExitFailure 14
+
+
+# End of transcript or log.
+\"\"\"]]
+"""]]

diff --git a/doc/bugs/Windows:_git_annex_get_fails_with_rsync:_Failed_to_exec_ssh.mdwn b/doc/bugs/Windows:_git_annex_get_fails_with_rsync:_Failed_to_exec_ssh.mdwn
new file mode 100644
index 0000000..23932a5
--- /dev/null
+++ b/doc/bugs/Windows:_git_annex_get_fails_with_rsync:_Failed_to_exec_ssh.mdwn
@@ -0,0 +1,36 @@
+### Please describe the problem.
+
+On windows, fails getting files with the following error : "rsync: Failed to exec ssh: No such file or directory". The server runs gitolite. I've tested from a Linux client, and it works.
+
+    $ git annex get big\ file
+    get big file (from origin...) rsync: Failed to exec ssh: No such file or directory (2)
+    rsync error: error in IPC code (code 14) at /home/lapo/package/rsync-3.0.9-1/src/rsync-3.0.9/pipe.c(84) [Receiver=3.0.9]
+    rsync: connection unexpectedly closed (0 bytes received so far) [Receiver]
+    rsync error: error in IPC code (code 14) at /home/lapo/package/rsync-3.0.9-1/src/rsync-3.0.9/io.c(605) [Receiver=3.0.9]
+    
+    
+      rsync failed -- run git annex again to resume file transfer
+    
+      Unable to access these remotes: origin
+    
+      Try making some of these repositories available:
+            dc8840b6-c0ec-4166-adcc-f821f3ee0216 -- olivier@myhost:~/git/whatever/testing
+            f8ef7445-2ccc-4871-a95a-7e4325fc763d -- gitolite3@aserver:~/repositories/testing.git [origin]
+    failed
+    git-annex: get: 1 failed
+
+
+### What steps will reproduce the problem?
+
+'git clone' from a repo containing a big file, then git annex init locally, then git get for the file contained in the repo
+
+### What version of git-annex are you using? On what operating system?
+
+Git for windows, from http://git-scm.com/downloads (referenced from https://git-annex.branchable.com/install/Windows/), i.e. Git 2.5.0
+Git annex gotten from https://downloads.kitenet.net/git-annex/windows/current/ as of 2015-08-19 08:43 (GitAnnexDistribution {distributionUrl = "https://downloads.kitenet.net/git-annex/windows/current/git-annex-installer.exe", distributionKey = Key {keyName = "76e06059fe0146d228578a1eef42d92f94f4d89b5b00798f317083f90a73e006.exe", keyBackendName = "SHA256E", keySize = Just 24420678, keyMtime = Nothing, keyChunkSize = Nothing, keyChunkNum = Nothing}, distributionVersion = "5.20150819", distributionReleasedate = 2015-08-24 21:24:56.240184 UTC, distributionUrgentUpgrade = Nothing})
+
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+Yes :-) Only on linux so far and trying on windows now :-/
+

diff --git a/doc/bugs/--help_should_not_demand_being_in_the_git_repo.mdwn b/doc/bugs/--help_should_not_demand_being_in_the_git_repo.mdwn
new file mode 100644
index 0000000..0a7aa43
--- /dev/null
+++ b/doc/bugs/--help_should_not_demand_being_in_the_git_repo.mdwn
@@ -0,0 +1,24 @@
+### Please describe the problem.
+
+subj -- happens for sync and merge commands at least
+
+
+[[!format sh """
+$> git annex sync --help
+git-annex: Not in a git repository.
+
+$> git annex merge --help
+git-annex: Not in a git repository.
+
+$> git annex version     
+git-annex version: 5.20150819+gitgc587698-1~ndall+1
+build flags: Assistant Webapp Webapp-secure Pairing Testsuite S3 WebDAV Inotify DBus DesktopNotify XMPP DNS Feeds Quvi TDFA Database
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 SHA1E SHA1 MD5E MD5 WORM URL
+remote types: git gcrypt S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external
+
+"""]]
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+YES -- lots of luck ;)
+

Added a comment: Same problem
diff --git a/doc/forum/sync_stages_deletions_on_remote/comment_5_f3350d336c6c66c3aacc7caade2ef12c._comment b/doc/forum/sync_stages_deletions_on_remote/comment_5_f3350d336c6c66c3aacc7caade2ef12c._comment
new file mode 100644
index 0000000..55f0533
--- /dev/null
+++ b/doc/forum/sync_stages_deletions_on_remote/comment_5_f3350d336c6c66c3aacc7caade2ef12c._comment
@@ -0,0 +1,31 @@
+[[!comment format=mdwn
+ username="edward"
+ subject="Same problem"
+ date="2015-08-27T09:24:38Z"
+ content="""
+I think I'm having the same problem. See my comments on [[bugs/git annex sync deleted a bunch of files (not expected)]]
+
+I've run `git annex sync` or `git annex webapp` on the laptop annex, then `git annex sync` on the external drive. I'm pretty sure some of the syncs have been interrupted. Does it help to see the .git/config from the external drive?
+
+    [core]
+    	repositoryformatversion = 0
+    	filemode = true
+    	bare = false
+    	logallrefupdates = true
+    [remote \"origin\"]
+    	url = /home/edward/annex
+    	fetch = +refs/heads/*:refs/remotes/origin/*
+    	annex-uuid = 38d109c9-7f5f-47cd-b15a-7b2beac22c64
+    [branch \"master\"]
+    	remote = origin
+    	merge = refs/heads/master
+    [annex]
+    	uuid = 822dec0f-a0d3-42f6-b0dc-a47b6bf91944
+    	version = 5
+    [remote \"x230\"]
+    	url = /home/edward/annex
+    	fetch = +refs/heads/*:refs/remotes/x230/*
+    	annex-uuid = 38d109c9-7f5f-47cd-b15a-7b2beac22c64
+
+Observations about my config, I have `bare = false`, which is correct. Do you think it is a problem that I have two remotes, `\"origin\"` and `\"x230\"` pointing at the same location?
+"""]]

Added a comment: I've ended up with lots of staged deletes
diff --git a/doc/bugs/git_annex_sync_deleted_a_bunch_of_files___40__not_expected__41__/comment_6_ccfa7150ee87a5ce5bc9189e3a0dcb86._comment b/doc/bugs/git_annex_sync_deleted_a_bunch_of_files___40__not_expected__41__/comment_6_ccfa7150ee87a5ce5bc9189e3a0dcb86._comment
new file mode 100644
index 0000000..bed21ae
--- /dev/null
+++ b/doc/bugs/git_annex_sync_deleted_a_bunch_of_files___40__not_expected__41__/comment_6_ccfa7150ee87a5ce5bc9189e3a0dcb86._comment
@@ -0,0 +1,27 @@
+[[!comment format=mdwn
+ username="edward"
+ subject="I've ended up with lots of staged deletes"
+ date="2015-08-27T08:29:55Z"
+ content="""
+I have the same problem with another annex. I ran the webapp using `git annex webapp` in the annex on my laptop hard drive. It seemed to update and sync with the annex on my external USB drive, but now when I run `git status` in the annex directory on the drive it has staged lots of deletes. I don't understand what is going on here. Both annexes are in indirect mode.
+
+    On branch master
+    Your branch is behind 'origin/master' by 61 commits, and can be fast-forwarded.
+      (use \"git pull\" to update your local branch)
+    Changes to be committed:
+      (use \"git reset HEAD <file>...\" to unstage)
+    
+            deleted:    4angle_tech_ltd/032-570247_20150312-074413_30313.pdf
+            deleted:    4angle_tech_ltd/032-570247_20150312_09486613.pdf
+            deleted:    android/RUU_PRIMO_U_ICS_40A_HTC_Europe_2.22.401.1_Radio_20.76.30.0835U_3831.19.00.120_release_273801_signed.exe
+            deleted:    article/Fukuyama-End-of-history-article.pdf
+            deleted:    article/The Selling of the Avocado - Health - The Atlantic.html
+
+The symlinks and the data are still on the disk, as is the data that the symlinks point to.
+
+    $ ls 4angle_tech_ltd -l
+    total 8
+    lrwxrwxrwx 1 edward edward 197 Mar 15 08:39 032-570247_20150312-074413_30313.pdf -> ../.git/annex/objects/qM/mj/SHA256E-s21598--efb39974c5253d8059f0fe991c1b76aba8455d8439eefd6cd8943503f85109c0.pdf/SHA256E-s21598--efb39974c5253d8059f0fe991c1b76aba8455d8439eefd6cd8943503f85109c0.pdf
+    lrwxrwxrwx 1 edward edward 197 Mar 15 08:39 032-570247_20150312_09486613.pdf -> ../.git/annex/objects/JX/XP/SHA256E-s93692--8e88ca5071bc2155acfe16a41c9c6b756fecc6515cfb7907105dd1a83e73f57a.pdf/SHA256E-s93692--8e88ca5071bc2155acfe16a41c9c6b756fecc6515cfb7907105dd1a83e73f57a.pdf
+    $ 
+"""]]

diff --git a/doc/users/dave.mdwn b/doc/users/dave.mdwn
new file mode 100644
index 0000000..0a18da5
--- /dev/null
+++ b/doc/users/dave.mdwn
@@ -0,0 +1 @@
+IM DAVE

Added a comment: re: UnicodeDecodeError
diff --git a/doc/special_remotes/glacier/comment_13_6ef8735fbd357a09dafe254c8da3b1a8._comment b/doc/special_remotes/glacier/comment_13_6ef8735fbd357a09dafe254c8da3b1a8._comment
new file mode 100644
index 0000000..58ac2ad
--- /dev/null
+++ b/doc/special_remotes/glacier/comment_13_6ef8735fbd357a09dafe254c8da3b1a8._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="dave@2ab82f485adf7e2ce787066e35f5f9789bff430b"
+ nickname="dave"
+ subject="re: UnicodeDecodeError"
+ date="2015-08-26T21:54:08Z"
+ content="""
+This part:
+
+      File \"/usr/lib/python2.7/httplib.py\", line 833, in _send_output
+        msg += message_body
+    UnicodeDecodeError: 'ascii' codec can't decode byte 0x8c in position 0: ordinal not in range(128)
+
+Tells me that you need to read [glacier-cli problem report #61](https://github.com/basak/glacier-cli/issues/61).
+
+There is a one-line [code change in a library named boto](https://github.com/felixonmars/boto/commit/0676eaf014f56279908cdd3409a5bb6895e86bf6) (glacier-cli depends on it) which will fix this.  (And probably that change will get merged in sometime, so you won't have to do this anymore.)
+"""]]

Added a comment: like dropbox, with your own cloud
diff --git a/doc/forum/Change_remote_server_address/comment_2_93a4c44d552efe6d51584e0aab3605e7._comment b/doc/forum/Change_remote_server_address/comment_2_93a4c44d552efe6d51584e0aab3605e7._comment
new file mode 100644
index 0000000..84ec29e
--- /dev/null
+++ b/doc/forum/Change_remote_server_address/comment_2_93a4c44d552efe6d51584e0aab3605e7._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="hasard@aa44fbf6c0a991a7b76fb8a118cc0b274f528de1"
+ nickname="hasard"
+ subject="like dropbox, with your own cloud "
+ date="2015-08-26T17:49:16Z"
+ content="""
+just to be complete: during setup some useful assistant may have created rsa keys so that the assistant can access remote hosts without password and following the update of .git/config you probably will need to update .ssh/config as well.
+ 
+Like many things with git annex and the assistant, its just \"like dropbox with your own cloud\", but you need first to become expert in editing .git/config and .ssh/config. 
+"""]]

diff --git a/doc/bugs/fails_to_addurl_to_file:__47____47____47___in_the_most_recent_snapshot_build.mdwn b/doc/bugs/fails_to_addurl_to_file:__47____47____47___in_the_most_recent_snapshot_build.mdwn
new file mode 100644
index 0000000..4a57557
--- /dev/null
+++ b/doc/bugs/fails_to_addurl_to_file:__47____47____47___in_the_most_recent_snapshot_build.mdwn
@@ -0,0 +1,122 @@
+### Please describe the problem.
+
+datalad tests started to fail whenever I upgraded to todays fresh snapshot build.  But the reason is somewhat bizzar since addurl works (with the same output in --debug for curl invocation) if I downgrade to the snapshot build from few days back.  And I don't see any obviously related changes in the git log since prev snapshot :-/
+
+### What version of git-annex are you using? On what operating system?
+
+5.20150826+gitg87972f5-1~ndall+1  custom standalone build on (neuro)debian
+
+### Please provide any additional information below.
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+$> git-annex addurl --file=test-annex.dat --debug 'file:///tmp/datalad_temp_testrepo_NKOjKp/test.dat'
+[2015-08-26 10:45:06.289638] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","git-annex"]
+[2015-08-26 10:45:06.291676] process done ExitSuccess
+[2015-08-26 10:45:06.291908] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","--hash","refs/heads/git-annex"]
+[2015-08-26 10:45:06.293961] process done ExitSuccess
+[2015-08-26 10:45:06.294297] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","log","refs/heads/git-annex..8a3167950d25c6626db5c31c334b024f43d132d8","-n1","--pretty=%H"]
+[2015-08-26 10:45:06.296672] process done ExitSuccess
+[2015-08-26 10:45:06.297441] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch"]
+[2015-08-26 10:45:06.300078] read: quvi ["--version"]
+[2015-08-26 10:45:06.303888] process done ExitSuccess
+[2015-08-26 10:45:06.304279] call: quvi ["--verbosity","mute","--support","file:///tmp/datalad_temp_testrepo_NKOjKp/test.dat"]
+[2015-08-26 10:45:06.31382] process done ExitFailure 65
+addurl test-annex.dat (downloading file:///tmp/datalad_temp_testrepo_NKOjKp/test.dat ...) 
+[2015-08-26 10:45:06.314824] call: curl ["-f","-L","-C","-","-#","-o","/tmp/datalad_temp_testrepo_NKOjKp/.git/annex/tmp/URL-s4--file&c%%%tmp%datalad_temp_testrepo_NKOjKp%test.dat","file:///tmp/datalad_temp_testrepo_NKOjKp/test.dat","--user-agent","git-annex/5.20150826+gitg87972f5-1~ndall+1"]
+[2015-08-26 10:45:06.319563] process done ExitFailure (-11)
+failed
+git-annex: addurl: 1 failed
+
+
+$> acpolicy git-annex-standalone                                                                     
+git-annex-standalone:
+  Installed: 5.20150826+gitg87972f5-1~ndall+1
+  Candidate: 5.20150826+gitg87972f5-1~ndall+1
+  Version table:
+ *** 5.20150826+gitg87972f5-1~ndall+1 0
+        100 /var/lib/dpkg/status
+     5.20150819+gitgc587698-1~ndall+1 0
+        500 http://neuro.debian.net/debian/ stretch/main amd64 Packages
+
+# downgrading to previous snapshot
+
+$> sudo apt-get install git-annex-standalone=5.20150819+gitgc587698-1~ndall+1
+[sudo] password for yoh: 
+Reading package lists... Done
+Building dependency tree       
+Reading state information... Done
+The following packages were automatically installed and are no longer required:
+  gir1.2-gtop-2.0 gir1.2-vte-2.90 gstreamer0.10-plugins-ugly icu-devtools libb-hooks-endofscope-perl libbit-vector-perl libcamel-1.2-49 libcarp-clan-perl libcmis-0.4-4
+  libconstantine-java libdate-calc-perl libdate-calc-xs-perl libdirac-encoder0 libdvbpsi9 libebackend-1.2-7 libebook-1.2-14 libebook-contacts-1.2-0 libecal-1.2-16
+  libedata-book-1.2-20 libedata-cal-1.2-23 libedataserver-1.2-18 libegl1-mesa-drivers libelfg0 libgdata19 libgdict-1.0-6 libghc-adjunctions-dev libghc-base-unicode-symbols-dev
+  libghc-errors-dev libghc-failure-dev libghc-idna-dev libghc-kan-extensions-dev libghc-keys-dev libghc-pointed-dev libghc-publicsuffixlist-dev libghc-punycode-dev
+  libghc-ranges-dev libghc-stringprep-dev libghc-text-icu-dev libgit2-21 libglew1.11 libglew1.9 libgnutls26 libgphoto2-port10 libgsoap5 libgtkhtml-4.0-0 libgtkhtml-4.0-common
+  libgtkhtml-editor-4.0-0 libgtop2-7 libicu-dev libinput5 libisl10 libjaffl-java libjim0.75 libkscreen1 libmediaart-1.0-0 libmodello-java libnamespace-clean-perl libopenobex1
+  libopenvg1-mesa liborcus-0.8-0 libplexus-digest-java libplist2 libqcustomplot1.2 libqscintilla2-11 librhythmbox-core8 librygel-core-2.4-2 librygel-renderer-2.4-2
+  librygel-renderer-gst-2.4-2 librygel-server-2.4-2 libssh-4 libsub-identify-perl libvariable-magic-perl libvncclient0 libvncserver0 libvpx1 libwps-0.3-3 libx264-142 libx265-43
+  obex-data-server publicsuffix
+Use 'apt-get autoremove' to remove them.
+Suggested packages:
+  bup tahoe-lafs
+The following packages will be DOWNGRADED:
+  git-annex-standalone
+0 upgraded, 0 newly installed, 1 downgraded, 0 to remove and 888 not upgraded.
+Need to get 0 B/23.9 MB of archives.
+After this operation, 13.3 kB disk space will be freed.
+Do you want to continue? [Y/n] 
+dpkg: warning: downgrading git-annex-standalone from 5.20150826+gitg87972f5-1~ndall+1 to 5.20150819+gitgc587698-1~ndall+1
+(Reading database ... 513649 files and directories currently installed.)
+Preparing to unpack .../git-annex-standalone_5.20150819+gitgc587698-1~ndall+1_amd64.deb ...
+Unpacking git-annex-standalone (5.20150819+gitgc587698-1~ndall+1) over (5.20150826+gitg87972f5-1~ndall+1) ...
+Processing triggers for man-db (2.7.0.2-5) ...
+Setting up git-annex-standalone (5.20150819+gitgc587698-1~ndall+1) ...
+Processing triggers for libc-bin (2.19-18) ...
+
+
+hopa:/tmp/datalad_temp_testrepo_NKOjKp
+$> git-annex addurl --file=test-annex.dat --debug 'file:///tmp/datalad_temp_testrepo_NKOjKp/test.dat'
+[2015-08-26 10:45:43.856957] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","git-annex"]
+[2015-08-26 10:45:43.859253] process done ExitSuccess
+[2015-08-26 10:45:43.859507] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","--hash","refs/heads/git-annex"]
+[2015-08-26 10:45:43.861503] process done ExitSuccess
+[2015-08-26 10:45:43.861842] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","log","refs/heads/git-annex..8a3167950d25c6626db5c31c334b024f43d132d8","-n1","--pretty=%H"]
+[2015-08-26 10:45:43.864027] process done ExitSuccess
+[2015-08-26 10:45:43.864822] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch"]
+[2015-08-26 10:45:43.867559] read: quvi ["--version"]
+[2015-08-26 10:45:43.871844] process done ExitSuccess
+[2015-08-26 10:45:43.872416] call: quvi ["--verbosity","mute","--support","file:///tmp/datalad_temp_testrepo_NKOjKp/test.dat"]
+[2015-08-26 10:45:43.88296] process done ExitFailure 65
+addurl test-annex.dat (downloading file:///tmp/datalad_temp_testrepo_NKOjKp/test.dat ...) 
+[2015-08-26 10:45:43.883939] call: curl ["-f","-L","-C","-","-#","-o","/tmp/datalad_temp_testrepo_NKOjKp/.git/annex/tmp/URL-s4--file&c%%%tmp%datalad_temp_testrepo_NKOjKp%test.dat","file:///tmp/datalad_temp_testrepo_NKOjKp/test.dat","--user-agent","git-annex/5.20150819+gitgc587698-1~ndall+1"]
+######################################################################## 100.0%
+[2015-08-26 10:45:43.889054] process done ExitSuccess
+[2015-08-26 10:45:43.889446] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","check-attr","-z","--stdin","annex.backend","annex.numcopies","--"]
+[2015-08-26 10:45:43.89022] read: git ["--version"]
+[2015-08-26 10:45:43.891664] process done ExitSuccess
+ok
+(recording state in git...)
+[2015-08-26 10:45:43.896364] feed: xargs ["-0","git","--git-dir=.git","--work-tree=.","--literal-pathspecs","add","--"]
+[2015-08-26 10:45:43.899267] process done ExitSuccess
+[2015-08-26 10:45:43.899949] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","hash-object","-w","--stdin-paths","--no-filters"]
+[2015-08-26 10:45:43.901383] feed: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","update-index","-z","--index-info"]
+[2015-08-26 10:45:43.905978] process done ExitSuccess
+[2015-08-26 10:45:43.906404] process done ExitSuccess
+[2015-08-26 10:45:43.906633] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","--hash","refs/heads/git-annex"]
+[2015-08-26 10:45:43.908796] process done ExitSuccess
+[2015-08-26 10:45:43.909363] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","write-tree"]
+[2015-08-26 10:45:43.912179] process done ExitSuccess
+[2015-08-26 10:45:43.912423] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","commit-tree","0ece4d39e673b48c886ccfded0bb4c588596e6d6","--no-gpg-sign","-p","refs/heads/git-annex"]
+[2015-08-26 10:45:43.915128] process done ExitSuccess
+[2015-08-26 10:45:43.915362] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","update-ref","refs/heads/git-annex","0f17facd87dbca08de5bc4d9c29bc7004557d4cf"]
+[2015-08-26 10:45:43.9179] process done ExitSuccess
+
+
+
+# End of transcript or log.
+"""]]
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+

desmilet
diff --git a/doc/templates/bugtemplate.mdwn b/doc/templates/bugtemplate.mdwn
index 711b537..f255df9 100644
--- a/doc/templates/bugtemplate.mdwn
+++ b/doc/templates/bugtemplate.mdwn
@@ -17,6 +17,6 @@
 # End of transcript or log.
 """]]
 
-### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders ;)
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
 
 

add positive feedback prompt
diff --git a/doc/templates/bugtemplate.mdwn b/doc/templates/bugtemplate.mdwn
index 6214e8f..711b537 100644
--- a/doc/templates/bugtemplate.mdwn
+++ b/doc/templates/bugtemplate.mdwn
@@ -16,3 +16,7 @@
 
 # End of transcript or log.
 """]]
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders ;)
+
+

Added a comment: WHEREIS -- is it better to just report failure to avoid duplicates?
diff --git a/doc/design/external_special_remote_protocol/comment_17_8dc7bbf485c9385a4b506e8b8fa934fe._comment b/doc/design/external_special_remote_protocol/comment_17_8dc7bbf485c9385a4b506e8b8fa934fe._comment
new file mode 100644
index 0000000..55e8c12
--- /dev/null
+++ b/doc/design/external_special_remote_protocol/comment_17_8dc7bbf485c9385a4b506e8b8fa934fe._comment
@@ -0,0 +1,23 @@
+[[!comment format=mdwn
+ username="https://me.yahoo.com/a/EbvxpTI_xP9Aod7Mg4cwGhgjrCrdM5s-#7c0f4"
+ subject="WHEREIS -- is it better to just report failure to avoid duplicates?"
+ date="2015-08-26T14:22:49Z"
+ content="""
+I wonder how should I utilize this new API (WHEREIS) in my case:  it seems just to lead to duplication of whereis information in my case of a special remote to support extracting of content from archives. If I make it to reply with the same url (which is not \"public\" per se, i.e. can't be used by annex directly) I just get it duplicated:
+
+    $> git annex whereis simple.txt
+    whereis simple.txt (1 copy) 
+      	82025765-5cac-4571-91ed-637620ec6fc7 -- [annexed-archives]
+    
+      annexed-archives: dl+archive:SHA256E-s173--5df2eeab61ea7d6479533d4e6b07c6bcfae46e040cad8cb1fc579f9f18c90790.tar.gz/a/d/%20%22%27%3Ba%26b%26cd%20%60%7C%20
+      annexed-archives: dl+archive:SHA256E-s173--5df2eeab61ea7d6479533d4e6b07c6bcfae46e040cad8cb1fc579f9f18c90790.tar.gz/a/d/%20%22%27%3Ba%26b%26cd%20%60%7C%20
+    ok
+
+if I \"explain\" it a bit, also somewhat duplicate:
+
+    annexed-archives: file a/d/%20%22%27%3Ba%26b%26cd%20%60%7C%20 within archive SHA256E-s173--5df2eeab61ea7d6479533d4e6b07c6bcfae46e040cad8cb1fc579f9f18c90790.tar.gz
+    annexed-archives: dl+archive:SHA256E-s173--5df2eeab61ea7d6479533d4e6b07c6bcfae46e040cad8cb1fc579f9f18c90790.tar.gz/a/d/%20%22%27%3Ba%26b%26cd%20%60%7C%20
+
+But if I just reply with \"WHEREIS-FAILURE\" it becomes more sensible (no duplicates), but I feel that then better documentation for this feature get adjusted to describe
+that it is only to complement information already known to annex, and not really to \"provide any information about ways to access the content of a key stored in it\".  Or have I missed the point? ;)
+"""]]

Added a comment: recoll: there's a Unity Lens for it
diff --git a/doc/forum/Searching_metadata_and_file_content__63__/comment_4_b8fbd129664c9680cd77f89185974741._comment b/doc/forum/Searching_metadata_and_file_content__63__/comment_4_b8fbd129664c9680cd77f89185974741._comment
new file mode 100644
index 0000000..fc94528
--- /dev/null
+++ b/doc/forum/Searching_metadata_and_file_content__63__/comment_4_b8fbd129664c9680cd77f89185974741._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="jean.jordaan@4bb3bd508a9eb0a4bab5d1b587dadd2b6c4a7edc"
+ nickname="jean.jordaan"
+ subject="recoll: there's a Unity Lens for it"
+ date="2015-08-26T13:04:12Z"
+ content="""
+I see there is an Ubuntu Unity search lens for recoll: http://www.webupd8.org/2012/03/recoll-lens-full-text-search-unity-lens.html
+It should be possible to integrate git-annex metadata with that ..
+"""]]

Added a comment: Glacier-cli works, thanks, some encode / decode error now...
diff --git a/doc/special_remotes/glacier/comment_12_a097d78d15e103c10f67e237c852b222._comment b/doc/special_remotes/glacier/comment_12_a097d78d15e103c10f67e237c852b222._comment
new file mode 100644
index 0000000..f033bab
--- /dev/null
+++ b/doc/special_remotes/glacier/comment_12_a097d78d15e103c10f67e237c852b222._comment
@@ -0,0 +1,59 @@
+[[!comment format=mdwn
+ username="git-annex,branchable.com@1fa4b21c7ece2d61d4730de8e83329049126cedc"
+ nickname="git-annex,branchable.com"
+ subject="Glacier-cli works, thanks, some encode / decode error now..."
+ date="2015-08-26T08:30:53Z"
+ content="""
+Hi Joey,
+
+Thanks for the hand, it started uploading once I had manually created the vault but then borked with:
+
+    fozz@cobol:~/Store/family_pictures $ git annex --verbose copy 201/2011/05/07/P1010004.RW2 --to familypictures-glacier
+    copy 201/2011/05/07/P1010004.RW2 (gpg) (checking familypictures-glacier...) (to familypictures-glacier...) 
+    81%           4.0MB/s 0sTraceback (most recent call last):
+      File \"/home/fozz/.vendor/bin/glacier\", line 730, in <module>
+        App().main()
+      File \"/home/fozz/.vendor/bin/glacier\", line 716, in main
+        self.args.func()
+      File \"/home/fozz/.vendor/bin/glacier\", line 498, in archive_upload
+        file_obj=self.args.file, description=name)
+      File \"/usr/local/lib/python2.7/dist-packages/boto/glacier/vault.py\", line 177, in create_archive_from_file
+        writer.write(data)
+      File \"/usr/local/lib/python2.7/dist-packages/boto/glacier/writer.py\", line 219, in write
+        self.partitioner.write(data)
+      File \"/usr/local/lib/python2.7/dist-packages/boto/glacier/writer.py\", line 61, in write
+        self._send_part()
+      File \"/usr/local/lib/python2.7/dist-packages/boto/glacier/writer.py\", line 75, in _send_part
+        self.send_fn(part)
+      File \"/usr/local/lib/python2.7/dist-packages/boto/glacier/writer.py\", line 222, in _upload_part
+        self.uploader.upload_part(self.next_part_index, part_data)
+      File \"/usr/local/lib/python2.7/dist-packages/boto/glacier/writer.py\", line 129, in upload_part
+        content_range, part_data)
+      File \"/usr/local/lib/python2.7/dist-packages/boto/glacier/layer1.py\", line 1279, in upload_part
+        response_headers=response_headers)
+      File \"/usr/local/lib/python2.7/dist-packages/boto/glacier/layer1.py\", line 114, in make_request
+        data=data)
+      File \"/usr/local/lib/python2.7/dist-packages/boto/connection.py\", line 1071, in make_request
+        retry_handler=retry_handler)
+      File \"/usr/local/lib/python2.7/dist-packages/boto/connection.py\", line 943, in _mexe
+        request.body, request.headers)
+      File \"/usr/lib/python2.7/httplib.py\", line 979, in request
+        self._send_request(method, url, body, headers)
+      File \"/usr/lib/python2.7/httplib.py\", line 1013, in _send_request
+        self.endheaders(body)
+      File \"/usr/lib/python2.7/httplib.py\", line 975, in endheaders
+        self._send_output(message_body)
+      File \"/usr/lib/python2.7/httplib.py\", line 833, in _send_output
+        msg += message_body
+    UnicodeDecodeError: 'ascii' codec can't decode byte 0x8c in position 0: ordinal not in range(128)
+    gpg: [stdout]: write error: Broken pipe
+    gpg: DBG: deflate: iobuf_write failed
+    gpg: build_packet failed: file write error
+    gpg: [stdout]: write error: Broken pipe
+    gpg: iobuf_flush failed on close: file write error
+    gpg: symmetric encryption of `[stdin]' failed: file write error
+    git-annex: fd:17: hPutBuf: resource vanished (Broken pipe)
+    failed                  
+    git-annex: copy: 1 failed
+
+"""]]

some weird corner case, i guess
diff --git a/doc/forum/removing_remote.log_information_completely.mdwn b/doc/forum/removing_remote.log_information_completely.mdwn
new file mode 100644
index 0000000..0a0e91c
--- /dev/null
+++ b/doc/forum/removing_remote.log_information_completely.mdwn
@@ -0,0 +1,9 @@
+in [[forum/remote-specific_meta-data/]], we have learned how to insert our own remote-specific metadata, in remote.log. now, we need a way to remove that data. for some reason, injecting commits in the `git-annex` branch doesn't quite work, because other assistants will overwrite that merge thanks to the [[git-union-merge]] driver.
+
+so far, i have found that it *can* be possible to work around this problem by repeatedly doing commits on the git-annex branch and running `git-annex sync` by hand after. it stumbles and flips around for a while, but eventually does it. it does create nice sparkles in gitk: 
+
+![a tangled mess in gitk](http://i.imgur.com/PD4ne50.png)]
+
+What is the proper way of removing entries from `remote.log`? How about propagating changes to the `synced/git-annex` branch? I can generate commits on `git-annex` using the git-annex index, and on the `git-annex` branch. But how should those changes be propagated to other branches?
+
+Thanks! --[[anarcat]]

Added a comment
diff --git a/doc/todo/autoenable__61__true_for_special_remotes/comment_1_c4926ed92263c78bafbee3862f12bab4._comment b/doc/todo/autoenable__61__true_for_special_remotes/comment_1_c4926ed92263c78bafbee3862f12bab4._comment
new file mode 100644
index 0000000..b04a8c2
--- /dev/null
+++ b/doc/todo/autoenable__61__true_for_special_remotes/comment_1_c4926ed92263c78bafbee3862f12bab4._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ subject="comment 1"
+ date="2015-08-25T18:25:44Z"
+ content="""
+There are going to be many configurations where auto-enable of a special remote fails. Ie, when creds are needed. While some of these could be detected and skipped, I sort of like the simplicity of having it try to enable everything.
+
+Maybe a command is also needed to autoenable remotes after the first git-annex init? Since it's actually ok to re-run git-annex init in an initalized repo, I suppose it could just be run again.
+"""]]

diff --git a/doc/todo/autoenable__61__true_for_special_remotes.mdwn b/doc/todo/autoenable__61__true_for_special_remotes.mdwn
new file mode 100644
index 0000000..8b0f019
--- /dev/null
+++ b/doc/todo/autoenable__61__true_for_special_remotes.mdwn
@@ -0,0 +1,3 @@
+Just passing along from https://github.com/datalad/datalad/issues/77#issuecomment-134688459
+
+joey:  I do think there could be a use case for configuring a special remote with autoenable=true and have git-annex init try to enable all such remotes.

link to manpages so there's context over there as well
diff --git a/doc/trust.mdwn b/doc/trust.mdwn
index a33c6dd..bfb36b5 100644
--- a/doc/trust.mdwn
+++ b/doc/trust.mdwn
@@ -20,7 +20,7 @@ There is still some trust involved here. A semitrusted repository is
 depended on to retain a copy of the file content; possibly the only
 [[copy|copies]].
 
-(Being semitrusted is the default. The `git annex semitrust` command
+(Being semitrusted is the default. The [[git-annex-semitrust]] command
 restores a repository to this default, when it has been overridden.
 The `--semitrust` option can temporarily restore a repository to this
 default.)
@@ -34,7 +34,7 @@ This is a good choice for eg, portable drives that could get lost. Or,
 if a disk is known to be dying, you can set it to untrusted and let
 `git annex fsck` warn about data that needs to be copied off it.
 
-To configure a repository as untrusted, use the `git annex untrust`
+To configure a repository as untrusted, use the [[git-annex-untrust]]
 command.
 
 ## trusted
@@ -49,7 +49,7 @@ access a remote you trust. Or to use `--trust` to specify a repository to
 trust temporarily.
 
 To configure a repository as fully and permanently trusted,
-use the `git annex trust` command.
+use the [[git-annex-trust]] command.
 
 ## dead
 
@@ -57,3 +57,6 @@ This is used to indicate that you have no trust that the repository
 exists at all. It's appropriate to use when a drive has been lost,
 or a directory irretrievably deleted. It will make git-annex avoid
 even showing the repository as a place where data might still reside.
+
+To configure a repository as dead and lost, use the [[git-annex-dead]]
+command.

ssh problem workaround in place
diff --git a/doc/news/version_5.20150824.mdwn b/doc/news/version_5.20150824.mdwn
index 24842cf..cc93106 100644
--- a/doc/news/version_5.20150824.mdwn
+++ b/doc/news/version_5.20150824.mdwn
@@ -26,4 +26,5 @@ git-annex 5.20150824 released with [[!toggle text="these changes"]]
      haskell program is unknown."""]]
 
 Note: The x86-64 bit linux standalone tarball shipped with this version had
-a broken version of ssh that crashed on startup.
+a broken version of ssh that crashed on startup. The tarball has been
+updated to fix this problem.

document ssh problem
diff --git a/doc/news/version_5.20150824.mdwn b/doc/news/version_5.20150824.mdwn
index aaa404a..24842cf 100644
--- a/doc/news/version_5.20150824.mdwn
+++ b/doc/news/version_5.20150824.mdwn
@@ -23,4 +23,7 @@ git-annex 5.20150824 released with [[!toggle text="these changes"]]
      ld, cc, and cpp.
    * As a result of the Makefile changes, the Debian package is built
      with various hardening options. Although their benefit to a largely
-     haskell program is unknown."""]]
\ No newline at end of file
+     haskell program is unknown."""]]
+
+Note: The x86-64 bit linux standalone tarball shipped with this version had
+a broken version of ssh that crashed on startup.

Added a comment: addendum
diff --git a/doc/forum/webapp:_disabling_a_paired_repository/comment_1_9dd316fedf55afecbc77f3b99e66d837._comment b/doc/forum/webapp:_disabling_a_paired_repository/comment_1_9dd316fedf55afecbc77f3b99e66d837._comment
new file mode 100644
index 0000000..077832d
--- /dev/null
+++ b/doc/forum/webapp:_disabling_a_paired_repository/comment_1_9dd316fedf55afecbc77f3b99e66d837._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="vincent.mcintyre@1318ebde5cb96fc17e59dfa86f399f5634b1facc"
+ nickname="vincent.mcintyre"
+ subject="addendum"
+ date="2015-08-25T10:45:56Z"
+ content="""
+Syncing seems to work only in one direction.
+
+If I  go to machine B and:
+ * change a file
+ * select 'sync now' from the 'actions' menu for machine A
+the webapp says it worked.
+
+But if I login to machine A and inspect the file I expect to have changed, it is 'not available'.
+
+If I run 'git annex get 'baz.txt' on machine A it complains and asks me to make available the reposiotry on machine B.
+
+"""]]

diff --git a/doc/forum/Multiple_machine_remotes_on_external_drive.mdwn b/doc/forum/Multiple_machine_remotes_on_external_drive.mdwn
new file mode 100644
index 0000000..70c910d
--- /dev/null
+++ b/doc/forum/Multiple_machine_remotes_on_external_drive.mdwn
@@ -0,0 +1,7 @@
+I have a question about remotes behavior on external drives.
+
+Say I have two machines A and B each with a git annex repository at `~/repo`, and an external drive C with the same repository at `/repo`.
+
+I can add C remotes for A and B at, for example, `/media/hdd/repo`, but I'm not certain how it works for C.
+
+Do I stick C into A and add a remote A at path `~/repo`, then stick C into B and add a remote B with the same path `~/repo`?  Does git annex handle this sanely?

diff --git a/doc/forum/webapp:_disabling_a_paired_repository.mdwn b/doc/forum/webapp:_disabling_a_paired_repository.mdwn
new file mode 100644
index 0000000..bc2c809
--- /dev/null
+++ b/doc/forum/webapp:_disabling_a_paired_repository.mdwn
@@ -0,0 +1,12 @@
+I had two repositories, on different machines, created with the assistant, so they were both direct mode.
+
+After pairing each with the other, so that files were merrily flowing back and forth, I happened to do the following:
+ * on machine A, in the dashboard
+ * click on the 'actions' emnu for the repository on machine B
+ * select 'disable'
+
+Result: all references to the repo on machine B have disappeared from the assistant in machine A.
+
+On machine B, I still have the pairing with machine A, and selecting the 'sync now' action seems to be working.
+
+The thing I am curious about is the behaviour on machine A - why is it that I cannot find any reference to it any more in the assistant, so that I can re-enable it?

Added a comment: Stream encoding
diff --git a/doc/design/external_special_remote_protocol/comment_16_62b137a138c143a8110886cc0bbb677e._comment b/doc/design/external_special_remote_protocol/comment_16_62b137a138c143a8110886cc0bbb677e._comment
new file mode 100644
index 0000000..4d196a2
--- /dev/null
+++ b/doc/design/external_special_remote_protocol/comment_16_62b137a138c143a8110886cc0bbb677e._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="sjvdwalt@3d195104d8f45061da99fe7f0a97d69dfc49bb5d"
+ nickname="sjvdwalt"
+ subject="Stream encoding"
+ date="2015-08-25T00:36:24Z"
+ content="""
+What encoding is used for the stdin/stdout streams used to communicate with remotes?
+"""]]

add news item for git-annex 5.20150824
diff --git a/doc/news/version_5.20150710.mdwn b/doc/news/version_5.20150710.mdwn
deleted file mode 100644
index 02035fa..0000000
--- a/doc/news/version_5.20150710.mdwn
+++ /dev/null
@@ -1,34 +0,0 @@
-git-annex 5.20150710 released with [[!toggle text="these changes"]]
-[[!toggleable text="""
-   * add: Stage symlinks the same as git add would, even if they are not a
-     link to annexed content.
-   * sync: When annex.autocommit=false, avoid making any commit of local
-     changes, while still merging with remote to the extent possible.
-   * unused: --used-refspec can now be configured to look at refs in the
-     reflog. This provides a way to not consider old versions of files to be
-     unused after they have reached a specified age, when the old refs in
-     the reflog expire.
-   * log: Fix reversion introduced in version 5.20150528 that broke this command.
-   * assistant --autostart: First stop any daemons that are already running,
-     which might be left over from a previous login session and so unable to
-     use the ssh agent of a new login session.
-   * assistant: Fix local pairing to not include newline in ssh pubkey,
-     which is rejected on the other end for security reasons.
-   * assistant: Fix ANNEX\_SHELL\_DIR written to ~/.ssh/authorized\_keys
-     in local pairing to be the absolute path to the repository, not "."
-     This was a reversion caused by the relative path changes in 5.20150113.
-   * Brought back the setkey plumbing command that was removed in 2011, since
-     we found a use case for it. Note that the command's syntax was changed
-     for consistency.
-   * bugfix: Pass --full-tree when using git ls-files to get a list of files
-     on the git-annex branch, so it works when run in a subdirectory.
-     This bug affected git-annex unused, and potentially also transitions
-     running code and other things.
-   * Support git's undocumented core.sharedRepository=2 value, which
-     is equivalent to "world", and is set when a repo was created using
-     git init --shared=world.
-   * When building on linux, pass --as-needed to linker to avoid linking
-     with unused shared libraries including libyaml.
-   * import: Fix failure of cross-device import on Windows.
-   * merge: Avoid creating the synced/master branch.
-   * Removed support for optparse-applicative versions older than 0.10."""]]
\ No newline at end of file
diff --git a/doc/news/version_5.20150824.mdwn b/doc/news/version_5.20150824.mdwn
new file mode 100644
index 0000000..aaa404a
--- /dev/null
+++ b/doc/news/version_5.20150824.mdwn
@@ -0,0 +1,26 @@
+git-annex 5.20150824 released with [[!toggle text="these changes"]]
+[[!toggleable text="""
+   * Sped up downloads of files from ssh remotes, reducing the
+     non-data-transfer overhead 6x.
+   * sync: Support --jobs
+   * sync --content: Avoid unnecessary second pull from remotes when
+     no file transfers are made.
+   * External special remotes can now be built that can be used in readonly
+     mode, where git-annex downloads content from the remote using regular
+     http.
+   * Added WHEREIS to external special remote protocol.
+   * importfeed --relaxed: Avoid hitting the urls of items in the feed.
+   * Fix reversion in init when ran as root, introduced in version 5.20150731.
+   * Reorder declaration to fix build with yesod-core &gt; 1.4.13.
+     Thanks, Michael Alan Dorman.
+   * Fix building without quvi and without database.
+     Thanks, Ben Boeckel.
+   * Avoid building the assistant on the hurd, since an inotify equivalent
+     is not yet implemented in git-annex for the hurd.
+   * --debug log messages are now timestamped with fractional seconds.
+   * --debug is passed along to git-annex-shell when git-annex is in debug mode.
+   * Makefile: Pass LDFLAGS, CFLAGS, and CPPFLAGS through ghc and on to
+     ld, cc, and cpp.
+   * As a result of the Makefile changes, the Debian package is built
+     with various hardening options. Although their benefit to a largely
+     haskell program is unknown."""]]
\ No newline at end of file

diff --git a/doc/forum/HowTo_Conflict_Resolution.mdwn b/doc/forum/HowTo_Conflict_Resolution.mdwn
index c180cc1..2e43efe 100644
--- a/doc/forum/HowTo_Conflict_Resolution.mdwn
+++ b/doc/forum/HowTo_Conflict_Resolution.mdwn
@@ -40,6 +40,7 @@ To /home/florian/Desktop/AA
    83ff4c6..7df9834  git-annex -> synced/git-annex
    b86e708..59a1240  annex/direct/master -> synced/master
 ok
+```
 
 ```
 florian@horus ~/Desktop/BB (git)-[annex/direct/master] % git annex get .
@@ -58,6 +59,8 @@ How can I resolve this conflict now? Is there a way to tell which bin1 / bin2 is
 
 This case might appear somehow artifical but I was caught in that various times when syncing my music database. Actually I didn't care which version of the database it took, but I was unable to produce a coherent data set, so that the database files only come from one sync partner.
 
+I did the git annex get after syncing, becaue usually I sync using --content.
+
 Thanks,
 Florian
 

diff --git a/doc/forum/HowTo_Conflict_Resolution.mdwn b/doc/forum/HowTo_Conflict_Resolution.mdwn
new file mode 100644
index 0000000..c180cc1
--- /dev/null
+++ b/doc/forum/HowTo_Conflict_Resolution.mdwn
@@ -0,0 +1,63 @@
+Hello,
+
+I have two git annex repos, AA and BB in direct mode. Both have edited a binary file before syncing
+
+```
+~/Desktop/BB (git)-[annex/direct/master] % git annex sync
+commit  ok
+pull origin 
+remote: Counting objects: 21, done.
+remote: Compressing objects: 100% (17/17), done.
+remote: Total 21 (delta 3), reused 0 (delta 0)
+Unpacking objects: 100% (21/21), done.
+From /home/florian/Desktop/AA
+   d55cfa2..b86e708  annex/direct/master -> origin/annex/direct/master
+   83ff4c6..5cfbd34  git-annex  -> origin/git-annex
+   d7b79e8..b86e708  master     -> origin/master
+   d7b79e8..b86e708  synced/master -> origin/synced/master
+
+Auto-merging bin2
+CONFLICT (content): Merge conflict in bin2
+Auto-merging bin1
+CONFLICT (content): Merge conflict in bin1
+Automatic merge failed; fix conflicts and then commit the result.
+bin2: needs merge
+bin1: needs merge
+(recording state in git...)
+
+  Merge conflict was automatically resolved; you may want to examine the result.
+
+ok
+(merging origin/git-annex into git-annex...)
+(recording state in git...)
+push origin 
+Counting objects: 31, done.
+Delta compression using up to 4 threads.
+Compressing objects: 100% (25/25), done.
+Writing objects: 100% (31/31), 3.04 KiB | 0 bytes/s, done.
+Total 31 (delta 6), reused 0 (delta 0)
+To /home/florian/Desktop/AA
+   83ff4c6..7df9834  git-annex -> synced/git-annex
+   b86e708..59a1240  annex/direct/master -> synced/master
+ok
+
+```
+florian@horus ~/Desktop/BB (git)-[annex/direct/master] % git annex get .
+get bin1.variant-c4b6 (from origin...) ok
+get bin2.variant-f16a (from origin...) ok
+(recording state in git...)
+florian@horus ~/Desktop/BB (git)-[annex/direct/master] % ll
+insgesamt 5824
+-rw-r----- 1 florian florian 2863795 24. Aug 21:32 bin1.variant-1696
+-rw-r----- 1 florian florian 2841749 24. Aug 21:30 bin1.variant-c4b6
+-rw-r----- 1 florian florian  125612 24. Aug 21:32 bin2.variant-0efa
+-rw-r----- 1 florian florian  126067 24. Aug 21:31 bin2.variant-f16a
+
+```
+How can I resolve this conflict now? Is there a way to tell which bin1 / bin2 is from AA, which from BB? Is there a way to tell git annex to completely take the data from AA or BB?
+
+This case might appear somehow artifical but I was caught in that various times when syncing my music database. Actually I didn't care which version of the database it took, but I was unable to produce a coherent data set, so that the database files only come from one sync partner.
+
+Thanks,
+Florian
+

diff --git a/doc/todo/webapp:_show_times_of_events.mdwn b/doc/todo/webapp:_show_times_of_events.mdwn
new file mode 100644
index 0000000..b58e52e
--- /dev/null
+++ b/doc/todo/webapp:_show_times_of_events.mdwn
@@ -0,0 +1,5 @@
+In the webapp 'dashboard' page there is a column of 'message boxes' on the right hand side that appear as events occur.
+
+I would find it helpful to be able to hover over a message box and have a timestamp appear so that I know whether the event is a recent one that I might need to go look in the log for more detail about, or that I can click on the 'X' to dismiss the message.
+
+A further improvement that occurred to me is adding a link within the message box (link text something like "view log entry") that takes you to the corresponding part of the 'view log' page.

Add bug report about hPutChar error message when using git annex fsck --incremental
diff --git a/doc/bugs/hPutChar_error_message_with_UTF-8_chars_above_7F_in_filenames.mdwn b/doc/bugs/hPutChar_error_message_with_UTF-8_chars_above_7F_in_filenames.mdwn
new file mode 100644
index 0000000..f4beac9
--- /dev/null
+++ b/doc/bugs/hPutChar_error_message_with_UTF-8_chars_above_7F_in_filenames.mdwn
@@ -0,0 +1,78 @@
+### Please describe the problem.
+
+When using `--incremental` together with `git annex fsck`, the error 
+message "hPutChar: invalid argument (invalid character)" appears in the 
+"Only X of Y trustworthy copies exist" message when the filename 
+contains an UTF-8 character above U+007F. The only locale in which this 
+doesn't happen is "C.UTF-8".
+
+### What steps will reproduce the problem?
+
+- Create and add a file with an UTF-8 character in the file name above U+007F to git-annex
+- Set `numcopies` high enough so `git annex fsck` will produce a warning about missing copies
+- Execute `git annex fsck --incremental`
+
+I've created two test scripts on 
+<https://gist.github.com/sunny256/ebf4d055f5500b257ed8> that demonstrate 
+this error:
+
+- `git clone https://gist.github.com/ebf4d055f5500b257ed8.git`
+- `cd ebf4d055f5500b257ed8`
+- `./runme`
+
+You can specify a locale to `runme` as `$1` to experiment with different 
+locales.
+
+There's also a `test-all-locales` script that executes `./runme` with 
+all defined locales on the computer. Both scripts return 1 if the error 
+message appears, if it's gone, 0 is returned.
+
+### What version of git-annex are you using? On what operating system?
+
+Newest git-annex amd64 (5.20150812) from `downloads.kitenet.net`.
+
+### Please provide any additional information below.
+
+The `runme` script contains more information about this issue.
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+
+Here are two excerpts of the test output using the "C" and 
+"C.UTF-8" locale:
+
+$ ./runme C
+[snip]
+================== git annex --incremental fsck ==================
+fsck U00D8_Ø.txt (checksum...)
+
+  Only 1 of 2 trustworthy copies exist of U00D8_
+git-annex: <stderr>: hPutChar: invalid argument (invalid character)
+failed
+fsck ascii_only.txt (checksum...)
+
+  Only 1 of 2 trustworthy copies exist of ascii_only.txt
+  Back it up with git-annex copy.
+failed
+(recording state in git...)
+git-annex: fsck: 2 failed
+
+$ ./runme C.UTF-8
+[snip]
+================== git annex --incremental fsck ==================
+fsck U00D8_Ø.txt (checksum...)
+
+  Only 1 of 2 trustworthy copies exist of U00D8_Ø.txt
+  Back it up with git-annex copy.
+failed
+fsck ascii_only.txt (checksum...)
+
+  Only 1 of 2 trustworthy copies exist of ascii_only.txt
+  Back it up with git-annex copy.
+failed
+(recording state in git...)
+git-annex: fsck: 2 failed
+
+# End of transcript or log.
+"""]]

Added a comment
diff --git a/doc/tips/fully_encrypted_git_repositories_with_gcrypt/comment_15_de4838d82987685896d4c76dac7cdb6c._comment b/doc/tips/fully_encrypted_git_repositories_with_gcrypt/comment_15_de4838d82987685896d4c76dac7cdb6c._comment
new file mode 100644
index 0000000..3eb3812
--- /dev/null
+++ b/doc/tips/fully_encrypted_git_repositories_with_gcrypt/comment_15_de4838d82987685896d4c76dac7cdb6c._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="tanen"
+ subject="comment 15"
+ date="2015-08-23T20:34:20Z"
+ content="""
+I just created the same setup again that I attempted 1-2 years ago, with the latest self-contained git-annex build. Two clients, one SSH server, using gcrypt. Setup worked flawless now (although the process of having to manually export the generated GPG key and import it into all clients is still very awkward); changes made on a client are immediately detected and synced with the server. However, the changes made on client A are never automatically propagated to client B. They are picked up when I restart the annex assistant on client B, but never automatically.
+
+Is this a bug or simply not supported? I read about XMPP being deprecated in favor of notifications via the annex-shell, but I couldn't find a post detailing these changes.
+"""]]

Reorder declaration to fix build with yesod-core > 1.4.13. Thanks, Michael Alan Dorman.
diff --git a/debian/changelog b/debian/changelog
index 307efde..23e17c5 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -20,6 +20,8 @@ git-annex (5.20150813) UNRELEASED; urgency=medium
   * As a result of the Makefile changes, the Debian package is built
     with various hardening options. Although their benefit to a largely
     haskell program is unknown.
+  * Reorder declaration to fix build with yesod-core > 1.4.13.
+    Thanks, Michael Alan Dorman.
 
  -- Joey Hess <id@joeyh.name>  Wed, 12 Aug 2015 14:31:01 -0400
 
diff --git a/doc/bugs/Build_failures_with_7.10.mdwn b/doc/bugs/Build_failures_with_7.10.mdwn
index 102326a..e733ad1 100644
--- a/doc/bugs/Build_failures_with_7.10.mdwn
+++ b/doc/bugs/Build_failures_with_7.10.mdwn
@@ -23,3 +23,5 @@ Assistant/WebApp/Types.hs:39:1: ‘WebApp’ is not in scope at a reify
 If I'm reading things correctly (you can do some diffing of the inputs from [the page for the build](http://hydra.cryp.to/build/1099681)), I'm going to guess that it was the upgrade to yesod-1.4.14.
 
 I'll continue to look into it, but it would seem to touch on TH and Yesod stuff with which I am largely unfamiliar.
+
+> Fixed with mdorman's patch, [[done]] (will push a release in a day or 2) --[[Joey]]

Added a comment: Fix for this issue
diff --git a/doc/bugs/Build_failures_with_7.10/comment_2_d3b68bbf83d9e83f93fc10a588e127f5._comment b/doc/bugs/Build_failures_with_7.10/comment_2_d3b68bbf83d9e83f93fc10a588e127f5._comment
new file mode 100644
index 0000000..dde4b4f
--- /dev/null
+++ b/doc/bugs/Build_failures_with_7.10/comment_2_d3b68bbf83d9e83f93fc10a588e127f5._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="mdorman@ddbe259e8f6e03351350a04515c67f7957abf736"
+ nickname="mdorman"
+ subject="Fix for this issue"
+ date="2015-08-23T17:26:34Z"
+ content="""
+[My yesod-core-fix branch](https://github.com/mdorman/git-annex/tree/yesod-core-fix) has as its HEAD the (super-simplistic) fix for this issue.
+"""]]

Added a comment: In fact, the problem *is* the yesod update
diff --git a/doc/bugs/Build_failures_with_7.10/comment_1_3ef2d6bcc66d57140777e6262467a40a._comment b/doc/bugs/Build_failures_with_7.10/comment_1_3ef2d6bcc66d57140777e6262467a40a._comment
new file mode 100644
index 0000000..38652d8
--- /dev/null
+++ b/doc/bugs/Build_failures_with_7.10/comment_1_3ef2d6bcc66d57140777e6262467a40a._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="mdorman@ddbe259e8f6e03351350a04515c67f7957abf736"
+ nickname="mdorman"
+ subject="In fact, the problem *is* the yesod update"
+ date="2015-08-22T10:37:20Z"
+ content="""
+Per https://github.com/yesodweb/yesod/issues/1059, it would appear that all you would need to do is reorder some declarations---though that was my first thought and I thought I tried it and it failed, perhaps I got something else wrong in doing so.  I'll report back when I have more info.
+"""]]

Something amiss in TH instantiation?
diff --git a/doc/bugs/Build_failures_with_7.10.mdwn b/doc/bugs/Build_failures_with_7.10.mdwn
new file mode 100644
index 0000000..102326a
--- /dev/null
+++ b/doc/bugs/Build_failures_with_7.10.mdwn
@@ -0,0 +1,25 @@
+### Please describe the problem.
+
+git-annex fails to build in the NixOS builder
+
+### What steps will reproduce the problem?
+
+cabal build
+
+### What version of git-annex are you using? On what operating system?
+
+5.20150812
+
+### Please provide any additional information below.
+
+[The build log](http://hydra.cryp.to/build/1099681/nixlog/1/raw) has a full transcript of the build from one of the build machines, though I have reproduced this locally.
+
+The pertinent bit of the log (which is *not* at the end, though I think that's just a capture-both-stderr-and-stdin thing, since it was at the end when I repro'd it:
+
+[[!format sh """
+Assistant/WebApp/Types.hs:39:1: ‘WebApp’ is not in scope at a reify
+"""]]
+
+If I'm reading things correctly (you can do some diffing of the inputs from [the page for the build](http://hydra.cryp.to/build/1099681)), I'm going to guess that it was the upgrade to yesod-1.4.14.
+
+I'll continue to look into it, but it would seem to touch on TH and Yesod stuff with which I am largely unfamiliar.

response
diff --git a/doc/bugs/git_annex_cannot_get_my_files_after_clone/comment_3_ef9b32d9ba1b80c313db48be36cc90d1._comment b/doc/bugs/git_annex_cannot_get_my_files_after_clone/comment_3_ef9b32d9ba1b80c313db48be36cc90d1._comment
new file mode 100644
index 0000000..4dc1985
--- /dev/null
+++ b/doc/bugs/git_annex_cannot_get_my_files_after_clone/comment_3_ef9b32d9ba1b80c313db48be36cc90d1._comment
@@ -0,0 +1,26 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2015-08-20T14:58:32Z"
+ content="""
+The error message about the transfer lock file is probably relevant, and
+seems to be coming from git-annex-shell on the clusterhost server.
+
+Since this code has recently been changed and partly rewritten,
+you ought to try upgrading git-annex on clusterhost to a more recent
+version.
+
+If that doesn't help, check if the specified lock file exists,
+and if its parent directory exists. It's possible that the directory it's
+trying to put the lock file in doesn't exist and this is causing the
+problem. If so, manually creating the directory would solve it.
+
+The other possibility seems to be that it's trying to open a lock file for
+read that doesn't exist. But I don't see how that can happen, at least
+not with the current code which catches any such exception.
+
+Stracing git-annex-shell would help narrow this down. 
+The git-annex-shell command that's failing is something like this:
+
+git-annex-shell sendkey ../chymera/data SHA256E-s814245--9dc6f1287ba683cae030e04ba7f94a73e566ce392c2d032f171094ddc342fa60.jpg
+"""]]

Added a comment: a bit more info and solutions
diff --git a/doc/forum/mesh_configurations/comment_9_ac3e1faaefaed222f725345ab4b5f01a._comment b/doc/forum/mesh_configurations/comment_9_ac3e1faaefaed222f725345ab4b5f01a._comment
new file mode 100644
index 0000000..33b6ab0
--- /dev/null
+++ b/doc/forum/mesh_configurations/comment_9_ac3e1faaefaed222f725345ab4b5f01a._comment
@@ -0,0 +1,89 @@
+[[!comment format=mdwn
+ username="anarcat"
+ subject="a bit more info and solutions"
+ date="2015-08-20T14:09:54Z"
+ content="""
+so short version here: thanks for your help and i figured it, there were problems with the S3 credentials perms not respecting `sharedRepository`, multiple group support confusion, bare/non-bare, groupwanted vs standard confusion and so on... now the files are migrating properly in production. hurray! i believe documentation could be improved, and i have questions about timeouts, below.
+
+so one thing that was definitely broken in production was that, on the central server, the S3 credentials were accessible only to the user that ran the \"enable s3\" command (that is `anarcat`). it was *not* accessible to the user actually running the assistant (the `git-annex` sandbox account), which made it simply impossible for the assistant to upload files to s3. so maybe one problem here is that the `.git/annex/creds` file do not respect the `core.sharedRepository = group` setting i have there...
+
+another problem in production, of course, was the *transfer* preferred group setting. once changed to `not inallgroup=backup`, things were better... but it was still keeping too many files. the problem then was that the repo was originally set to the *source* group (PEBKAC here again, sorry) and then it was *added* to the *standard* group, with the `git annex group . standard` command. i didn't expect that: i expected the group command to *change* the group, not to add to it. the documentation ([[git-annex-group]]) is clear enough, however, so this is yet another PEBKAC.
+
+Another possible problem is that the central server (`b`) is not a bare git repository. I am not sure why it was setup that way... maybe i was worried about bare repo suport and past experiences, or concerns about being able to actually interact with the files directly on the central server. i had to do `git co -b master synced/master` to eventually see the files locally, and this helped a little in diagnosing all of this.
+
+A problem remained after that though: files are *still* not removed from `A` in my tests in production. i don't understand why: `A` is setup as a source repository:
+
+<pre>
+antoine@ip-10-88-150-10:/mnt/media$ git annex group .
+sourcethis 
+antoine@ip-10-88-150-10:/mnt/media$ git annex wanted .
+groupwanted
+</pre>
+
+yet some files have more than one copy:
+
+<pre>
+antoine@ip-10-88-150-10:/mnt/media$ git annex list test
+here
+|origin
+||s3
+|||web (untrusted)
+||||bittorrent
+|||||
+X_X__ test/motd
+__X__ test/test1
+__X__ test/test2
+__X__ test/test3
+</pre>
+
+Indeed, it doesn't sem to want to drop that local file:
+
+<pre>
+antoine@ip-10-88-150-10:/mnt/media$ git annex list --want-drop test
+here
+|origin
+||s3
+|||web (untrusted)
+||||bittorrent
+|||||
+__X__ test/test1
+__X__ test/test2
+__X__ test/test3
+</pre>
+
+It turns out that I had documentation wrong again about that as well: i was using *groupwanted* as a `wanted` expression, but the groups were standard groups, so git-annex was just failing to use the proper content expression. setting the `wanted` expression back to standard (yes, again as you showed, sorry about that) fixed the problem:
+
+<pre>
+antoine@ip-10-88-150-10:/mnt/media$ sudo -u www-data -H git annex wanted . standard
+wanted . ok
+(recording state in git...)
+antoine@ip-10-88-150-10:/mnt/media$ git annex list --want-drop test
+here
+|origin
+||s3
+|||web (untrusted)
+||||bittorrent
+|||||
+X_X__ test/motd
+__X__ test/test1
+__X__ test/test2
+__X__ test/test3
+antoine@ip-10-88-150-10:/mnt/media$ sudo -u www-data -H git annex drop --auto test
+drop test/motd ok
+(recording state in git...)
+</pre>
+
+hurray!
+
+again, i apologise for all the hand holding here... as a software developper myself, i understand how frustrating it can be to try to make users come out of their cave of ignorance and see the light of day...
+
+but i do feel there could be more work done to clarify how all of this works. i will certainly try to give a few kicks in the [[preferred content]] section and maybe this forum post will be helpful for future endeavors... or maybe just write up a new tips page about such hairy setups?
+
+the questions that remain here for me are:
+
+* how long does the assistant wait before refreshing the wanted content expressions
+* how long it waits before triggering syncs
+* are those timeouts configurable
+
+thanks so much for helping us through this, it's really appreciated!
+"""]]

Added a comment
diff --git a/doc/bugs/git_annex_cannot_get_my_files_after_clone/comment_2_545c9daafc63c5cdb80763b929c8d622._comment b/doc/bugs/git_annex_cannot_get_my_files_after_clone/comment_2_545c9daafc63c5cdb80763b929c8d622._comment
new file mode 100644
index 0000000..efbb232
--- /dev/null
+++ b/doc/bugs/git_annex_cannot_get_my_files_after_clone/comment_2_545c9daafc63c5cdb80763b929c8d622._comment
@@ -0,0 +1,32 @@
+[[!comment format=mdwn
+ username="https://me.yahoo.com/a/yx5Y6EI1t.759Jsu63ZWqYclCmpOmxxd.ramtw--#7114a"
+ nickname="Ioanas"
+ subject="comment 2"
+ date="2015-08-20T09:37:21Z"
+ content="""
+Doesn't seem to be the case. I get nothing in my out.dat file, but still the same rsync complaint from git annex. 
+
+```
+guest@labhost ~ $ ssh clusterhost /bin/true > out.dat
+guest@labhost ~ $ cat out.dat
+guest@labhost ~ $ ls -l out.dat 
+-rw-r--r-- 1 guest guest 0 20. Aug 11:31 out.dat
+guest@labhost ~ $ cd /mnt/data/data/                
+guest@labhost /mnt/data/data $ git annex get gt.ep/pcr/
+get gt.ep/pcr/pcr_0000.csv (from clusterhost...) 
+protocol version mismatch -- is your shell clean?
+(see the rsync man page for an explanation)
+rsync error: protocol incompatibility (code 2) at compat.c(176) [Receiver=3.1.1]
+git-annex: ../chymera/data/.git/annex/transfer/upload/b8415264-4b9a-40ca-b450-7e57507cdc06/lck.SHA256E-s960--4689d3b876dfeabb3d9578204c8df7c4af0fd6c0f09691cffb3dfd86130e6a27.csv: openFd: does not exist (No such file or directory)
+git-annex-shell: sendkey: 1 failed
+
+  rsync failed -- run git annex again to resume file transfer
+
+  Unable to access these remotes: clusterhost
+
+  Try making some of these repositories available:
+  	809074b6-e079-4ea1-b2f8-2d7840deda7d -- zenbookhost
+   	a1ed6786-8b93-4a14-b00d-877b741e34da -- [clusterhost]
+failed
+```
+"""]]

give up on fixing the link and remove slash from original URL
diff --git a/doc/bugs/sync-git-annex_branch_not_syncing_in_the_assistant.mdwn b/doc/bugs/sync-git-annex_branch_not_syncing_in_the_assistant.mdwn
new file mode 100644
index 0000000..d7c679e
--- /dev/null
+++ b/doc/bugs/sync-git-annex_branch_not_syncing_in_the_assistant.mdwn
@@ -0,0 +1,49 @@
+### Please describe the problem.
+
+It seems that the `synced/git-annex` branch (which I am a little confused about in the first place), doesn't get synced automatically by the assistant.
+
+I was expecting the assistant to regularly do the equivalent of `git annex sync`. However, after a client pushed changes to the `git-annex` branch, I had to manually do a `git annex sync` for the changes of the `synced/git-annex` branch to be merged down into the local `git-annex`.
+
+### What steps will reproduce the problem?
+
+I have 3 machines in this setup (to simplify: there are more, but those are sufficient). Let's call them foo, bar and quux. foo and quuex are connected to bar through password-less SSH connexions.
+
+foo commits a file to git-annex. the assistant syncs that to bar in the `synced/git-annex` branch.
+
+quux syncs with bar, and seems to ignore the `synced/git-annex` branch.
+
+git-annex sync on quux syncs the `synced/git-annex` branch into the local `git-annex`, working around the issue.
+
+### What version of git-annex are you using? On what operating system?
+
+foo is 5.20150610+gitg608172f-1~ndall+1 on Debian 7.8 (wheezy).
+
+bar and quux are 5.20150409+git126-ga29f683-1~ndall+1 and 5.20150610+gitg608172f-1~ndall+1 (respectively) on Ubuntu 12.04 (precise) .
+
+### Please provide any additional information below.
+
+I guess a more general question is how and how often do those branches get merged by the assistant... it's still unclear to me how this works.
+
+[[!format sh """
+$ sudo -u www-data -H git annex sync
+(merging origin/synced/git-annex into git-annex...)
+(recording state in git...)
+commit  ok
+pull origin
+Auto packing the repository in background for optimum performance.
+See "git help gc" for manual housekeeping.
+
+Already up-to-date.
+ok
+push origin
+Counting objects: 373637, done.
+# End of transcript or log.
+"""]]
+
+This was started at 20:23 UTC. Note that the sync had run previously under the assistant:
+
+<pre>
+[2015-07-22 20:09:06 UTC] RemoteControl: Syncing with origin
+</pre>
+
+Available, as usual, for further debugging. :) -- [[anarcat]]
diff --git a/doc/bugs/sync__47__git-annex_branch_not_syncing_in_the_assistant.mdwn b/doc/bugs/sync__47__git-annex_branch_not_syncing_in_the_assistant.mdwn
deleted file mode 100644
index d7c679e..0000000
--- a/doc/bugs/sync__47__git-annex_branch_not_syncing_in_the_assistant.mdwn
+++ /dev/null
@@ -1,49 +0,0 @@
-### Please describe the problem.
-
-It seems that the `synced/git-annex` branch (which I am a little confused about in the first place), doesn't get synced automatically by the assistant.
-
-I was expecting the assistant to regularly do the equivalent of `git annex sync`. However, after a client pushed changes to the `git-annex` branch, I had to manually do a `git annex sync` for the changes of the `synced/git-annex` branch to be merged down into the local `git-annex`.
-
-### What steps will reproduce the problem?
-
-I have 3 machines in this setup (to simplify: there are more, but those are sufficient). Let's call them foo, bar and quux. foo and quuex are connected to bar through password-less SSH connexions.
-
-foo commits a file to git-annex. the assistant syncs that to bar in the `synced/git-annex` branch.
-
-quux syncs with bar, and seems to ignore the `synced/git-annex` branch.
-
-git-annex sync on quux syncs the `synced/git-annex` branch into the local `git-annex`, working around the issue.
-
-### What version of git-annex are you using? On what operating system?
-
-foo is 5.20150610+gitg608172f-1~ndall+1 on Debian 7.8 (wheezy).
-
-bar and quux are 5.20150409+git126-ga29f683-1~ndall+1 and 5.20150610+gitg608172f-1~ndall+1 (respectively) on Ubuntu 12.04 (precise) .
-
-### Please provide any additional information below.
-
-I guess a more general question is how and how often do those branches get merged by the assistant... it's still unclear to me how this works.
-
-[[!format sh """
-$ sudo -u www-data -H git annex sync
-(merging origin/synced/git-annex into git-annex...)
-(recording state in git...)
-commit  ok
-pull origin
-Auto packing the repository in background for optimum performance.
-See "git help gc" for manual housekeeping.
-
-Already up-to-date.
-ok
-push origin
-Counting objects: 373637, done.
-# End of transcript or log.
-"""]]
-
-This was started at 20:23 UTC. Note that the sync had run previously under the assistant:
-
-<pre>
-[2015-07-22 20:09:06 UTC] RemoteControl: Syncing with origin
-</pre>
-
-Available, as usual, for further debugging. :) -- [[anarcat]]
diff --git a/doc/forum/mesh_configurations/comment_8_a2b5da1ea55a222dd30f0e982d5ee807._comment b/doc/forum/mesh_configurations/comment_8_a2b5da1ea55a222dd30f0e982d5ee807._comment
index 11e14d6..b77b1b0 100644
--- a/doc/forum/mesh_configurations/comment_8_a2b5da1ea55a222dd30f0e982d5ee807._comment
+++ b/doc/forum/mesh_configurations/comment_8_a2b5da1ea55a222dd30f0e982d5ee807._comment
@@ -189,7 +189,7 @@ ____X otherfile
 ____X somefile
 </pre>
 
-how long does it take for the assistant to start syncs like this? are those timers user-accessible somehow? this problem sure looks like [[bugs/sync/git-annex_branch_not_syncing_in_the_assistant]] - but maybe i'm confused there as well.
+how long does it take for the assistant to start syncs like this? are those timers user-accessible somehow? this problem sure looks like [[bugs/sync-git-annex_branch_not_syncing_in_the_assistant]] - but maybe i'm confused there as well.
 
 anyways, it does seem like content actually does gets synced around properly by the assistant. i'll try to deploy the new preferred content expression in production and report back here.
 

try to fix link
diff --git a/doc/forum/mesh_configurations/comment_8_a2b5da1ea55a222dd30f0e982d5ee807._comment b/doc/forum/mesh_configurations/comment_8_a2b5da1ea55a222dd30f0e982d5ee807._comment
index 20eb4eb..11e14d6 100644
--- a/doc/forum/mesh_configurations/comment_8_a2b5da1ea55a222dd30f0e982d5ee807._comment
+++ b/doc/forum/mesh_configurations/comment_8_a2b5da1ea55a222dd30f0e982d5ee807._comment
@@ -189,7 +189,7 @@ ____X otherfile
 ____X somefile
 </pre>
 
-how long does it take for the assistant to start syncs like this? are those timers user-accessible somehow? this problem sure looks like [[bugs/sync__47__git-annex_branch_not_syncing_in_the_assistant]] - but maybe i'm confused there as well.
+how long does it take for the assistant to start syncs like this? are those timers user-accessible somehow? this problem sure looks like [[bugs/sync/git-annex_branch_not_syncing_in_the_assistant]] - but maybe i'm confused there as well.
 
 anyways, it does seem like content actually does gets synced around properly by the assistant. i'll try to deploy the new preferred content expression in production and report back here.
 

Added a comment: seems just ignore errors while adding urls to "unsupported" urls
diff --git a/doc/bugs/git-annex_drop_fails_to_access_file:__47____47____47___target_URL_on_Windows/comment_1_f0d30a953f072f8d9a929a4a6ba69914._comment b/doc/bugs/git-annex_drop_fails_to_access_file:__47____47____47___target_URL_on_Windows/comment_1_f0d30a953f072f8d9a929a4a6ba69914._comment
new file mode 100644
index 0000000..c7de2eb
--- /dev/null
+++ b/doc/bugs/git-annex_drop_fails_to_access_file:__47____47____47___target_URL_on_Windows/comment_1_f0d30a953f072f8d9a929a4a6ba69914._comment
@@ -0,0 +1,48 @@
+[[!comment format=mdwn
+ username="https://me.yahoo.com/a/EbvxpTI_xP9Aod7Mg4cwGhgjrCrdM5s-#7c0f4"
+ subject="seems just ignore errors while adding urls to &quot;unsupported&quot; urls"
+ date="2015-08-19T21:59:09Z"
+ content="""
+actually situation is somewhat similar on linux as well in a sense that annex manages to addurl a file using e.g. file:///./data   url (not sure even if legit) without puking but contains wrong content (empty):
+
+[[!format  sh \"\"\"
+
+% mkdir XXX
+% cd XXX
+% git init; git annex init
+Initialized empty Git repository in /tmp/XXX/.git/
+init  ok
+(recording state in git...)
+% echo 123 > data
+% git annex addurl --file=annexed file:///./data
+addurl annexed (downloading file:///./data ...) 
+
+ok
+(recording state in git...)
+% cat annexed 
+% git annex drop annexed
+drop annexed (checking file:///./data...) (unsafe) 
+  Could only verify the existence of 0 out of 1 necessary copies
+
+  Rather than dropping this file, try using: git annex move
+
+  (Use --force to override this check, or adjust numcopies.)
+failed
+git-annex: drop: 1 failed
+% git annex addurl --file=annexedfull file://$PWD/data
+addurl annexedfull (downloading file:///tmp/XXX/data ...) 
+######################################################################## 100.0%
+ok
+(recording state in git...)
+% cat annexedfull
+123
+% git annex drop annexedfull                          
+drop annexedfull (checking file:///tmp/XXX/data...) ok
+(recording state in git...)
+% annex version
+zsh: command not found: annex
+% git annex version
+git-annex version: 5.20150812-2
+
+\"\"\"]]
+"""]]

Added a comment
diff --git a/doc/bugs/symlinks_to_absent_files_remain_upon_switching_to_direct_mode2/comment_4_d40ed7385eb46aa0a9940198e4591c0e._comment b/doc/bugs/symlinks_to_absent_files_remain_upon_switching_to_direct_mode2/comment_4_d40ed7385eb46aa0a9940198e4591c0e._comment
new file mode 100644
index 0000000..d39513e
--- /dev/null
+++ b/doc/bugs/symlinks_to_absent_files_remain_upon_switching_to_direct_mode2/comment_4_d40ed7385eb46aa0a9940198e4591c0e._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://me.yahoo.com/a/EbvxpTI_xP9Aod7Mg4cwGhgjrCrdM5s-#7c0f4"
+ subject="comment 4"
+ date="2015-08-19T20:50:08Z"
+ content="""
+gotcha -- thanks. Sticking to git behavior is indeed preferable.
+Cheers!
+"""]]

diff --git a/doc/bugs/git-annex_drop_fails_to_access_file:__47____47____47___target_URL_on_Windows.mdwn b/doc/bugs/git-annex_drop_fails_to_access_file:__47____47____47___target_URL_on_Windows.mdwn
new file mode 100644
index 0000000..ada6621
--- /dev/null
+++ b/doc/bugs/git-annex_drop_fails_to_access_file:__47____47____47___target_URL_on_Windows.mdwn
@@ -0,0 +1,29 @@
+### Please describe the problem.
+
+If I addurl file pointing to file:///C:/... it seems to work just fine, but then refuses to drop it stating that can't verify its presence.
+
+Please see two screenshots (sorry for not cut/paste here since it was already was painful -- debugging under Virtualbox in remote vnc through debconf internet which for some reason drops for me quite often):
+
+http://www.onerussian.com/tmp/gkrellShoot_08-19-15_220150.png
+http://www.onerussian.com/tmp/gkrellShoot_08-19-15_184052.png
+
+as screenshot shows, apparently wget is clueless about file:// targets on windows (while curl does fine) -- may be related ;-)
+
+### What steps will reproduce the problem?
+
+addurl some file:///C:/ under windows pointing to existing file, and then try to drop that annexed file
+
+### What version of git-annex are you using? On what operating system?
+
+windows
+20150805 or so
+
+### Please provide any additional information below.
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+
+
+# End of transcript or log.
+"""]]

Added a comment: works with sync --content, but the assistant is slow to pickup tracking info
diff --git a/doc/forum/mesh_configurations/comment_8_a2b5da1ea55a222dd30f0e982d5ee807._comment b/doc/forum/mesh_configurations/comment_8_a2b5da1ea55a222dd30f0e982d5ee807._comment
new file mode 100644
index 0000000..20eb4eb
--- /dev/null
+++ b/doc/forum/mesh_configurations/comment_8_a2b5da1ea55a222dd30f0e982d5ee807._comment
@@ -0,0 +1,197 @@
+[[!comment format=mdwn
+ username="anarcat"
+ subject="works with sync --content, but the assistant is slow to pickup tracking info"
+ date="2015-08-19T20:29:46Z"
+ content="""
+well, this is not exactly the topology i have here.
+
+you setup a topology like this:
+
+    A <- B <-> C
+
+`X <- Y` means `X is a remote of Y`.
+
+My topology is:
+
+    A -> B -> C
+
+So B can't directly manage objects from A. It can *receive* objects from it, but that's it.
+
+So here's a clearer transcript of the session, using the same semantics you have been using for the different repos, but with the remotes setup differently, as I describe above:
+
+<pre>
+[1113]anarcat@desktop008:bench$ git init B
+Initialized empty Git repository in /home/anarcat/test/bench/B/.git/
+[1114]anarcat@desktop008:bench$ cd B/
+[1115]anarcat@desktop008:B$ git annex init
+init  ok
+(recording state in git...)
+[1116]anarcat@desktop008:B$ date > somefile
+[1117]anarcat@desktop008:B$ git annex add
+add somefile ok
+(recording state in git...)
+[1118]anarcat@desktop008:B$ git commit -madded
+[master (root-commit) d2f6177] added
+ 1 file changed, 1 insertion(+)
+ create mode 120000 somefile
+[1119]anarcat@desktop008:B$ git annex wanted . \"not inallgroup=backup\"
+wanted . ok
+(recording state in git...)
+[1138]anarcat@desktop008:B$ git remote add C ../C # actually did that later
+[1120]anarcat@desktop008:B$ cd ../
+[1121]anarcat@desktop008:bench$ git clone -o B B A
+Cloning into 'A'...
+done.
+[1122]anarcat@desktop008:bench$ git clone B C
+Cloning into 'C'...
+done.
+[1123]anarcat@desktop008:bench$ cd A
+[1124]anarcat@desktop008:A$ git annex wanted . standard
+(merging B/git-annex into git-annex...)
+(recording state in git...)
+wanted . ok
+(recording state in git...)
+[1125]anarcat@desktop008:A$ git annex group . source
+group . ok
+(recording state in git...)
+[1126]anarcat@desktop008:A$ cd ../C
+[1127]anarcat@desktop008:C$ git annex wanted . standard
+(merging origin/git-annex into git-annex...)
+(recording state in git...)
+wanted . ok
+(recording state in git...)
+[1128]anarcat@desktop008:C$ git annex group . backup
+group . ok
+(recording state in git...)
+[1142]anarcat@desktop008:C$ git remote rm origin # because this is S3 in production, and can't do anything on its own
+</pre>
+
+And of course now, it actually works fine, with `sync --content`:
+
+<pre>
+[1144]anarcat@desktop008:A$ git annex sync --content
+commit  ok
+pull B
+remote: Counting objects: 20, done.
+remote: Compressing objects: 100% (18/18), done.
+remote: Total 20 (delta 8), reused 0 (delta 0)
+Unpacking objects: 100% (20/20), done.
+From /home/anarcat/test/bench/B
+   d2f6177..b625a42  master     -> B/master
+   0432685..2061cf9  git-annex  -> B/git-annex
+ok
+(merging B/git-annex into git-annex...)
+copy otherfile copy otherfile (to B...) ok
+drop otherfile ok
+pull B
+ok
+(recording state in git...)
+push B
+Counting objects: 8, done.
+Delta compression using up to 2 threads.
+Compressing objects: 100% (6/6), done.
+Writing objects: 100% (8/8), 720 bytes | 0 bytes/s, done.
+Total 8 (delta 3), reused 0 (delta 0)
+To /home/anarcat/test/bench/B
+   0432685..e0fccbd  git-annex -> synced/git-annex
+ok
+[1145]anarcat@desktop008:A$ cd ../B
+[1146]anarcat@desktop008:B$ git annex sync --content
+commit  ok
+pull C
+remote: Counting objects: 5, done.
+remote: Compressing objects: 100% (4/4), done.
+remote: Total 5 (delta 2), reused 0 (delta 0)
+Unpacking objects: 100% (5/5), done.
+From ../C
+   2061cf9..1d0a3d5  git-annex  -> C/git-annex
+ok
+(merging C/git-annex into git-annex...)
+(recording state in git...)
+copy otherfile copy otherfile (to C...) ok
+drop otherfile ok
+pull C
+ok
+(recording state in git...)
+push C
+Counting objects: 20, done.
+Delta compression using up to 2 threads.
+Compressing objects: 100% (16/16), done.
+Writing objects: 100% (20/20), 1.55 KiB | 0 bytes/s, done.
+Total 20 (delta 10), reused 0 (delta 0)
+To ../C
+   2061cf9..86a892f  git-annex -> synced/git-annex
+ok
+[1147]anarcat@desktop008:B$ git annex list
+here
+|C
+||web
+|||bittorrent
+||||
+_X__ otherfile
+_X__ somefile
+</pre>
+
+Now, that's all great for `sync --content` - but what about the assistant?
+
+<pre>
+[1150]anarcat@desktop008:B$ git annex assistant
+[1151]anarcat@desktop008:B$ cd ../A
+[1152]anarcat@desktop008:A$ git annex assistant
+[1154]anarcat@desktop008:A$ date > foo
+[1157]anarcat@desktop008:A$ git annex list --allrepos
+here
+|B
+||web
+|||bittorrent
+||||anarcat@desktop008:~/test/bench/C
+|||||
+_X___ foo
+____X otherfile
+____X somefile
+[1158]anarcat@desktop008:A$ sleep 600; git annex list --allrepos
+here
+|B
+||web
+|||bittorrent
+||||anarcat@desktop008:~/test/bench/C
+|||||
+_X___ foo
+____X otherfile
+____X somefile
+</pre>
+
+so from `A`'s perspective, it looks like the file didn't migrate properly. *but* it actually did!
+
+<pre>
+[1159]anarcat@desktop008:A$ cd ../B
+[1160]anarcat@desktop008:B$ git annex list --allrepos
+here
+|C
+||web
+|||bittorrent
+||||anarcat@desktop008:~/test/bench/A
+|||||
+_X___ foo
+_X___ otherfile
+_X___ somefile
+[1161]anarcat@desktop008:B$ cd -
+/home/anarcat/test/bench/A
+[1162]anarcat@desktop008:A$ git annex list --allrepos
+here
+|B
+||web
+|||bittorrent
+||||anarcat@desktop008:~/test/bench/C
+|||||
+_X___ foo
+____X otherfile
+____X somefile
+</pre>
+
+how long does it take for the assistant to start syncs like this? are those timers user-accessible somehow? this problem sure looks like [[bugs/sync__47__git-annex_branch_not_syncing_in_the_assistant]] - but maybe i'm confused there as well.
+
+anyways, it does seem like content actually does gets synced around properly by the assistant. i'll try to deploy the new preferred content expression in production and report back here.

(Diff truncated)
devblog
diff --git a/doc/devblog/day_314__pre_trip_catchup.mdwn b/doc/devblog/day_314__pre_trip_catchup.mdwn
new file mode 100644
index 0000000..15546aa
--- /dev/null
+++ b/doc/devblog/day_314__pre_trip_catchup.mdwn
@@ -0,0 +1,13 @@
+Did some work on Friday and Monday to let external special remotes be used
+in a readonly mode. This lets files that are stored in the remote be
+downloaded by git-annex without the user needing to install the 
+external special remote program. For this to work, the external special
+remote just has to tell git-annex the urls to use. This was developed in
+collaboration with Benjamin Gilbert, who is developing
+[gcsannex](https://github.com/bgilbert/gcsannex), a Google Cloud Storage
+special remote.
+
+Today, got caught up with recent traffic, including fixing a couple of
+bugs. The backlog remains in the low 90's, which is a good place to be as I
+prepare for my August vacation week in the SF Bay Area, followed by a week
+for ICFP and the Haskell Symposium in Vancouver.

working example
diff --git a/doc/forum/mesh_configurations/comment_7_6c9d499f64067ee9d3721dc763f3c425._comment b/doc/forum/mesh_configurations/comment_7_6c9d499f64067ee9d3721dc763f3c425._comment
new file mode 100644
index 0000000..1767d53
--- /dev/null
+++ b/doc/forum/mesh_configurations/comment_7_6c9d499f64067ee9d3721dc763f3c425._comment
@@ -0,0 +1,123 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 7"""
+ date="2015-08-19T18:51:42Z"
+ content="""
+I'm afraid I don't have time to continue to read and try to debug
+transcripts of this being set up incorrectly in various ways. 
+
+So, here's a transcript of the configuration I described, which seems to be
+working as I'd expect it to work:
+
+	joey@darkstar:~/tmp>mkdir bench
+	joey@darkstar:~/tmp>cd bench
+	joey@darkstar:~/tmp/bench>git init A
+	Initialized empty Git repository in /home/joey/tmp/bench/A/.git/
+	joey@darkstar:~/tmp/bench>cd A
+	joey@darkstar:~/tmp/bench/A>git annex init
+	init  ok
+	(recording state in git...)
+	joey@darkstar:~/tmp/bench/A>git annex wanted . standard
+	wanted . ok
+	(recording state in git...)
+	joey@darkstar:~/tmp/bench/A>git annex group . source
+	group . ok
+	(recording state in git...)
+	joey@darkstar:~/tmp/bench/A>date > somefile
+	joey@darkstar:~/tmp/bench/A>git annex add
+	add somefile ok
+	(recording state in git...)
+	joey@darkstar:~/tmp/bench/A>git commit -m added
+	[master (root-commit) 4a322e1] added
+	 1 file changed, 1 insertion(+)
+	 create mode 120000 somefile
+	joey@darkstar:~/tmp/bench/A>cd ..
+	joey@darkstar:~/tmp/bench>git clone A B
+	Cloning into 'B'...
+	done.
+	joey@darkstar:~/tmp/bench>cd B
+	joey@darkstar:~/tmp/bench/B>git annex wanted . "not inallgroup=backup"
+	(merging origin/git-annex into git-annex...)
+	(recording state in git...)
+	wanted . ok
+	(recording state in git...)
+	joey@darkstar:~/tmp/bench/B>cd ..
+	joey@darkstar:~/tmp/bench>git clone B C
+	Cloning into 'C'...
+	done.
+	joey@darkstar:~/tmp/bench>cd C
+	joey@darkstar:~/tmp/bench/C>git annex group . backup
+	(merging origin/git-annex into git-annex...)
+	(recording state in git...)
+	group . ok
+	(recording state in git...)
+	joey@darkstar:~/tmp/bench/C>git annex wanted . standard
+	wanted . ok
+	(recording state in git...)
+	joey@darkstar:~/tmp/bench/C>cd ..
+	joey@darkstar:~/tmp/bench>cd B
+	joey@darkstar:~/tmp/bench/B>git remote add A ../A
+	joey@darkstar:~/tmp/bench/B>git remote add C ../C
+
+Now observe sync moving the file from A thru B to C:
+
+	joey@darkstar:~/tmp/bench/B>git annex sync --content
+	commit  ok
+	pull origin 
+	ok
+	pull C 
+	remote: Counting objects: 10, done.
+	remote: Compressing objects: 100% (9/9), done.
+	remote: Total 10 (delta 3), reused 0 (delta 0)
+	Unpacking objects: 100% (10/10), done.
+	From ../C
+	 * [new branch]      git-annex  -> C/git-annex
+	 * [new branch]      master     -> C/master
+	ok
+	pull A 
+	From ../A
+	 * [new branch]      git-annex  -> A/git-annex
+	 * [new branch]      master     -> A/master
+	ok
+	(merging C/git-annex into git-annex...)
+	get somefile (from origin...) ok
+	copy somefile copy somefile (to C...) ok
+	drop somefile ok
+	drop origin somefile ok
+	pull origin 
+	ok
+	pull C 
+	ok
+	pull A 
+	ok
+	(recording state in git...)
+	push origin 
+	Counting objects: 21, done.
+	Delta compression using up to 4 threads.
+	Compressing objects: 100% (19/19), done.
+	Writing objects: 100% (21/21), 2.19 KiB | 0 bytes/s, done.
+	Total 21 (delta 7), reused 0 (delta 0)
+	To /home/joey/tmp/bench/A
+	 * [new branch]      git-annex -> synced/git-annex
+	 * [new branch]      master -> synced/master
+	ok
+	push C 
+	Counting objects: 5, done.
+	Delta compression using up to 4 threads.
+	Compressing objects: 100% (4/4), done.
+	Writing objects: 100% (5/5), 474 bytes | 0 bytes/s, done.
+	Total 5 (delta 2), reused 0 (delta 0)
+	To ../C
+	 * [new branch]      git-annex -> synced/git-annex
+	 * [new branch]      master -> synced/master
+	ok
+	push A 
+	Everything up-to-date
+	ok
+	joey@darkstar:~/tmp/bench/B>git annex whereis
+	whereis somefile (1 copy) 
+	  	65092dc3-ea1e-4267-89b7-5fcb8df2c6ae -- joey@darkstar:~/tmp/bench/C [C]
+	ok
+
+Er, the 'A' remote in 'B' was unnecessary since A is origin. But otherwise, I think that's what you asked for.. HTH.
+"""]]

response
diff --git a/doc/special_remotes/bup/comment_14_940b778f97377e83dc16439c0c7e5b38._comment b/doc/special_remotes/bup/comment_14_940b778f97377e83dc16439c0c7e5b38._comment
new file mode 100644
index 0000000..7c0d5b9
--- /dev/null
+++ b/doc/special_remotes/bup/comment_14_940b778f97377e83dc16439c0c7e5b38._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 14"""
+ date="2015-08-19T18:30:16Z"
+ content="""
+@darkfeline, setting buprepo= causes git-annex to run bup with -r. 
+You can verify this by using the --debug switch.
+
+IIRC, bup still creates ~/.bup when used this way, but doesn't store the
+contents of annexed files there. It uses it only to store some small index
+files, which are also stored in the repo specified with -r. This seems
+weird, but I don't think this is a bug on bup's part; it seems to
+intentionally do that, using path names in ~/.bup that are constructed to
+not conflict when -r is used with different repositories.
+I suppose bup has a good reason to do this, though I don't know what the
+reason is.
+
+I can blow ~/.bup away, run "bup init" to make a fresh clean ~/.bup,
+and then git-annex can still get the content of files from the buprepo=
+repository. So, it seems that buprepo= is working ok.
+"""]]

response
diff --git a/doc/special_remotes/glacier/comment_11_e062b823b4d0b365698a6488d756b85c._comment b/doc/special_remotes/glacier/comment_11_e062b823b4d0b365698a6488d756b85c._comment
new file mode 100644
index 0000000..0c38120
--- /dev/null
+++ b/doc/special_remotes/glacier/comment_11_e062b823b4d0b365698a6488d756b85c._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 11"""
+ date="2015-08-19T18:27:53Z"
+ content="""
+@forbesmyester, I think that the "glacier" program you have installed is
+the one from boto, not the one from glacier-cli. git-annex only supports
+the glacier-cli one.
+
+Note that, since version 5.20150219, git-annex probes to see if the
+"glacier" program in PATH is the one from boto, and fails with a nicer
+error message.
+"""]]

response
diff --git a/doc/forum/Github_pull_request_with_git-annex/comment_1_03023d2fba47e84d03573d996e8366cf._comment b/doc/forum/Github_pull_request_with_git-annex/comment_1_03023d2fba47e84d03573d996e8366cf._comment
new file mode 100644
index 0000000..ef165fe
--- /dev/null
+++ b/doc/forum/Github_pull_request_with_git-annex/comment_1_03023d2fba47e84d03573d996e8366cf._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-08-19T18:17:17Z"
+ content="""
+Your pull request should be for the branch you changed. In this case, the
+`master` branch. This is the same as adding files to a regular git
+repository and making a pull request for that.
+
+The changes that git-annex makes to the `git-annex branch` can either be
+ignored by the person who merges your pull request, or they could opt to
+fetch your git-annex branch and let git-annex auto-merge it for them. A
+manual review and pull request of the `git-annex` branch is not likely to be
+productive. Whether they need to merge your `git-annex` branch into their
+`git-annex` branch depends on whether git-annex's information about eg,
+locations of file contents needs to be passed along with your pull
+request.
+
+Note that GitHub does not support using git-annex to upload the content of
+annexed files to it. (GitLab does support this.) This GitHub limitation
+may cause problems with this kind of workflow.
+"""]]

followup
diff --git a/doc/bugs/External_special_remote_SETURLPRESENT_doesn__39__t_seem_to_work/comment_8_44ae52059790e105442067c311a7ec8b._comment b/doc/bugs/External_special_remote_SETURLPRESENT_doesn__39__t_seem_to_work/comment_8_44ae52059790e105442067c311a7ec8b._comment
new file mode 100644
index 0000000..25c1ae8
--- /dev/null
+++ b/doc/bugs/External_special_remote_SETURLPRESENT_doesn__39__t_seem_to_work/comment_8_44ae52059790e105442067c311a7ec8b._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 8"""
+ date="2015-08-19T18:03:22Z"
+ content="""
+I chose readonly=true to be consistent with the annex.readonly git config
+values. This is inconsistent with some other initremote stuff that uses
+foo=yes.
+
+I should probably make everything accept everything, which seems to be
+approximately what git-config does, but too much bother for now.
+
+----
+
+Indeed, WHEREIS is not useful for encrypted (or chunked) special remotes.
+I've made it not be used in those cases.
+"""]]

Added a comment
diff --git a/doc/forum/mesh_configurations/comment_6_7cb33d2416289f744828d8d9d24e9ef6._comment b/doc/forum/mesh_configurations/comment_6_7cb33d2416289f744828d8d9d24e9ef6._comment
new file mode 100644
index 0000000..cd7e677
--- /dev/null
+++ b/doc/forum/mesh_configurations/comment_6_7cb33d2416289f744828d8d9d24e9ef6._comment
@@ -0,0 +1,117 @@
+[[!comment format=mdwn
+ username="anarcat"
+ subject="comment 6"
+ date="2015-08-19T18:13:22Z"
+ content="""
+right, i thought as well that the assistant wouldn't pickup some stuff...
+
+but `sync --content` doesn't behave as expected either:
+
+<pre>
+[1081]anarcat@desktop008:b$ git annex list --allrepos
+here
+|origin
+||web
+|||bittorrent
+||||anarcat@desktop008:~/test/g-a/a
+|||||
+XX__X bar
+XX__X foo
+X___X quuex
+XX__X test
+[1082]anarcat@desktop008:b$ git annex sync --content
+commit  ok
+pull origin
+remote: Counting objects: 6, done.
+remote: Compressing objects: 100% (5/5), done.
+remote: Total 6 (delta 3), reused 0 (delta 0)
+Unpacking objects: 100% (6/6), done.
+From ../c
+   29d3b7b..6afbb52  git-annex  -> origin/git-annex
+ok
+(merging origin/git-annex into git-annex...)
+(recording state in git...)
+(recovering from race...)
+drop bar ok
+drop foo ok
+drop test ok
+pull origin
+ok
+(recording state in git...)
+push origin
+Counting objects: 18, done.
+Delta compression using up to 2 threads.
+Compressing objects: 100% (14/14), done.
+Writing objects: 100% (18/18), 1.47 KiB | 0 bytes/s, done.
+Total 18 (delta 11), reused 0 (delta 0)
+To ../c
+   873a124..8390704  git-annex -> synced/git-annex
+ok
+[1083]anarcat@desktop008:b$ git annex list --allrepos
+here
+|origin
+||web
+|||bittorrent
+||||anarcat@desktop008:~/test/g-a/a
+|||||
+_X__X bar
+_X__X foo
+X___X quuex
+_X__X test
+[1084]anarcat@desktop008:b$ git annex list --allrepos
+here
+|origin
+||web
+|||bittorrent
+||||anarcat@desktop008:~/test/g-a/a
+|||||
+_X__X bar
+_X__X foo
+X___X quuex
+_X__X test
+[1084]anarcat@desktop008:b$ git annex wanted .
+not inallgroup=backup
+[1085]anarcat@desktop008:b$ cd ../a
+[1086]anarcat@desktop008:a$ git annex list --allrepos
+here
+|origin
+||web
+|||bittorrent
+||||
+XX__ bar
+XX__ foo
+XX__ quuex
+XX__ test
+[1087]anarcat@desktop008:a$ git annex sync --content
+commit  ok
+pull origin
+remote: Counting objects: 114, done.
+remote: Compressing objects: 100% (94/94), done.
+remote: Total 114 (delta 54), reused 0 (delta 0)
+Receiving objects: 100% (114/114), 9.20 KiB | 0 bytes/s, done.
+Resolving deltas: 100% (54/54), completed with 6 local objects.
+From ../b
+   de5f95e..158c3cc  git-annex  -> origin/git-annex
+ok
+(merging origin/git-annex into git-annex...)
+pull origin
+ok
+[1088]anarcat@desktop008:a$ git annex list --allrepos
+here
+|origin
+||web
+|||bittorrent
+||||anarcat@desktop008:~/test/g-a/c
+|||||
+X___X bar
+X___X foo
+XX___ quuex
+X___X test
+[1089]anarcat@desktop008:a$ git annex wanted .
+groupwanted
+[1090]anarcat@desktop008:a$ git annex group .
+source
+</pre>
+
+files are still not removed from `a` and a few of them were dropped from `b`, but not all of them. but worse, one file still isn't sent to the backup server `c` at all.
+"""]]

comment
diff --git a/doc/forum/mesh_configurations/comment_5_a181fde7b7f6d0559331e1afa395ba0a._comment b/doc/forum/mesh_configurations/comment_5_a181fde7b7f6d0559331e1afa395ba0a._comment
new file mode 100644
index 0000000..4cc4121
--- /dev/null
+++ b/doc/forum/mesh_configurations/comment_5_a181fde7b7f6d0559331e1afa395ba0a._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2015-08-19T17:54:36Z"
+ content="""
+You have B configured as a regular transfer repo, so it only wants to drop
+files once they have reached some client repos. Settings its preferred
+content to "not inallgroup=backup" should fix that.
+
+Also, the assistant can notice some configuration changes that are made
+while it's running, but maybe not all of them, and maybe it won't rescan
+files to transfer right away after such a change is made. I'd use `git
+annex sync --content` to test such changes, and save the assistant for once
+I have a working setup.
+"""]]

diff --git a/doc/forum/Github_pull_request_with_git-annex.mdwn b/doc/forum/Github_pull_request_with_git-annex.mdwn
new file mode 100644
index 0000000..b0ae1da
--- /dev/null
+++ b/doc/forum/Github_pull_request_with_git-annex.mdwn
@@ -0,0 +1,11 @@
+I would like to use git annex with github. Here what I did:
+
+1. Create github directory "a". Added all the special remote and git annex files. Pushed them to the "a" using "git annex sync."
+2. Fork the repository on gihub to "b". Clone it and enable remote and I could pull annexed files.
+3. Added repository "a" as "upstream" tracking remote to "b".
+3. Created a second special remote for "b". Added new git annex files to it. Used "git annex sync origin" to push the changed files to the forked repository "b".
+4. Now I would like to create a pull request. What are branches I should create pull request for?  a:synced/git-annex vs b:synced/git-annex? Or, a:synced/git-annex vs b:git-annex? Do I need to create separate pull request for the "master"?
+
+Thanks for the help.
+
+ 

Added a comment
diff --git a/doc/forum/mesh_configurations/comment_4_d5c8e99cadf976434460d6d0f410136e._comment b/doc/forum/mesh_configurations/comment_4_d5c8e99cadf976434460d6d0f410136e._comment
new file mode 100644
index 0000000..39446c7
--- /dev/null
+++ b/doc/forum/mesh_configurations/comment_4_d5c8e99cadf976434460d6d0f410136e._comment
@@ -0,0 +1,282 @@
+[[!comment format=mdwn
+ username="anarcat"
+ subject="comment 4"
+ date="2015-08-19T17:17:50Z"
+ content="""
+darn, you're right... then i screwed up my copy-paste. :( the assistant *was* running on a and b, that i am sure of.
+
+here's a more complete transcript (hopefully):
+
+<pre>
+[997]anarcat@desktop008:test$ mkdir g-a
+[998]anarcat@desktop008:test$ cd g-a/
+[999]anarcat@desktop008:g-a$ git init a
+Initialized empty Git repository in /home/anarcat/test/g-a/a/.git/
+[1000]anarcat@desktop008:g-a$ git init b
+Initialized empty Git repository in /home/anarcat/test/g-a/b/.git/
+[1001]anarcat@desktop008:g-a$ git init c
+Initialized empty Git repository in /home/anarcat/test/g-a/c/.git/
+[1002]anarcat@desktop008:g-a$ cd a
+[1003]anarcat@desktop008:a$ git annex init
+init  ok
+(recording state in git...)
+[1004]anarcat@desktop008:a$ git remote add origin ../b
+[1005]anarcat@desktop008:a$ cd ../b
+[1006]anarcat@desktop008:b$ git annex init
+init  ok
+(recording state in git...)
+[1007]anarcat@desktop008:b$ git remote add origin ../c
+[1008]anarcat@desktop008:b$ cd ../c
+[1009]anarcat@desktop008:c$ git annex init
+init  ok
+(recording state in git...)
+[1010]anarcat@desktop008:c$ cd ../a/
+[1011]anarcat@desktop008:a$ git annex ^C
+[1011]anarcat@desktop008:a130$ touch test
+[1012]anarcat@desktop008:a$ git annex add tset
+git-annex: tset not found
+git-annex: add: 1 failed
+[1013]anarcat@desktop008:a1$ git annex add test
+add test ok
+(recording state in git...)
+[1014]anarcat@desktop008:a$ git annex sync
+commit  ok
+pull origin
+warning: no common commits
+remote: Counting objects: 5, done.
+remote: Compressing objects: 100% (3/3), done.
+remote: Total 5 (delta 0), reused 0 (delta 0)
+Unpacking objects: 100% (5/5), done.
+From ../b
+ * [new branch]      git-annex  -> origin/git-annex
+ok
+(merging origin/git-annex into git-annex...)
+(recording state in git...)
+push origin
+Counting objects: 16, done.
+Delta compression using up to 2 threads.
+Compressing objects: 100% (12/12), done.
+Writing objects: 100% (16/16), 1.56 KiB | 0 bytes/s, done.
+Total 16 (delta 1), reused 0 (delta 0)
+To ../b
+ * [new branch]      git-annex -> synced/git-annex
+ * [new branch]      master -> synced/master
+ok
+[1015]anarcat@desktop008:a$ git annex assistant
+[1016]anarcat@desktop008:a$ cd ../b
+[1017]anarcat@desktop008:b$ git annex assistant
+[1018]anarcat@desktop008:b$ ls
+[1019]anarcat@desktop008:b$ git anne^C
+[1019]anarcat@desktop008:b130$ ls
+[1019]anarcat@desktop008:b$ git annex sync
+commit  ok
+pull origin
+
+merge: refs/remotes/origin/master - not something we can merge
+
+merge: refs/remotes/origin/synced/master - not something we can merge
+failed
+git-annex: sync: 1 failed
+[1020]anarcat@desktop008:b1$ git remote -v^C
+[1020]anarcat@desktop008:b130$ git re^C
+[1020]anarcat@desktop008:b130$ ls
+[1021]anarcat@desktop008:b$ cd ../
+[1022]anarcat@desktop008:g-a$ git annexccd ^C
+[1022]anarcat@desktop008:g-a130$ cd c
+[1023]anarcat@desktop008:c$ git annex sync
+commit  ok
+[1024]anarcat@desktop008:c$ ls
+[1025]anarcat@desktop008:c$ cd ../b
+[1026]anarcat@desktop008:b$ git co master
+error: pathspec 'master' did not match any file(s) known to git.
+[1027]anarcat@desktop008:b1$ git branch -a
+  git-annex
+  synced/git-annex
+  synced/master
+  remotes/origin/git-annex
+[1028]anarcat@desktop008:b$ git co -b master synced/master
+Already on 'master'
+[1029]anarcat@desktop008:b$ ls
+test
+[1030]anarcat@desktop008:b$ git annex sync
+commit  ok
+pull origin
+ok
+[1031]anarcat@desktop008:b$ cd ..c
+bash: cd: ..c: No such file or directory
+[1032]anarcat@desktop008:b1$ cd ../c
+[1033]anarcat@desktop008:c$ ls
+[1034]anarcat@desktop008:c$ git annex sync
+(recording state in git...)
+commit  ok
+[1035]anarcat@desktop008:c$ ls
+[1036]anarcat@desktop008:c$ cd ../a
+[1037]anarcat@desktop008:a$ echo test > foo
+[1038]anarcat@desktop008:a$ ls -al
+total 20K
+drwxr-xr-x  3 anarcat 4294967294 4096 aoû 19 13:12 .
+drwxr-xr-x  5 anarcat 4294967294 4096 aoû 19 13:10 ..
+lrwxrwxrwx  1 anarcat 4294967294  178 aoû 19 13:12 foo -> .git/annex/objects/w8/pv/SHA256E-s5--f2ca1bb6c7e907d06dafe4687e579fce76b37e4e93b7605022da52e6ccc26fd2/SHA256E-s5--f2ca1bb6c7e907d06dafe4687e579fce76b37e4e93b7605022da52e6ccc26fd2
+drwxr-xr-x 10 anarcat 4294967294 4096 aoû 19 13:12 .git
+lrwxrwxrwx  1 anarcat 4294967294  178 aoû 19 13:11 test -> .git/annex/objects/pX/ZJ/SHA256E-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855/SHA256E-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
+[1039]anarcat@desktop008:a$ git status
+On branch master
+nothing to commit, working directory clean
+[1040]anarcat@desktop008:a$ git annex list
+here
+|origin
+||web
+|||bittorrent
+||||
+XX__ foo
+XX__ test
+[1041]anarcat@desktop008:a$ git annex list --allrepos
+here
+|origin
+||web
+|||bittorrent
+||||
+XX__ foo
+XX__ test
+[1042]anarcat@desktop008:a$ cd ../b
+[1043]anarcat@desktop008:b$ git annex wanted transfer
+git-annex: there is no available git remote named \"transfer\"
+[1044]anarcat@desktop008:b1$ git annex wanted . transfer
+wanted . git-annex: Parse error: Parse failure: near \"transfer\"
+[1045]anarcat@desktop008:b1$ git annex wanted . groupwanted
+wanted . ok
+(recording state in git...)
+[1046]anarcat@desktop008:b$ git annex group . transfer
+group . c ok
+(recording state in git...)
+[1047]anarcat@desktop008:b$ cd ../a
+[1048]anarcat@desktop008:a$ git annex group . source
+group . ok
+(recording state in git...)
+[1049]anarcat@desktop008:a$ git annex wanted . groupwanted
+wanted . ok
+(recording state in git...)
+[1050]anarcat@desktop008:a$ cd ../c
+[1051]anarcat@desktop008:c$ git annex wanted . groupwanted
+wanted . ok
+(recording state in git...)
+[1052]anarcat@desktop008:c$ git annex group . backup
+group . (merging synced/git-annex into git-annex...)
+(recording state in git...)
+ok
+(recording state in git...)
+[1053]anarcat@desktop008:c$ cd ../
+[1054]anarcat@desktop008:g-a$ cd b
+[1055]anarcat@desktop008:b$ cd ../a
+[1056]anarcat@desktop008:a$ git annex list --allrepos
+here
+|origin
+||web
+|||bittorrent
+||||
+XX__ foo
+XX__ test
+[1057]anarcat@desktop008:a$ git annex^C
+[1057]anarcat@desktop008:a130$ cd ../
+[1058]anarcat@desktop008:g-a$ git ^C
+[1058]anarcat@desktop008:g-a130$ cd b
+[1059]anarcat@desktop008:b$ git remote -v
+origin  ../c (fetch)
+origin  ../c (push)
+[1060]anarcat@desktop008:b$ git annex sync
+commit  ok
+pull origin
+remote: Counting objects: 23, done.
+remote: Compressing objects: 100% (19/19), done.
+remote: Total 23 (delta 8), reused 0 (delta 0)
+Unpacking objects: 100% (23/23), done.
+From ../c
+   ac66bb1..43cfe35  git-annex  -> origin/git-annex

(Diff truncated)
response
diff --git a/doc/forum/Searching_metadata_and_file_content__63__/comment_3_67715b73349dc92e9746b234024057ef._comment b/doc/forum/Searching_metadata_and_file_content__63__/comment_3_67715b73349dc92e9746b234024057ef._comment
new file mode 100644
index 0000000..56986b5
--- /dev/null
+++ b/doc/forum/Searching_metadata_and_file_content__63__/comment_3_67715b73349dc92e9746b234024057ef._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2015-08-19T17:11:41Z"
+ content="""
+Nice script to use recoil, and I imagine similar approaches could be used
+to integrate with other search engines.
+
+Note that `git annex metadata --json` yields a format better suited to
+machine parsing. Especially because metadata values can contain arbitrary
+content, even potentially newlines.
+
+There are plans to eventually make git-annex use a caching database for
+things, including metadata. This would automatically get updated whenever there
+are changes to the metadata, and SQL queries could then be run against it.
+Or, `git annex metadata` queries could boil down to SQL queries and so run
+a lot faster than they do now.
+"""]]

comment
diff --git a/doc/forum/mesh_configurations/comment_3_d228158cf00cd04dc9ef5602acebdaac._comment b/doc/forum/mesh_configurations/comment_3_d228158cf00cd04dc9ef5602acebdaac._comment
new file mode 100644
index 0000000..4777457
--- /dev/null
+++ b/doc/forum/mesh_configurations/comment_3_d228158cf00cd04dc9ef5602acebdaac._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2015-08-19T17:04:30Z"
+ content="""
+Your transcript doesn't show the assistant running. It's not clear that, in
+your live deployment, any files ever got to repo B for the assistant there
+to deal with.
+
+Repos such as B need a preferred content expression like the one I gave. It
+doesn't matter a whole lot what group is used for them; overriding the
+groupwanted for the transfer group to use that expression would be one way
+to do it.
+"""]]
diff --git a/git-annex.cabal b/git-annex.cabal
index 103f122..5c4153a 100644
--- a/git-annex.cabal
+++ b/git-annex.cabal
@@ -1,5 +1,5 @@
 Name: git-annex
-Version: 5.20150812
+Version: 5.20150813
 Cabal-Version: >= 1.8
 License: GPL-3
 Maintainer: Joey Hess <id@joeyh.name>

Added a comment: clarifications
diff --git a/doc/forum/mesh_configurations/comment_2_0d9ba4017343475a96975145c9db29c5._comment b/doc/forum/mesh_configurations/comment_2_0d9ba4017343475a96975145c9db29c5._comment
new file mode 100644
index 0000000..9296cf7
--- /dev/null
+++ b/doc/forum/mesh_configurations/comment_2_0d9ba4017343475a96975145c9db29c5._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="anarcat"
+ subject="clarifications"
+ date="2015-08-19T16:57:49Z"
+ content="""
+the assistant is runnin on repos a and b. i was expecting it to move the files automatically.
+
+about repo groups, if i understand correctly, it should be:
+
+* `a`: *source*
+* `b`: *transfer* (or *not inallgroup=backup*?)
+* `c`: *backup*
+
+is that correct?
+"""]]

forwarded
diff --git a/doc/bugs/OOM_while_configuring_git-annex.mdwn b/doc/bugs/OOM_while_configuring_git-annex.mdwn
index cd5d878..07f8909 100644
--- a/doc/bugs/OOM_while_configuring_git-annex.mdwn
+++ b/doc/bugs/OOM_while_configuring_git-annex.mdwn
@@ -44,3 +44,5 @@ Currently, 5.20141203. Newest snapshot requires deps not yet packaged in Fedora.
   checking sha224... sha224sum
   checking sha384...Setup: out of memory (requested 1048576 bytes)
 """]]
+
+> forwarded to cabal && [[done]] per my comment --[[Joey]]
diff --git a/doc/bugs/OOM_while_configuring_git-annex/comment_5_49cfdd1b3a2bf2bc61f1cba7fe7cc11c._comment b/doc/bugs/OOM_while_configuring_git-annex/comment_5_49cfdd1b3a2bf2bc61f1cba7fe7cc11c._comment
new file mode 100644
index 0000000..ad63dba
--- /dev/null
+++ b/doc/bugs/OOM_while_configuring_git-annex/comment_5_49cfdd1b3a2bf2bc61f1cba7fe7cc11c._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2015-08-19T16:50:51Z"
+ content="""
+I notice that you're using Setup configure. It turns out that for some
+reason, Setup configure's dependency resolution fails to find available
+solutions, where cabal configure will easly succeed without using much
+memory. There's a bug filed about this now:
+<https://github.com/haskell/cabal/issues/2777>
+
+So, use cabal configure, or downloading the cabal.config from stackage will
+probably prevent this blowup by pinning all the package versions to
+particular versions.
+
+I don't think this can be fixed in git-annex, really. So will close this as
+forwarded to the above cabal bug.
+"""]]

move comment
diff --git a/doc/bugs/symlinks_to_absent_files_remain_upon_switching_to_direct_mode/comment_3_9b76d5f67a858ea0170e816b35190aef._comment b/doc/bugs/symlinks_to_absent_files_remain_upon_switching_to_direct_mode/comment_3_9b76d5f67a858ea0170e816b35190aef._comment
deleted file mode 100644
index 3c81b70..0000000
--- a/doc/bugs/symlinks_to_absent_files_remain_upon_switching_to_direct_mode/comment_3_9b76d5f67a858ea0170e816b35190aef._comment
+++ /dev/null
@@ -1,12 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 3"""
- date="2015-08-13T20:45:36Z"
- content="""
-Broken symlinks are really much preferable to files that don't have the
-content the user expects. Anyway, git-annex is just inheriting how git
-deals with symlinks on filesystems that don't support them.
-
-Previous discussion:
-<http://git-annex.branchable.com/bugs/symlinks_to_absent_files_remain_upon_switching_to_direct_mode/>
-"""]]
diff --git a/doc/bugs/symlinks_to_absent_files_remain_upon_switching_to_direct_mode2/comment_3_9b76d5f67a858ea0170e816b35190aef._comment b/doc/bugs/symlinks_to_absent_files_remain_upon_switching_to_direct_mode2/comment_3_9b76d5f67a858ea0170e816b35190aef._comment
new file mode 100644
index 0000000..3c81b70
--- /dev/null
+++ b/doc/bugs/symlinks_to_absent_files_remain_upon_switching_to_direct_mode2/comment_3_9b76d5f67a858ea0170e816b35190aef._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2015-08-13T20:45:36Z"
+ content="""
+Broken symlinks are really much preferable to files that don't have the
+content the user expects. Anyway, git-annex is just inheriting how git
+deals with symlinks on filesystems that don't support them.
+
+Previous discussion:
+<http://git-annex.branchable.com/bugs/symlinks_to_absent_files_remain_upon_switching_to_direct_mode/>
+"""]]

response
diff --git a/doc/forum/mesh_configurations/comment_1_0712fa3d50ca6092bd7d98c945b5cc31._comment b/doc/forum/mesh_configurations/comment_1_0712fa3d50ca6092bd7d98c945b5cc31._comment
new file mode 100644
index 0000000..a97ade4
--- /dev/null
+++ b/doc/forum/mesh_configurations/comment_1_0712fa3d50ca6092bd7d98c945b5cc31._comment
@@ -0,0 +1,23 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-08-19T16:40:16Z"
+ content="""
+It's easy to see why a file is not copied from source repo A to source repo
+B: The preferred content expression for a source repo is "not (copies=1)",
+so a source repo will not want to get any files from any other repo.
+
+You probably want to make the central repo use transfer; that's basically
+what it's for. Note that a transfer repo hangs onto file content until it
+reaches all client repos. So you might want to change the preferred content
+expression to refer to backup repos. Something as simple as this might
+work:
+
+	not inallgroup=backup
+
+I don't see any reason why a file wouldn't move from B to backup repo C,
+but I don't see anything in your transcript that shows that not happening
+either. Your transcript doesn't actually show running any git-annex commands
+that move file contents at all; no git annex copy/move, and the sync is not
+run with --content...
+"""]]

Fix reversion in init when ran as root, introduced in version 5.20150731.
diff --git a/Annex/Init.hs b/Annex/Init.hs
index 5759adf..e59f045 100644
--- a/Annex/Init.hs
+++ b/Annex/Init.hs
@@ -40,6 +40,7 @@ import Upgrade
 import Utility.UserInfo
 import Utility.FileMode
 import Annex.Perms
+import System.Posix.User
 #endif
 
 genDescription :: Maybe String -> Annex String
@@ -141,8 +142,10 @@ probeCrippledFileSystem = do
 		-- Should be unable to write to the file, unless
 		-- running as root, but some crippled
 		-- filesystems ignore write bit removals.
-		unlessM 
-		not <$> catchBoolIO (writeFile f "2" >> return True)
+		ifM ((== 0) <$> getRealUserID)
+			( return True
+			, not <$> catchBoolIO (writeFile f "2" >> return True)
+			)
 #endif
 
 checkCrippledFileSystem :: Annex ()
diff --git a/debian/changelog b/debian/changelog
index b81a533..20c28e9 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -14,6 +14,7 @@ git-annex (5.20150813) UNRELEASED; urgency=medium
   * Avoid building the assistant on the hurd, since an inotify equivilant
     is not yet implemented in git-annex for the hurd.
   * importfeed --relaxed: Avoid hitting the urls of items in the feed.
+  * Fix reversion in init when ran as root, introduced in version 5.20150731.
 
  -- Joey Hess <id@joeyh.name>  Wed, 12 Aug 2015 14:31:01 -0400
 
diff --git a/doc/bugs/decides_that_FS_is_crippled_under_cowbuilder___40__symlinks_supported_etc__41__.mdwn b/doc/bugs/decides_that_FS_is_crippled_under_cowbuilder___40__symlinks_supported_etc__41__.mdwn
index 68f9865..cad21f5 100644
--- a/doc/bugs/decides_that_FS_is_crippled_under_cowbuilder___40__symlinks_supported_etc__41__.mdwn
+++ b/doc/bugs/decides_that_FS_is_crippled_under_cowbuilder___40__symlinks_supported_etc__41__.mdwn
@@ -41,3 +41,5 @@ Debian sid   5.20150812-2
 
 # End of transcript or log.
 """]]
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/bugs/decides_that_FS_is_crippled_under_cowbuilder___40__symlinks_supported_etc__41__/comment_1_82480202831a08388f9f716abfaa0340._comment b/doc/bugs/decides_that_FS_is_crippled_under_cowbuilder___40__symlinks_supported_etc__41__/comment_1_82480202831a08388f9f716abfaa0340._comment
new file mode 100644
index 0000000..2374185
--- /dev/null
+++ b/doc/bugs/decides_that_FS_is_crippled_under_cowbuilder___40__symlinks_supported_etc__41__/comment_1_82480202831a08388f9f716abfaa0340._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-08-19T16:22:31Z"
+ content="""
+Actually, it does detect a crippled FS when run as root here. I guess you
+had some version confusion going on, since this problem was introduced in a
+recent release. Fixing..
+"""]]

tag moreinfo
diff --git a/doc/bugs/git_annex_test_fails_when_run_through_powershell.mdwn b/doc/bugs/git_annex_test_fails_when_run_through_powershell.mdwn
index 48291b7..fd9e2af 100644
--- a/doc/bugs/git_annex_test_fails_when_run_through_powershell.mdwn
+++ b/doc/bugs/git_annex_test_fails_when_run_through_powershell.mdwn
@@ -26,3 +26,5 @@ git-annex: MoveFileEx "C:\\Users\\duffrw\\LOCALS~1\\Temp\\importtest.0\\import1\
 
 # End of transcript or log.
 """]]
+
+[[!tag moreinfo]]

importfeed --relaxed: Avoid hitting the urls of items in the feed.
diff --git a/Annex/Init.hs b/Annex/Init.hs
index fad533d..5759adf 100644
--- a/Annex/Init.hs
+++ b/Annex/Init.hs
@@ -138,8 +138,10 @@ probeCrippledFileSystem = do
 		createSymbolicLink f f2
 		nukeFile f2
 		preventWrite f
-		-- Should be unable to write to the file, but some crippled
+		-- Should be unable to write to the file, unless
+		-- running as root, but some crippled
 		-- filesystems ignore write bit removals.
+		unlessM 
 		not <$> catchBoolIO (writeFile f "2" >> return True)
 #endif
 
diff --git a/Command/AddUrl.hs b/Command/AddUrl.hs
index adc0d3a..de3bff4 100644
--- a/Command/AddUrl.hs
+++ b/Command/AddUrl.hs
@@ -182,7 +182,7 @@ startWeb o s = go $ fromMaybe bad $ parseURI urlstring
 	regulardownload url = do
 		pathmax <- liftIO $ fileNameLengthLimit "."
 		urlinfo <- if relaxedOption o
-			then pure $ Url.UrlInfo True Nothing Nothing
+			then pure Url.assumeUrlExists
 			else Url.withUrlOptions (Url.getUrlInfo urlstring)
 		file <- adjustFile o <$> case fileOption o of
 			Just f -> pure f
diff --git a/Command/ImportFeed.hs b/Command/ImportFeed.hs
index 46e1b6d..d82d734 100644
--- a/Command/ImportFeed.hs
+++ b/Command/ImportFeed.hs
@@ -172,7 +172,9 @@ performDownload opts cache todownload = case location todownload of
 			r <- Remote.claimingUrl url
 			if Remote.uuid r == webUUID || rawOption opts
 				then do
-					urlinfo <- Url.withUrlOptions (Url.getUrlInfo url)
+					urlinfo <- if relaxedOption opts
+						then pure Url.assumeUrlExists
+						else Url.withUrlOptions (Url.getUrlInfo url)
 					maybeToList <$> addUrlFile (relaxedOption opts) url urlinfo f
 				else do
 					res <- tryNonAsync $ maybe
diff --git a/Utility/Url.hs b/Utility/Url.hs
index 90ca74e..976fe97 100644
--- a/Utility/Url.hs
+++ b/Utility/Url.hs
@@ -20,6 +20,7 @@ module Utility.Url (
 	exists,
 	UrlInfo(..),
 	getUrlInfo,
+	assumeUrlExists,
 	download,
 	downloadQuiet,
 	parseURIRelaxed
@@ -104,6 +105,9 @@ data UrlInfo = UrlInfo
 	, urlSuggestedFile :: Maybe FilePath
 	}
 
+assumeUrlExists :: UrlInfo
+assumeUrlExists = UrlInfo True Nothing Nothing
+
 {- Checks that an url exists and could be successfully downloaded,
  - also returning its size and suggested filename if available. -}
 getUrlInfo :: URLString -> UrlOptions -> IO UrlInfo
diff --git a/debian/changelog b/debian/changelog
index 1bba9d8..b81a533 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -13,6 +13,7 @@ git-annex (5.20150813) UNRELEASED; urgency=medium
     http.
   * Avoid building the assistant on the hurd, since an inotify equivilant
     is not yet implemented in git-annex for the hurd.
+  * importfeed --relaxed: Avoid hitting the urls of items in the feed.
 
  -- Joey Hess <id@joeyh.name>  Wed, 12 Aug 2015 14:31:01 -0400
 
diff --git a/doc/bugs/importfeed_--relaxed_fails_with_HEAD-rejecting_servers.mdwn b/doc/bugs/importfeed_--relaxed_fails_with_HEAD-rejecting_servers.mdwn
index 5a52af3..f7b6199 100644
--- a/doc/bugs/importfeed_--relaxed_fails_with_HEAD-rejecting_servers.mdwn
+++ b/doc/bugs/importfeed_--relaxed_fails_with_HEAD-rejecting_servers.mdwn
@@ -34,3 +34,5 @@ I ran into this bug trying to importfeed various BBC podcasts. For instance:
 ### What version of git-annex are you using? On what operating system?
 
 git-annex version: 5.20150731-1 on a quite up-to-date debian unstable.
+
+> Thanks for a nice test case. [[fixed|done]] --[[Joey]]
diff --git a/doc/git-annex-addurl.mdwn b/doc/git-annex-addurl.mdwn
index 888f6ac..1503a28 100644
--- a/doc/git-annex-addurl.mdwn
+++ b/doc/git-annex-addurl.mdwn
@@ -25,7 +25,8 @@ be used to get better filenames.
 
 * `--fast`
 
-  Avoid immediately downloading the url.
+  Avoid immediately downloading the url. The url is still checked
+  (via HEAD) to verify that it exists, and to get its size if possible.
 
 * `--relaxed`
 

paste from relevant man page
diff --git a/doc/bugs/git_annex_cannot_get_my_files_after_clone/comment_1_52c91f8d2e8086b26a078a02d036c197._comment b/doc/bugs/git_annex_cannot_get_my_files_after_clone/comment_1_52c91f8d2e8086b26a078a02d036c197._comment
new file mode 100644
index 0000000..2a375c5
--- /dev/null
+++ b/doc/bugs/git_annex_cannot_get_my_files_after_clone/comment_1_52c91f8d2e8086b26a078a02d036c197._comment
@@ -0,0 +1,28 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-08-19T16:12:12Z"
+ content="""
+From the rsync man page that the error directs you to:
+
+> rsync occasionally produces error messages that may seem a little cryp‐
+> tic. The one that seems to cause the most confusion is  "protocol  ver‐
+> sion mismatch -- is your shell clean?".
+
+> This  message is usually caused by your startup scripts or remote shell
+> facility producing unwanted garbage on the stream that rsync  is  using
+> for  its  transport.  The  way  to diagnose this problem is to run your
+> remote shell like this:
+
+>        ssh remotehost /bin/true > out.dat
+
+
+> then look at out.dat. If everything is working correctly  then  out.dat
+> should  be  a zero length file. If you are getting the above error from
+> rsync then you will probably find that out.dat contains  some  text  or
+> data.  Look  at  the contents and try to work out what is producing it.
+> The most common cause is incorrectly configured shell  startup  scripts
+> (such  as  .cshrc  or  .profile)  that  contain  output  statements for
+> non-interactive logins.
+
+"""]]

wrote ut issue
diff --git a/doc/bugs/git_annex_cannot_get_my_files_after_clone.mdwn b/doc/bugs/git_annex_cannot_get_my_files_after_clone.mdwn
new file mode 100644
index 0000000..764e7b1
--- /dev/null
+++ b/doc/bugs/git_annex_cannot_get_my_files_after_clone.mdwn
@@ -0,0 +1,36 @@
+### Please describe the problem.
+
+git annex cannot get me my file contents from my remotes
+
+### What steps will reproduce the problem?
+
+```
+git clone myserver:/path/to/repo
+cd repo
+git annex get
+```
+
+### What version of git-annex are you using? On what operating system?
+Using git-annex-5.20150327 on gentoo linux
+
+### Please provide any additional information below.
+
+The error messages I get egenrally look like:
+
+```
+get 2att/photos-glasgow/male/patrik.jpg (from clusterhost...) 
+git-annex: ../chymera/data/.git/annex/transfer/upload/b8415264-4b9a-40ca-b450-7e57507cdc06/lck.SHA256E-s814245--9dc6f1287ba683cae030e04ba7f94a73e566ce392c2d032f171094ddc342fa60.jpg: openFd: does not exist (No such file or directory)
+git-annex-shell: sendkey: 1 failed
+protocol version mismatch -- is your shell clean?
+(see the rsync man page for an explanation)
+rsync error: protocol incompatibility (code 2) at compat.c(176) [Receiver=3.1.1]
+
+  rsync failed -- run git annex again to resume file transfer
+
+  Unable to access these remotes: clusterhost
+
+  Try making some of these repositories available:
+  	809074b6-e079-4ea1-b2f8-2d7840deda7d -- zenbookhost
+   	a1ed6786-8b93-4a14-b00d-877b741e34da -- [clusterhost]
+failed
+```

Added a comment
diff --git a/doc/bugs/External_special_remote_SETURLPRESENT_doesn__39__t_seem_to_work/comment_7_f3c26c061fdc6dcd181f998c73450525._comment b/doc/bugs/External_special_remote_SETURLPRESENT_doesn__39__t_seem_to_work/comment_7_f3c26c061fdc6dcd181f998c73450525._comment
new file mode 100644
index 0000000..45130b4
--- /dev/null
+++ b/doc/bugs/External_special_remote_SETURLPRESENT_doesn__39__t_seem_to_work/comment_7_f3c26c061fdc6dcd181f998c73450525._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="bgilbert@a0c64716cf22216de5eeb15a5ca4f009164c8fb3"
+ nickname="bgilbert"
+ subject="comment 7"
+ date="2015-08-19T05:49:12Z"
+ content="""
+It seems that with encrypted remotes, `WHEREIS` passes the non-HMAC version of the `Key`.  Thus, the URL returned by the external special remote won't actually point to the remote object.  I'm not sure whether it's even useful to display URLs for encrypted files, but the current situation seems actively misleading.
+"""]]

Added a comment: design phase only
diff --git a/doc/design/requests_routing/comment_2_a409df0566b308bf2b84efd4fb2c8a8f._comment b/doc/design/requests_routing/comment_2_a409df0566b308bf2b84efd4fb2c8a8f._comment
new file mode 100644
index 0000000..d7bbaed
--- /dev/null
+++ b/doc/design/requests_routing/comment_2_a409df0566b308bf2b84efd4fb2c8a8f._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="https://id.koumbit.net/anarcat"
+ subject="design phase only"
+ date="2015-08-18T19:02:30Z"
+ content="""
+just to clarify: this is not implemented yet, as far as i know.
+"""]]

more details and questions
diff --git a/doc/forum/mesh_configurations.mdwn b/doc/forum/mesh_configurations.mdwn
index 3e02602..c3904f4 100644
--- a/doc/forum/mesh_configurations.mdwn
+++ b/doc/forum/mesh_configurations.mdwn
@@ -172,4 +172,10 @@ XX__ foo
 X___ quux
 </pre>
 
-why don't the files get copied over to the backup repo by the assistant? --[[anarcat]]
+why don't the files get copied over to the backup repo by the assistant?
+
+i somewhat understand that files don't get sent from `a` to `b`, but why doesn't the assistant copy the files from `b` to `c`?
+
+i have tried using `required` instead of `wanted` and it doesn't work much better.
+
+tested with `5.20150610+gitg608172f-1~ndall+1` (prod) and `5.20141125` (the above test). --[[anarcat]]

add the date this was added
diff --git a/doc/git-annex-required.mdwn b/doc/git-annex-required.mdwn
index 8239ac7..81bfd95 100644
--- a/doc/git-annex-required.mdwn
+++ b/doc/git-annex-required.mdwn
@@ -24,6 +24,10 @@ removed. For example a file that is `wanted` can be removed with `git
 annex drop`, but if that file is `required`, it would need to be
 removed with `git annex drop --force`.
 
+# NOTES
+
+The `required` command was added in git-annex 5.20150420.
+
 # SEE ALSO
 
 [[git-annex]](1)

weird dumb question maybe?
diff --git a/doc/forum/mesh_configurations.mdwn b/doc/forum/mesh_configurations.mdwn
new file mode 100644
index 0000000..3e02602
--- /dev/null
+++ b/doc/forum/mesh_configurations.mdwn
@@ -0,0 +1,175 @@
+I have a setup where a *source* repository `a` is connected to a *source* repository `b` (through SSH) which is then connected to  *backup* repository `c` (on amazon S3). I was expecting a file added on `a` to be moved to `c` *through* `b`, but that doesn't seem to be happening...
+
+I tried to reproduce with this basic setup:
+
+<pre>
+[1009]anarcat@angela:g-a$ git init a
+Dépôt Git vide initialisé dans /home/anarcat/test/g-a/a/.git/
+[1010]anarcat@angela:g-a$ git init b
+Dépôt Git vide initialisé dans /home/anarcat/test/g-a/b/.git/
+[1011]anarcat@angela:g-a$ git init c
+Dépôt Git vide initialisé dans /home/anarcat/test/g-a/c/.git/
+[1012]anarcat@angela:g-a$ cd a/
+[1013]anarcat@angela:a$ git annex init
+init  ok
+(Recording state in git...)
+[1014]anarcat@angela:a$ git annex group . source
+group . ok
+(Recording state in git...)
+[1015]anarcat@angela:a$ git annex wanted . groupwanted
+wanted . ok
+(Recording state in git...)
+[1036]anarcat@angela:a$ git remote add origin ../b
+[1016]anarcat@angela:a$ cd ../b
+[1025]anarcat@angela:b$ git annex init
+init  ok
+(Recording state in git...)
+[1026]anarcat@angela:b$ git annex group . source
+group . ok
+(Recording state in git...)
+[1027]anarcat@angela:b$ git annex wanted . groupwanted
+wanted . ok
+(Recording state in git...)
+[1038]anarcat@angela:b$ git remote add origin ../c
+[1019]anarcat@angela:b$ cd ../c
+[1021]anarcat@angela:c$ git annex init
+init  ok
+(Recording state in git...)
+[1022]anarcat@angela:c$ git annex group . backup
+group . ok
+(Recording state in git...)
+[1023]anarcat@angela:c$ git annex wanted . groupwanted
+wanted . ok
+(Recording state in git...)
+anarcat@angela:c$ cd ../a
+[1041]anarcat@angela:a$ git annex sync
+commit  ok
+pull origin
+warning: no common commits
+remote: Décompte des objets: 11, fait.
+remote: Compression des objets: 100% (9/9), fait.
+remote: Total 11 (delta 1), reused 0 (delta 0)
+Dépaquetage des objets: 100% (11/11), fait.
+Depuis ../b
+ * [nouvelle branche] git-annex  -> origin/git-annex
+
+merge: refs/remotes/origin/master - not something we can merge
+
+merge: refs/remotes/origin/synced/master - not something we can merge
+failed
+(merging origin/git-annex into git-annex...)
+(Recording state in git...)
+(Recording state in git...)
+git-annex: sync: 1 failed
+[1042]anarcat@angela:a1$ cd ../b
+[1043]anarcat@angela:b$ git annex sync
+commit  ok
+pull origin
+warning: no common commits
+remote: Décompte des objets: 11, fait.
+remote: Compression des objets: 100% (9/9), fait.
+remote: Total 11 (delta 1), reused 0 (delta 0)
+Dépaquetage des objets: 100% (11/11), fait.
+Depuis ../c
+ * [nouvelle branche] git-annex  -> origin/git-annex
+
+merge: refs/remotes/origin/master - not something we can merge
+
+merge: refs/remotes/origin/synced/master - not something we can merge
+failed
+(merging origin/git-annex into git-annex...)
+(Recording state in git...)
+(Recording state in git...)
+git-annex: sync: 1 failed
+[1063]anarcat@angela:b$ touch bar
+[1064]anarcat@angela:b$ ls
+bar
+[1065]anarcat@angela:b$ ls -al
+total 16K
+drwxr-xr-x 3 anarcat anarcat 4096 aoû 18 14:41 .
+drwxr-xr-x 5 anarcat anarcat 4096 aoû 18 14:33 ..
+lrwxrwxrwx 1 anarcat anarcat  178 aoû 18 14:41 bar -> .git/annex/objects/pX/ZJ/SHA256E-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855/SHA256E-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
+drwxr-xr-x 9 anarcat anarcat 4096 aoû 18 14:41 .git
+[1066]anarcat@angela:b$ git annex sync
+commit  ok
+pull origin
+ok
+push origin
+Décompte des objets: 26, fait.
+Delta compression using up to 2 threads.
+Compression des objets: 100% (22/22), fait.
+Écriture des objets: 100% (26/26), 2.47 KiB | 0 bytes/s, fait.
+Total 26 (delta 5), reused 0 (delta 0)
+To ../c
+ * [new branch]      git-annex -> synced/git-annex
+ * [new branch]      master -> synced/master
+ok
+[1067]anarcat@angela:b$ cd ../a
+[1068]anarcat@angela:a$ git annex sync
+commit  ok
+pull origin
+remote: Décompte des objets: 8, fait.
+remote: Compression des objets: 100% (6/6), fait.
+remote: Total 8 (delta 1), reused 0 (delta 0)
+Dépaquetage des objets: 100% (8/8), fait.
+Depuis ../b
+   5d3090f..9e345e6  git-annex  -> origin/git-annex
+ * [nouvelle branche] master     -> origin/master
+ * [nouvelle branche] synced/master -> origin/synced/master
+
+Merge made by the 'recursive' strategy.
+ bar | 1 +
+ 1 file changed, 1 insertion(+)
+ create mode 120000 bar
+
+Already up-to-date.
+ok
+(merging origin/git-annex into git-annex...)
+(Recording state in git...)
+(Recording state in git...)
+push origin
+Décompte des objets: 41, fait.
+Delta compression using up to 2 threads.
+Compression des objets: 100% (36/36), fait.
+Écriture des objets: 100% (41/41), 3.50 KiB | 0 bytes/s, fait.
+Total 41 (delta 20), reused 0 (delta 0)
+To ../b
+   6019ab8..368ca15  master -> synced/master
+ * [new branch]      git-annex -> synced/git-annex
+ok
+[1069]anarcat@angela:a$ touch quu^C
+[1069]anarcat@angela:a130$ echo foo > quux
+[1070]anarcat@angela:a$ cd ../b
+[1071]anarcat@angela:b$ ls
+bar  foo
+[1072]anarcat@angela:b$ cd ..
+[1073]anarcat@angela:g-a$ cd a
+[1074]anarcat@angela:a$ git annex list
+here
+|origin
+||web
+|||
+XX_ bar
+XX_ foo
+X__ quux
+[1075]anarcat@angela:a$ git annex list --help
+git-annex: unrecognized option `--help'
+
+Usage: git-annex list [PATH ...] [option ...]
+    --allrepos  show all repositories, not only remotes
+
+To see additional options common to all commands, run: git annex help options
+
+
+[1076]anarcat@angela:a1$ git annex list --allrepos
+here-
+|origin
+||web
+|||anarcat@angela:~/test/g-a/c
+||||
+XX__ bar
+XX__ foo
+X___ quux
+</pre>
+
+why don't the files get copied over to the backup repo by the assistant? --[[anarcat]]

add more related software
diff --git a/doc/not.mdwn b/doc/not.mdwn
index 949978c..6ef601e 100644
--- a/doc/not.mdwn
+++ b/doc/not.mdwn
@@ -14,6 +14,16 @@
   too slow, or its strict mirroring of everything to both places too
   limiting, then git-annex could be a useful alternative.
 
+* git-annex is also not a folder mirroring system like [syncthing](https://syncthing.net/) 
+  (although [syncthing could be supported as a special remote](todo/syncthing_special_remote/))
+  or [gut](https://github.com/tillberg/gut), but it can be used to sync
+  files such a way, with certain limitations (for example, it doesn't
+  like syncing `.git` directories so much).
+
+* git-annex is also not a distributed file system like Bittorrent or [ipfs](http://ipfs.io)
+  but both are supported as special remotes with more work in making 
+  [[git-annex more distributed underway|todo/Bittorrent-like_features/]].
+  
 * git-annex is more than just a workaround for git scalability 
   limitations that might eventually be fixed by efforts like
   [git-bigfiles](http://caca.zoy.org/wiki/git-bigfiles). In particular,
@@ -56,5 +66,5 @@
   Although mercurial and git have some of the same problems around large
   files, and both try to solve them in similar ways (standin files using
   mostly hashes of the real content).
-  
+
 See also the [[related_software]] page for software that git-annex *is* similar to.

link to not
diff --git a/doc/related_software.mdwn b/doc/related_software.mdwn
index a2d5cc8..0eb3c89 100644
--- a/doc/related_software.mdwn
+++ b/doc/related_software.mdwn
@@ -36,3 +36,5 @@ designed to interoperate with it.
 
 * [git-annex-watcher](https://github.com/rubiojr/git-annex-watcher)
   is a status icon for your desktop.
+
+See also [[not]] for software that is *not* related to git-annex, but similar.

like to related
diff --git a/doc/not.mdwn b/doc/not.mdwn
index 754da22..949978c 100644
--- a/doc/not.mdwn
+++ b/doc/not.mdwn
@@ -57,3 +57,4 @@
   files, and both try to solve them in similar ways (standin files using
   mostly hashes of the real content).
   
+See also the [[related_software]] page for software that git-annex *is* similar to.

Added a comment: link to the files
diff --git a/doc/forum/Searching_metadata_and_file_content__63__/comment_2_5dd29566dacb5ca70340d54b469c40a5._comment b/doc/forum/Searching_metadata_and_file_content__63__/comment_2_5dd29566dacb5ca70340d54b469c40a5._comment
new file mode 100644
index 0000000..9bd3c27
--- /dev/null
+++ b/doc/forum/Searching_metadata_and_file_content__63__/comment_2_5dd29566dacb5ca70340d54b469c40a5._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="konubinix"
+ subject="link to the files"
+ date="2015-08-18T13:37:12Z"
+ content="""
+The previous comment did not display the files correctly.
+
+[link the script to dump the tags](https://raw.githubusercontent.com/Konubinix/Devel/master/bin/konix_git-annex_dump_tags.sh)
+
+[link the fields file](https://raw.githubusercontent.com/Konubinix/Devel/master/config/recoll/fields)
+
+"""]]

Added a comment: recoll
diff --git a/doc/forum/Searching_metadata_and_file_content__63__/comment_1_25ac180194a59b659e0b02bb95dd26aa._comment b/doc/forum/Searching_metadata_and_file_content__63__/comment_1_25ac180194a59b659e0b02bb95dd26aa._comment
new file mode 100644
index 0000000..8b72cc5
--- /dev/null
+++ b/doc/forum/Searching_metadata_and_file_content__63__/comment_1_25ac180194a59b659e0b02bb95dd26aa._comment
@@ -0,0 +1,45 @@
+[[!comment format=mdwn
+ username="konubinix"
+ subject="recoll"
+ date="2015-08-18T13:30:21Z"
+ content="""
+I personally use recoll to do that. It is not perfect but works well.
+
+To extract the metadata, I use a script called git-annex_dump_tags.sh whose content is:
+	set -eu
+	FILE=\"${1}\"
+	DIR=\"$(dirname \"${FILE}\")\"
+	FILE_NO_DIR=\"$(basename \"${FILE}\")\"
+	cd \"${DIR}\"
+	git annex metadata \"${FILE_NO_DIR}\"|\
+	    tail -n+2|\
+	    head -n-1|\
+	    sed -r 's/^ +//'|\
+	    sed -r 's/^([^=]+)=(.+)$/\1 = \2/'
+
+Then in the recoll configuration, I added
+	[~/perso]
+	metadatacmds = ; rclmulti_gitannex = git-annex_dump_tags.sh %f
+
+More information can be found in [link the recoll manual](http://www.lesbonscomptes.com/recoll/usermanual/usermanual.html#RCL.INSTALL.CONFIG.RECOLLCONF).
+
+Then you'll have to indicate what key to use in the indexing by updating the \"fields\" file. For instance, you could add:
+	[prefixes]
+	ack = XYACK
+	year = XYMONTH
+	month = XYMONTH
+	day = XYDAY
+
+	[stored]
+	ack=
+	year=
+	month=
+	day=
+
+I generally use the ack metadata in my bibliography to indicate whether I read the paper or not (ack=no or ack=yes). I can get access to all the paper I did not read yet, that were added in August 2015, and that deal with gaussian processes with the query
+	recoll -t -q ack:no year:2015 month:8 gaussian processes
+
+It was not easy to setup, but it does the job.
+
+Hope that helps.
+"""]]

Added a comment: Not sure what is wrong... looks like `glacier` might be called wrongly.
diff --git a/doc/special_remotes/glacier/comment_10_c0e841c3e305712d960e43a10e674215._comment b/doc/special_remotes/glacier/comment_10_c0e841c3e305712d960e43a10e674215._comment
new file mode 100644
index 0000000..be2ef46
--- /dev/null
+++ b/doc/special_remotes/glacier/comment_10_c0e841c3e305712d960e43a10e674215._comment
@@ -0,0 +1,63 @@
+[[!comment format=mdwn
+ username="forbesmyester@2cec261fa984ee168bdbad63665c58953963c10e"
+ nickname="forbesmyester"
+ subject="Not sure what is wrong... looks like `glacier` might be called wrongly."
+ date="2015-08-18T07:42:38Z"
+ content="""
+Have done a full setup as much as I can, with all the GPG / AWS stuff but it keeps doing non stop...
+
+    copy 201/2011/05/20/P1010044.RW2 (checking familypictures-glacier...) [2015-08-18 08:37:05 BST] read: glacier [\"--region=us-east-1\",\"archive\",\"checkpresent\",\"familypictures\",\"--quiet\",\"GPGHMACSHA1--[SOME_HASH]\"]
+    (to familypictures-glacier...) 
+    [2015-08-18 08:37:05 BST] feed: glacier [\"--region=us-east-1\",\"archive\",\"upload\",\"--name\",\"GPGHMACSHA1--[SOME_HASH]\",\"familypictures\",\"-\"]
+    [2015-08-18 08:37:05 BST] chat: gpg [\"--quiet\",\"--trust-model\",\"always\",\"--batch\",\"--passphrase-fd\",\"40\",\"--symmetric\",\"--force-mdc\",\"--no-textmode\"]
+    0%            0.0 B/s 0s
+    glacier <command> [args]
+    
+        Commands
+            vaults    - Operations with vaults
+            jobs      - Operations with jobs
+            upload    - Upload files to a vault. If the vault doesn't exits, it is
+                        created
+    
+        Common args:
+            --access_key - Your AWS Access Key ID.  If not supplied, boto will
+                           use the value of the environment variable
+                           AWS_ACCESS_KEY_ID
+            --secret_key - Your AWS Secret Access Key.  If not supplied, boto
+                           will use the value of the environment variable
+                           AWS_SECRET_ACCESS_KEY
+            --region     - AWS region to use. Possible values: us-east-1, us-west-1,
+                           us-west-2, ap-northeast-1, eu-west-1.
+                           Default: us-east-1
+    
+        Vaults operations:
+    
+            List vaults:
+                glacier vaults 
+    
+        Jobs operations:
+    
+            List jobs:
+                glacier jobs <vault name>
+    
+        Uploading files:
+    
+            glacier upload <vault name> <files>
+    
+            Examples : 
+                glacier upload pics *.jpg
+                glacier upload pics a.jpg b.jpg
+    
+    gpg: [stdout]: write error: Broken pipe
+    gpg: DBG: deflate: iobuf_write failed
+    gpg: build_packet failed: file write error
+    gpg: [stdout]: write error: Broken pipe
+    gpg: iobuf_flush failed on close: file write error
+    gpg: [stdout]: write error: Broken pipe
+    gpg: iobuf_flush failed on close: file write error
+    gpg: symmetric encryption of `[stdin]' failed: file write error
+    git-annex: fd:46: hPutBuf: resource vanished (Broken pipe)
+    failed
+    
+
+"""]]

Added a comment
diff --git a/doc/bugs/External_special_remote_SETURLPRESENT_doesn__39__t_seem_to_work/comment_6_34aecee25295477c51650ece94fda113._comment b/doc/bugs/External_special_remote_SETURLPRESENT_doesn__39__t_seem_to_work/comment_6_34aecee25295477c51650ece94fda113._comment
new file mode 100644
index 0000000..39e4477
--- /dev/null
+++ b/doc/bugs/External_special_remote_SETURLPRESENT_doesn__39__t_seem_to_work/comment_6_34aecee25295477c51650ece94fda113._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="bgilbert@a0c64716cf22216de5eeb15a5ca4f009164c8fb3"
+ nickname="bgilbert"
+ subject="comment 6"
+ date="2015-08-18T06:13:28Z"
+ content="""
+`readonly` seems to work in my early tests.  Thanks for doing that.
+
+For consistency, shouldn't it be `readonly=yes` rather than `readonly=true`?
+"""]]

Added a comment: Never mind
diff --git a/doc/bugs/copy_to_--fast_should_not_mention_every_file_it_checks/comment_4_b1cefd6259ecce0bd154c509825fb17a._comment b/doc/bugs/copy_to_--fast_should_not_mention_every_file_it_checks/comment_4_b1cefd6259ecce0bd154c509825fb17a._comment
new file mode 100644
index 0000000..265b749
--- /dev/null
+++ b/doc/bugs/copy_to_--fast_should_not_mention_every_file_it_checks/comment_4_b1cefd6259ecce0bd154c509825fb17a._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="jason@bbebec708d192ae9848ef6d0c6983e2b37127df1"
+ nickname="jason"
+ subject="Never mind"
+ date="2015-08-17T18:00:06Z"
+ content="""
+I'm writing again to confirm that this has been fixed.
+
+I assume it was due to a short-lived release bug that accidentally removed some copy options.
+"""]]

done
diff --git a/doc/bugs/External_special_remote_SETURLPRESENT_doesn__39__t_seem_to_work.mdwn b/doc/bugs/External_special_remote_SETURLPRESENT_doesn__39__t_seem_to_work.mdwn
index 186382f..ee007b3 100644
--- a/doc/bugs/External_special_remote_SETURLPRESENT_doesn__39__t_seem_to_work.mdwn
+++ b/doc/bugs/External_special_remote_SETURLPRESENT_doesn__39__t_seem_to_work.mdwn
@@ -141,3 +141,5 @@ get sample.jpg (not available)
 failed
 git-annex: get: 1 failed
 """]]
+
+> [[fixed|done]] --[[Joey]] 
diff --git a/doc/bugs/External_special_remote_SETURLPRESENT_doesn__39__t_seem_to_work/comment_5_5cd42f34ccdb665193960abb6e6248a1._comment b/doc/bugs/External_special_remote_SETURLPRESENT_doesn__39__t_seem_to_work/comment_5_5cd42f34ccdb665193960abb6e6248a1._comment
new file mode 100644
index 0000000..4574856
--- /dev/null
+++ b/doc/bugs/External_special_remote_SETURLPRESENT_doesn__39__t_seem_to_work/comment_5_5cd42f34ccdb665193960abb6e6248a1._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2015-08-17T15:36:49Z"
+ content="""
+I've gone ahead and implemented my last comment, see
+<http://git-annex.branchable.com/design/external_special_remote_protocol/#index9h2>
+"""]]

Added a comment: @niklaas
diff --git a/doc/assistant/comment_7_831a529c92951f70a27721210204e46b._comment b/doc/assistant/comment_7_831a529c92951f70a27721210204e46b._comment
new file mode 100644
index 0000000..deaf693
--- /dev/null
+++ b/doc/assistant/comment_7_831a529c92951f70a27721210204e46b._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="https://woid.cryptobitch.de/foobar"
+ subject="@niklaas"
+ date="2015-08-17T13:42:26Z"
+ content="""
+Joey Hess is using xmonad.
+"""]]

Added a comment: buprepo doesn't work properly
diff --git a/doc/special_remotes/bup/comment_13_ce960bc69b27dfc2a233c9baa5b2cd2b._comment b/doc/special_remotes/bup/comment_13_ce960bc69b27dfc2a233c9baa5b2cd2b._comment
new file mode 100644
index 0000000..e17e42c
--- /dev/null
+++ b/doc/special_remotes/bup/comment_13_ce960bc69b27dfc2a233c9baa5b2cd2b._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="darkfeline@e6d098788a13ce41f3141a2dfc1bd31b401e83f0"
+ nickname="darkfeline"
+ subject="buprepo doesn't work properly"
+ date="2015-08-17T12:59:25Z"
+ content="""
+The buprepo parameter doesn't seem to work properly, at least for local repos.  For example, I added a bup remote with buprepo=/media/hdd/bup, yet when I try to move files onto it, it still tries to use /home/foo/.bup (the default path).  I suppose git-annex should be setting the envvar BUP_DIR before calling bup?
+
+I can do it manually like BUP_DIR=/media/hdd/bup git annex move --to hdd foo, but that almost seems to defeat the purpose...
+"""]]

Added a comment
diff --git a/doc/bugs/UnicodeDecodeError_while_archiving_files_with_git-annex_to_glacier/comment_2_f0f1f18265ebb83caf4e6f1fb23ec876._comment b/doc/bugs/UnicodeDecodeError_while_archiving_files_with_git-annex_to_glacier/comment_2_f0f1f18265ebb83caf4e6f1fb23ec876._comment
new file mode 100644
index 0000000..c288b02
--- /dev/null
+++ b/doc/bugs/UnicodeDecodeError_while_archiving_files_with_git-annex_to_glacier/comment_2_f0f1f18265ebb83caf4e6f1fb23ec876._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="mhubig"
+ subject="comment 2"
+ date="2015-08-17T11:44:40Z"
+ content="""
+Yes it's a glacier.cli related bug ... maybe git-annex should use boto3 for glacier support ...
+"""]]

Added a comment
diff --git a/doc/bugs/MacOSX:_archive_folders_not_working_as_expected/comment_1_c8ce2a1978fc1bfa5f31cff9f48690f6._comment b/doc/bugs/MacOSX:_archive_folders_not_working_as_expected/comment_1_c8ce2a1978fc1bfa5f31cff9f48690f6._comment
new file mode 100644
index 0000000..d1380f1
--- /dev/null
+++ b/doc/bugs/MacOSX:_archive_folders_not_working_as_expected/comment_1_c8ce2a1978fc1bfa5f31cff9f48690f6._comment
@@ -0,0 +1,57 @@
+[[!comment format=mdwn
+ username="mhubig"
+ subject="comment 1"
+ date="2015-08-17T11:42:18Z"
+ content="""
+Here's some more infos from running git-annex with debug:
+
+Moving a 'symlinked' file from `~/annex/archive` to `~/annex`. I expected that the file get's automagically pulled from the archive drive and the symlink is replaced with the real file.
+but what happens is this:
+
+[[!format sh \"\"\"
+[2015-08-17 13:29:48 CEST] Watcher: file deleted /Users/markus/annex/archive/Crisi\'s Trail und Stubenfelsen Jam.gpx
+[2015-08-17 13:29:48 CEST] Committer: committing 1 changes
+[2015-08-17 13:29:48 CEST] Committer: Committing changes to git
+(recording state in git...)
+[2015-08-17 13:29:48 CEST] feed: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"update-index\",\"-z\",\"--index-info\"]
+[2015-08-17 13:29:48 CEST] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"symbolic-ref\",\"-q\",\"HEAD\"]
+[2015-08-17 13:29:48 CEST] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"show-ref\",\"--hash\",\"refs/heads/annex/direct/master\"]
+[2015-08-17 13:29:48 CEST] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"write-tree\"]
+[2015-08-17 13:29:48 CEST] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"rev-parse\",\"df537468c185961a9785d9288d00b0bc5f628a28:\"]
+[2015-08-17 13:29:48 CEST] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"commit-tree\",\"be3e4a4a4477d6a1aad9fcbd333b43d84295e9b6\",\"--no-gpg-sign\",\"-p\",\"df537468c185961a9785d9288d00b0bc5f628a28\"]
+[2015-08-17 13:29:48 CEST] call: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"update-ref\",\"refs/heads/annex/direct/master\",\"3436556450500cf342154e9b03bfd1825402f5eb\"]
+[2015-08-17 13:29:48 CEST] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"symbolic-ref\",\"-q\",\"HEAD\"]
+[2015-08-17 13:29:48 CEST] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"show-ref\",\"refs/heads/annex/direct/master\"]
+[2015-08-17 13:29:48 CEST] call: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"branch\",\"-f\",\"synced/master\"]
+[2015-08-17 13:29:48 CEST] call: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"branch\",\"-f\",\"master\"]
+[2015-08-17 13:29:48 CEST] Pusher: Syncing with annexbackup, annexarchive
+[2015-08-17 13:29:48 CEST] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"symbolic-ref\",\"-q\",\"HEAD\"]
+[2015-08-17 13:29:48 CEST] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"show-ref\",\"refs/heads/annex/direct/master\"]
+[2015-08-17 13:29:48 CEST] Pusher: pushing to [Remote { name =\"annexbackup\" },Remote { name =\"annexarchive\" }]
+[2015-08-17 13:29:48 CEST] call: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"push\",\"annexbackup\",\"+git-annex:synced/git-annex\",\"annex/direct/master:synced/master\"]
+[2015-08-17 13:29:48 CEST] call: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"push\",\"annexarchive\",\"+git-annex:synced/git-annex\",\"annex/direct/master:synced/master\"]
+To /Volumes/annex-archive/annex-archive
+   df53746..3436556  annex/direct/master -> synced/master
+[2015-08-17 13:29:48 CEST] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"push\",\"annexarchive\",\"git-annex\",\"master\"]
+To /Volumes/annex-backup/annex-backup
+   464ebc5..2413398  git-annex -> synced/git-annex
+   df53746..3436556  annex/direct/master -> synced/master
+[2015-08-17 13:29:48 CEST] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"push\",\"annexbackup\",\"git-annex\",\"master\"]
+[2015-08-17 13:29:49 CEST] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"symbolic-ref\",\"-q\",\"HEAD\"]
+[2015-08-17 13:29:49 CEST] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"show-ref\",\"refs/heads/annex/direct/master\"]
+[2015-08-17 13:29:49 CEST] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"log\",\"refs/heads/annex/direct/master..refs/heads/synced/master\",\"-n1\",\"--pretty=%H\"]
+[2015-08-17 13:29:49 CEST] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"symbolic-ref\",\"-q\",\"HEAD\"]
+[2015-08-17 13:29:49 CEST] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"show-ref\",\"refs/heads/annex/direct/master\"]
+[2015-08-17 13:29:49 CEST] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"log\",\"refs/heads/annex/direct/master..refs/remotes/annexarchive/synced/master\",\"-n1\",\"--pretty=%H\"]
+[2015-08-17 13:29:49 CEST] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"show-ref\",\"git-annex\"]
+[2015-08-17 13:29:49 CEST] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"show-ref\",\"--hash\",\"refs/heads/git-annex\"]
+[2015-08-17 13:29:49 CEST] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"log\",\"refs/heads/git-annex..24133980364c5ae86e939c214deea1b6ab63135c\",\"-n1\",\"--pretty=%H\"]
+[2015-08-17 13:29:49 CEST] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"log\",\"refs/heads/git-annex..d42c35efe8b1333930587a41aec8744aa0e90ae3\",\"-n1\",\"--pretty=%H\"]
+[2015-08-17 13:29:49 CEST] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"log\",\"refs/heads/git-annex..796db681152a16121be271668d5f79c845e24b8c\",\"-n1\",\"--pretty=%H\"]
+[2015-08-17 13:29:49 CEST] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"ls-tree\",\"--full-tree\",\"-z\",\"--\",\"refs/heads/git-annex\",\"uuid.log\",\"remote.log\",\"trust.log\",\"group.log\",\"numcopies.log\",\"schedule.log\",\"preferred-content.log\",\"required-content.log\",\"group-preferred-content.log\"]
+[2015-08-17 13:29:49 CEST] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"symbolic-ref\",\"-q\",\"HEAD\"]
+[2015-08-17 13:29:49 CEST] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"show-ref\",\"refs/heads/annex/direct/master\"]
+[2015-08-17 13:29:49 CEST] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"log\",\"refs/heads/annex/direct/master..refs/remotes/annexbackup/synced/master\",\"-n1\",\"--pretty=%H\"]
+\"\"\"]]
+ 
+"""]]

diff --git a/doc/bugs/decides_that_FS_is_crippled_under_cowbuilder___40__symlinks_supported_etc__41__.mdwn b/doc/bugs/decides_that_FS_is_crippled_under_cowbuilder___40__symlinks_supported_etc__41__.mdwn
new file mode 100644
index 0000000..68f9865
--- /dev/null
+++ b/doc/bugs/decides_that_FS_is_crippled_under_cowbuilder___40__symlinks_supported_etc__41__.mdwn
@@ -0,0 +1,43 @@
+### Please describe the problem.
+
+Was trying to create a prelim package for datalad but unittests failed.  Apparently under cowbuilder (I guess it is the culprit) annex decides that the filesystem is crippled.  Looking at the code, annex does two tests:
+
+1. either it can create a symlink (which it should be able to -- I can create symlinks no problem there)
+2. either it can't write to a file with write permissions removed
+
+But that is where I am getting confused ;) since it seems that I can write to a file, when write permissions were removed, if I am root (that is how package is built in that chroot):
+
+[[!format sh """
+root@hopa:/tmp# echo 123 > 123; chmod a-w 123;  echo "add" >> 123;
+root@hopa:/tmp# echo $?
+0
+root@hopa:/tmp# cat 123
+123
+add
+root@hopa:/tmp# ls -ld 123
+-r-------- 1 root root 8 Aug 17 07:32 123
+root@hopa:/tmp# python -c 'open("123", "w")'
+root@hopa:/tmp# python -c 'open("123", "w").write("asdf")'
+root@hopa:/tmp# cat 123
+asdfroot@hopa:/tmp# 
+
+"""]]
+
+but annex doesn't detect file system as crippled when merely in a root session.  So I guess there is something more to it (cowbuilder?)
+
+### What steps will reproduce the problem?
+
+
+### What version of git-annex are you using? On what operating system?
+
+Debian sid   5.20150812-2
+
+### Please provide any additional information below.
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+
+
+# End of transcript or log.
+"""]]

Added a comment: great!
diff --git a/doc/todo/speed_up_transfers_over_ssh+rsync_--_directly_reuse_the_same_connection__63__/comment_8_0209467fbfb83b4b5aace9767179b7ab._comment b/doc/todo/speed_up_transfers_over_ssh+rsync_--_directly_reuse_the_same_connection__63__/comment_8_0209467fbfb83b4b5aace9767179b7ab._comment
new file mode 100644
index 0000000..a3175b2
--- /dev/null
+++ b/doc/todo/speed_up_transfers_over_ssh+rsync_--_directly_reuse_the_same_connection__63__/comment_8_0209467fbfb83b4b5aace9767179b7ab._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="anarcat"
+ subject="great!"
+ date="2015-08-17T04:07:28Z"
+ content="""
+it's great to see such improvements! i was wondering if git-annex was slower than an equivalent rsync transfer... 
+
+how does git-annex compare with rsync now?
+
+how should we decide how many -J we should use? are there good heuristics on that?
+
+should this todo be marked as done?
+"""]]

rename forum_/_Searching_metadata_and_file_content__63__.mdwn to forum/Searching_metadata_and_file_content__63__.mdwn
diff --git a/doc/forum/Searching_metadata_and_file_content__63__.mdwn b/doc/forum/Searching_metadata_and_file_content__63__.mdwn
new file mode 100644
index 0000000..c13ff36
--- /dev/null
+++ b/doc/forum/Searching_metadata_and_file_content__63__.mdwn
@@ -0,0 +1,11 @@
+Hi
+
+Is there any (built-in or otherwise) way to search git-annex metadata and file content?  Ideally I think something that knows about git-annex would be helpful because of files moving around / going away due to metadata driven views, dangling symlinks etc.
+
+I'm imagining:
+
+* Something based on Lucene (solr/elasticsearch) or Xapian for fast searches
+* Probably ideally using git-annex metadata to track which files move where on disk
+* Maybe use of inotify to let it know when git annex has moved file content around or added/removed it from a working tree
+
+Thanks everybody, and Joey for making git annex and being an inspiration
diff --git a/doc/forum_/_Searching_metadata_and_file_content__63__.mdwn b/doc/forum_/_Searching_metadata_and_file_content__63__.mdwn
deleted file mode 100644
index c13ff36..0000000
--- a/doc/forum_/_Searching_metadata_and_file_content__63__.mdwn
+++ /dev/null
@@ -1,11 +0,0 @@
-Hi
-
-Is there any (built-in or otherwise) way to search git-annex metadata and file content?  Ideally I think something that knows about git-annex would be helpful because of files moving around / going away due to metadata driven views, dangling symlinks etc.
-
-I'm imagining:
-
-* Something based on Lucene (solr/elasticsearch) or Xapian for fast searches
-* Probably ideally using git-annex metadata to track which files move where on disk
-* Maybe use of inotify to let it know when git annex has moved file content around or added/removed it from a working tree
-
-Thanks everybody, and Joey for making git annex and being an inspiration

rename forum/_creating_Searching_metadata_and_file_content__63__.mdwn to forum_/_Searching_metadata_and_file_content__63__.mdwn
diff --git a/doc/forum/_creating_Searching_metadata_and_file_content__63__.mdwn b/doc/forum/_creating_Searching_metadata_and_file_content__63__.mdwn
deleted file mode 100644
index c13ff36..0000000
--- a/doc/forum/_creating_Searching_metadata_and_file_content__63__.mdwn
+++ /dev/null
@@ -1,11 +0,0 @@
-Hi
-
-Is there any (built-in or otherwise) way to search git-annex metadata and file content?  Ideally I think something that knows about git-annex would be helpful because of files moving around / going away due to metadata driven views, dangling symlinks etc.
-
-I'm imagining:
-
-* Something based on Lucene (solr/elasticsearch) or Xapian for fast searches
-* Probably ideally using git-annex metadata to track which files move where on disk
-* Maybe use of inotify to let it know when git annex has moved file content around or added/removed it from a working tree
-
-Thanks everybody, and Joey for making git annex and being an inspiration
diff --git a/doc/forum_/_Searching_metadata_and_file_content__63__.mdwn b/doc/forum_/_Searching_metadata_and_file_content__63__.mdwn
new file mode 100644
index 0000000..c13ff36
--- /dev/null
+++ b/doc/forum_/_Searching_metadata_and_file_content__63__.mdwn
@@ -0,0 +1,11 @@
+Hi
+
+Is there any (built-in or otherwise) way to search git-annex metadata and file content?  Ideally I think something that knows about git-annex would be helpful because of files moving around / going away due to metadata driven views, dangling symlinks etc.
+
+I'm imagining:
+
+* Something based on Lucene (solr/elasticsearch) or Xapian for fast searches
+* Probably ideally using git-annex metadata to track which files move where on disk
+* Maybe use of inotify to let it know when git annex has moved file content around or added/removed it from a working tree
+
+Thanks everybody, and Joey for making git annex and being an inspiration

diff --git a/doc/forum/_creating_Searching_metadata_and_file_content__63__.mdwn b/doc/forum/_creating_Searching_metadata_and_file_content__63__.mdwn
new file mode 100644
index 0000000..c13ff36
--- /dev/null
+++ b/doc/forum/_creating_Searching_metadata_and_file_content__63__.mdwn
@@ -0,0 +1,11 @@
+Hi
+
+Is there any (built-in or otherwise) way to search git-annex metadata and file content?  Ideally I think something that knows about git-annex would be helpful because of files moving around / going away due to metadata driven views, dangling symlinks etc.
+
+I'm imagining:
+
+* Something based on Lucene (solr/elasticsearch) or Xapian for fast searches
+* Probably ideally using git-annex metadata to track which files move where on disk
+* Maybe use of inotify to let it know when git annex has moved file content around or added/removed it from a working tree
+
+Thanks everybody, and Joey for making git annex and being an inspiration

Added a comment: git-new-workdir
diff --git a/doc/forum/checkout_view_to_directory_outside_of_annex/comment_3_2139407a3a556023a2458148a4a2c009._comment b/doc/forum/checkout_view_to_directory_outside_of_annex/comment_3_2139407a3a556023a2458148a4a2c009._comment
new file mode 100644
index 0000000..b6e48b4
--- /dev/null
+++ b/doc/forum/checkout_view_to_directory_outside_of_annex/comment_3_2139407a3a556023a2458148a4a2c009._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="konubinix"
+ subject="git-new-workdir"
+ date="2015-08-15T12:48:30Z"
+ content="""
+I am not sure whether it would help, but to show views of my git-annex repositories without messing with the current working directory, I generally use git-new-workdir
+https://github.com/git/git/blob/master/contrib/workdir/git-new-workdir
+
+It allows to checkout a separate branch in another directory. The new directory's .git directory contains symbolic links to the parent one, making sure that changes in the new work dir are propagated to the parent one.
+
+Hope that helps.
+"""]]

Fix formatting of shell output
diff --git a/doc/bugs/importfeed_--relaxed_fails_with_HEAD-rejecting_servers.mdwn b/doc/bugs/importfeed_--relaxed_fails_with_HEAD-rejecting_servers.mdwn
index 6b017bf..5a52af3 100644
--- a/doc/bugs/importfeed_--relaxed_fails_with_HEAD-rejecting_servers.mdwn
+++ b/doc/bugs/importfeed_--relaxed_fails_with_HEAD-rejecting_servers.mdwn
@@ -4,10 +4,10 @@ Calling "git annex importfeed --relaxed" on a url of a BBC podcast
 fails just like a "git annex addurl --fast" (and not relaxed) on the
 url of a show:
 
-addurl open.live.bbc.co.uk_mediaselector_5_redir_version_2.0_mediaset_audio_nondrm_download_proto_http_vpid_p02y8kfc.mp3 
-  unable to access url: http://open.live.bbc.co.uk/mediaselector/5/redir/version/2.0/mediaset/audio-nondrm-download/proto/http/vpid/p02y8kfc.mp3
-failed
-git-annex: addurl: 1 failed
+    addurl open.live.bbc.co.uk_mediaselector_5_redir_version_2.0_mediaset_audio_nondrm_download_proto_http_vpid_p02y8kfc.mp3 
+      unable to access url: http://open.live.bbc.co.uk/mediaselector/5/redir/version/2.0/mediaset/audio-nondrm-download/proto/http/vpid/p02y8kfc.mp3
+    failed
+    git-annex: addurl: 1 failed
 
 I suppose that is because HEAD on that same URL returns 403 Forbidden
 (addurl without fast works just fine).
@@ -19,16 +19,16 @@ I suppose that is because HEAD on that same URL returns 403 Forbidden
 
 I ran into this bug trying to importfeed various BBC podcasts. For instance:
 
-$ git annex importfeed --relaxed 'http://www.bbc.co.uk/programmes/p02pc9x6/episodes/downloads.rss'
-(checking known urls...)
-importfeed http://www.bbc.co.uk/programmes/p02pc9x6/episodes/downloads.rss 
-/tmp/feed3947                   100%[=======================================================>]   8,39K  --.-KB/s   en 0,007s 
-addurl Comedy_of_the_Week/In_and_Out_of_the_Kitchen__Episode_1__The_Supplement.mp3 
-  unable to access url: http://open.live.bbc.co.uk/mediaselector/5/redir/version/2.0/mediaset/audio-nondrm-download/proto/http/vpid/p02yy1hn.mp3
-failed
+    $ git annex importfeed --relaxed 'http://www.bbc.co.uk/programmes/p02pc9x6/episodes/downloads.rss'
+    (checking known urls...)
+    importfeed http://www.bbc.co.uk/programmes/p02pc9x6/episodes/downloads.rss 
+    /tmp/feed3947                   100%[=======================================================>]   8,39K  --.-KB/s   en 0,007s 
+    addurl Comedy_of_the_Week/In_and_Out_of_the_Kitchen__Episode_1__The_Supplement.mp3 
+      unable to access url: http://open.live.bbc.co.uk/mediaselector/5/redir/version/2.0/mediaset/audio-nondrm-download/proto/http/vpid/p02yy1hn.mp3
+    failed
 
-  warning: problem downloading item
-ok
+      warning: problem downloading item
+    ok
 
 
 ### What version of git-annex are you using? On what operating system?

diff --git a/doc/bugs/importfeed_--relaxed_fails_with_HEAD-rejecting_servers.mdwn b/doc/bugs/importfeed_--relaxed_fails_with_HEAD-rejecting_servers.mdwn
new file mode 100644
index 0000000..6b017bf
--- /dev/null
+++ b/doc/bugs/importfeed_--relaxed_fails_with_HEAD-rejecting_servers.mdwn
@@ -0,0 +1,36 @@
+### Please describe the problem.
+
+Calling "git annex importfeed --relaxed" on a url of a BBC podcast
+fails just like a "git annex addurl --fast" (and not relaxed) on the
+url of a show:
+
+addurl open.live.bbc.co.uk_mediaselector_5_redir_version_2.0_mediaset_audio_nondrm_download_proto_http_vpid_p02y8kfc.mp3 
+  unable to access url: http://open.live.bbc.co.uk/mediaselector/5/redir/version/2.0/mediaset/audio-nondrm-download/proto/http/vpid/p02y8kfc.mp3
+failed
+git-annex: addurl: 1 failed
+
+I suppose that is because HEAD on that same URL returns 403 Forbidden
+(addurl without fast works just fine).
+
+"git annex addurl --relaxed" works on the given url.
+
+
+### What steps will reproduce the problem?
+
+I ran into this bug trying to importfeed various BBC podcasts. For instance:
+
+$ git annex importfeed --relaxed 'http://www.bbc.co.uk/programmes/p02pc9x6/episodes/downloads.rss'
+(checking known urls...)
+importfeed http://www.bbc.co.uk/programmes/p02pc9x6/episodes/downloads.rss 
+/tmp/feed3947                   100%[=======================================================>]   8,39K  --.-KB/s   en 0,007s 
+addurl Comedy_of_the_Week/In_and_Out_of_the_Kitchen__Episode_1__The_Supplement.mp3 
+  unable to access url: http://open.live.bbc.co.uk/mediaselector/5/redir/version/2.0/mediaset/audio-nondrm-download/proto/http/vpid/p02yy1hn.mp3
+failed
+
+  warning: problem downloading item
+ok
+
+
+### What version of git-annex are you using? On what operating system?
+
+git-annex version: 5.20150731-1 on a quite up-to-date debian unstable.