Recent changes to this wiki:

diff --git a/doc/bugs/webapp_missing_in_20150522_release.mdwn b/doc/bugs/webapp_missing_in_20150522_release.mdwn
new file mode 100644
index 0000000..4c96ed6
--- /dev/null
+++ b/doc/bugs/webapp_missing_in_20150522_release.mdwn
@@ -0,0 +1,34 @@
+### Please describe the problem.
+
+Using the prebuilt linux tarball, version 20150522 fails to start the webapp.
+
+Doing it manually from the console, just gives me the help text. 
+
+Trying out an older version shows me the webapp option below "watch" in the help, but this is missing in 20150522 version.
+
+git-annex version gives me:
+
+    git-annex version: 5.20150522-gb199d65
+    build flags: Assistant Pairing Testsuite S3 WebDAV Inotify DBus DesktopNotify XMPP DNS Feeds Quvi TDFA
+    key/value backends: SHA256E SHA1E SHA512E SHA224E SHA384E SKEIN256E SKEIN512E MD5E SHA256 SHA1 SHA512 SHA224 SHA384 SKEIN256 SKEIN512 MD5 WORM URL
+    remote types: git gcrypt S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external
+
+### What steps will reproduce the problem?
+
+Use 20150522 version of git annex
+
+### What version of git-annex are you using? On what operating system?
+
+linux tarball, version 20150522
+
+Arch linux
+
+### 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: --depth undo option
diff --git a/doc/direct_mode/comment_17_e7c066fba8e28c61e8517c7a18a02457._comment b/doc/direct_mode/comment_17_e7c066fba8e28c61e8517c7a18a02457._comment
new file mode 100644
index 0000000..6847c5f
--- /dev/null
+++ b/doc/direct_mode/comment_17_e7c066fba8e28c61e8517c7a18a02457._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="mitzip"
+ subject="--depth undo option"
+ date="2015-05-27T02:54:17Z"
+ content="""
+Well I just spent 4 hours building a OSX GUI around git annex undo --depth and it responds with \"git-annex: unrecognized option '--depth'\"... lol Please tell me that option exists somewhere other than the documentation... lol
+"""]]

cracked it
diff --git a/doc/bugs/windows_ssh_webapp_password_entry_broken/comment_2_c0020f6bfb1690ae14560bc5ac791695._comment b/doc/bugs/windows_ssh_webapp_password_entry_broken/comment_2_c0020f6bfb1690ae14560bc5ac791695._comment
new file mode 100644
index 0000000..558a388
--- /dev/null
+++ b/doc/bugs/windows_ssh_webapp_password_entry_broken/comment_2_c0020f6bfb1690ae14560bc5ac791695._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2015-05-26T23:24:41Z"
+ content="""
+I hacked `process` to set both `DETACHED_PROCESS` and `CREATE_NO_WINDOW`,
+and this solved it!
+
+However, this will need changes to `process` (or a lot of code duplication).
+
+Filed feature request: <https://github.com/haskell/process/issues/32>
+"""]]

stumped
diff --git a/doc/bugs/windows_ssh_webapp_password_entry_broken/comment_1_efe3225766e0ef010534e77f1d073541._comment b/doc/bugs/windows_ssh_webapp_password_entry_broken/comment_1_efe3225766e0ef010534e77f1d073541._comment
new file mode 100644
index 0000000..8941daa
--- /dev/null
+++ b/doc/bugs/windows_ssh_webapp_password_entry_broken/comment_1_efe3225766e0ef010534e77f1d073541._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-05-26T20:28:42Z"
+ content="""
+Had a closer look at this, and I'm stumped. The ssh.exe from msysgit seems
+to be built with `SSH_ASKPASS` support, based on strings. But, I cannot seem
+to get it to use it.
+
+OTOH, the ssh from cygwin did support this. Just had other problems so it's
+not being used any longer.
+
+At a guess, from reading ssh's code, I might need to find a way to defeat
+ssh's isatty check on windows.
+
+<http://stackoverflow.com/questions/10960269/git-ssh-askpass-on-windows>
+hints that there might be a way to start the process "with CreateProcess()
+dwCreationFlags DETACHED_PROCESS" to make it work.
+"""]]

removed
diff --git a/doc/forum/Git_annex_hangs/comment_7_c22ffebedc9b1c1c74fc3f2f933971d3._comment b/doc/forum/Git_annex_hangs/comment_7_c22ffebedc9b1c1c74fc3f2f933971d3._comment
deleted file mode 100644
index 3e70f1a..0000000
--- a/doc/forum/Git_annex_hangs/comment_7_c22ffebedc9b1c1c74fc3f2f933971d3._comment
+++ /dev/null
@@ -1,8 +0,0 @@
-[[!comment format=mdwn
- username="https://me.yahoo.com/a/yx5Y6EI1t.759Jsu63ZWqYclCmpOmxxd.ramtw--#7114a"
- nickname="Ioanas"
- subject="Same issue here "
- date="2015-05-26T17:13:13Z"
- content="""
-I am also experiencing the same issue. How do I solve this? Re-installing git and git-annex (as some linked GitHub thread suggested) did not help.
-"""]]

removed
diff --git a/doc/forum/Git_annex_hangs/comment_8_94dc2b8386a8286690292343bf3c89b3._comment b/doc/forum/Git_annex_hangs/comment_8_94dc2b8386a8286690292343bf3c89b3._comment
deleted file mode 100644
index 1a855e6..0000000
--- a/doc/forum/Git_annex_hangs/comment_8_94dc2b8386a8286690292343bf3c89b3._comment
+++ /dev/null
@@ -1,8 +0,0 @@
-[[!comment format=mdwn
- username="https://me.yahoo.com/a/yx5Y6EI1t.759Jsu63ZWqYclCmpOmxxd.ramtw--#7114a"
- nickname="Ioanas"
- subject="Same issue here "
- date="2015-05-26T17:13:28Z"
- content="""
-I am also experiencing the same issue. How do I solve this? Re-installing git and git-annex (as some linked GitHub thread suggested) did not help.
-"""]]

Added a comment: Same issue here
diff --git a/doc/forum/Git_annex_hangs/comment_8_94dc2b8386a8286690292343bf3c89b3._comment b/doc/forum/Git_annex_hangs/comment_8_94dc2b8386a8286690292343bf3c89b3._comment
new file mode 100644
index 0000000..1a855e6
--- /dev/null
+++ b/doc/forum/Git_annex_hangs/comment_8_94dc2b8386a8286690292343bf3c89b3._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://me.yahoo.com/a/yx5Y6EI1t.759Jsu63ZWqYclCmpOmxxd.ramtw--#7114a"
+ nickname="Ioanas"
+ subject="Same issue here "
+ date="2015-05-26T17:13:28Z"
+ content="""
+I am also experiencing the same issue. How do I solve this? Re-installing git and git-annex (as some linked GitHub thread suggested) did not help.
+"""]]

Added a comment: Same issue here
diff --git a/doc/forum/Git_annex_hangs/comment_7_c22ffebedc9b1c1c74fc3f2f933971d3._comment b/doc/forum/Git_annex_hangs/comment_7_c22ffebedc9b1c1c74fc3f2f933971d3._comment
new file mode 100644
index 0000000..3e70f1a
--- /dev/null
+++ b/doc/forum/Git_annex_hangs/comment_7_c22ffebedc9b1c1c74fc3f2f933971d3._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://me.yahoo.com/a/yx5Y6EI1t.759Jsu63ZWqYclCmpOmxxd.ramtw--#7114a"
+ nickname="Ioanas"
+ subject="Same issue here "
+ date="2015-05-26T17:13:13Z"
+ content="""
+I am also experiencing the same issue. How do I solve this? Re-installing git and git-annex (as some linked GitHub thread suggested) did not help.
+"""]]

Added a comment: Same issue here
diff --git a/doc/forum/Git_annex_hangs/comment_6_4abe6aa966feea4e1881f6a2fbe7a007._comment b/doc/forum/Git_annex_hangs/comment_6_4abe6aa966feea4e1881f6a2fbe7a007._comment
new file mode 100644
index 0000000..2d84b08
--- /dev/null
+++ b/doc/forum/Git_annex_hangs/comment_6_4abe6aa966feea4e1881f6a2fbe7a007._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://me.yahoo.com/a/yx5Y6EI1t.759Jsu63ZWqYclCmpOmxxd.ramtw--#7114a"
+ nickname="Ioanas"
+ subject="Same issue here "
+ date="2015-05-26T17:12:59Z"
+ content="""
+I am also experiencing the same issue. How do I solve this? Re-installing git and git-annex (as some linked GitHub thread suggested) did not help.
+"""]]

Added a comment
diff --git a/doc/forum/Restricting_git-annex-shell_to_a_specific_repository/comment_4_4712a74774f60c29704d1e0f598caa78._comment b/doc/forum/Restricting_git-annex-shell_to_a_specific_repository/comment_4_4712a74774f60c29704d1e0f598caa78._comment
new file mode 100644
index 0000000..b50f137
--- /dev/null
+++ b/doc/forum/Restricting_git-annex-shell_to_a_specific_repository/comment_4_4712a74774f60c29704d1e0f598caa78._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="anarcat"
+ subject="comment 4"
+ date="2015-05-26T16:59:02Z"
+ content="""
+seems to me this should be migrated to a tip, no?
+"""]]

old version bug; not present in current version
diff --git a/doc/bugs/incremental_fsck-ing_a_remote_does_not_work_for_files_that_are_not_present_in_current_repository.mdwn b/doc/bugs/incremental_fsck-ing_a_remote_does_not_work_for_files_that_are_not_present_in_current_repository.mdwn
index ffc3acb..3b53866 100644
--- a/doc/bugs/incremental_fsck-ing_a_remote_does_not_work_for_files_that_are_not_present_in_current_repository.mdwn
+++ b/doc/bugs/incremental_fsck-ing_a_remote_does_not_work_for_files_that_are_not_present_in_current_repository.mdwn
@@ -101,3 +101,5 @@ ok
 giovanni@amalgama:/tmp/test (master)$ git annex fsck --from test --more
 giovanni@amalgama:/tmp/test (master)$
 """]]
+
+> [[done]] --[[Joey]]
diff --git a/doc/bugs/incremental_fsck-ing_a_remote_does_not_work_for_files_that_are_not_present_in_current_repository/comment_1_adbde1bbeb434f42f96cae7d3ad5b65f._comment b/doc/bugs/incremental_fsck-ing_a_remote_does_not_work_for_files_that_are_not_present_in_current_repository/comment_1_adbde1bbeb434f42f96cae7d3ad5b65f._comment
new file mode 100644
index 0000000..9fdc95a
--- /dev/null
+++ b/doc/bugs/incremental_fsck-ing_a_remote_does_not_work_for_files_that_are_not_present_in_current_repository/comment_1_adbde1bbeb434f42f96cae7d3ad5b65f._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-05-26T14:57:24Z"
+ content="""
+More recent versions of git-annex don't use the mtime hack, so avoid this
+problem. I had not realized that was a benefit of ditching the mtime hack,
+actually; it was done for other reasons like keeping separate incremental 
+fscks of different remotes. 
+
+I have verified that the problem does not exist with current versions.
+"""]]

commnet
diff --git a/doc/bugs/rsync:_protocol_version_mismatch/comment_5_7d819c3e4af2b8044a52fa6131f36187._comment b/doc/bugs/rsync:_protocol_version_mismatch/comment_5_7d819c3e4af2b8044a52fa6131f36187._comment
new file mode 100644
index 0000000..85af7d2
--- /dev/null
+++ b/doc/bugs/rsync:_protocol_version_mismatch/comment_5_7d819c3e4af2b8044a52fa6131f36187._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2015-05-26T14:52:11Z"
+ content="""
+The stray recv-key is a good clue. git-annex-shell only allows one upload
+of a given file to run at a time. So if you get a transfer stalled out,
+it will reject another transfer attempt. This can sometimes happen when eg,
+migrating between networks and restarting an upload when the old one is
+still running on the server.
+
+However, normally there is an error message "transfer already in progress".
+
+It may be that your rsync is not forwarding that stderr through to display
+it, for some reason.
+
+It would probably help if you can run the same git-annex shell command line
+on the server, verify that it fails with "transfer already in progress"
+when an recvkey of that key is already running. Then you could try sshing
+to the server noninteractively and having it run the same git-annex-shell
+command, and see if the error makes it through that.
+"""]]

Added a comment: Finding IPFS hash
diff --git a/doc/special_remotes/ipfs/comment_3_b8c7e402e0ee63d659ae33e3e2504ca2._comment b/doc/special_remotes/ipfs/comment_3_b8c7e402e0ee63d659ae33e3e2504ca2._comment
new file mode 100644
index 0000000..b2161ae
--- /dev/null
+++ b/doc/special_remotes/ipfs/comment_3_b8c7e402e0ee63d659ae33e3e2504ca2._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="rob.syme@92895c98b16fd7a88bed5f10913c522ebfd76c31"
+ nickname="rob.syme"
+ subject="Finding IPFS hash"
+ date="2015-05-26T05:08:38Z"
+ content="""
+I see now that git-annex only reports the ipfs hash when the remote is unencrypted. It the ipfs hash not reported for encrypted ipfs remotes for security reasons?
+"""]]

Added a comment: Finding IPFS hash
diff --git a/doc/special_remotes/ipfs/comment_2_564271a8660d7bbade6e4ed396fcfb57._comment b/doc/special_remotes/ipfs/comment_2_564271a8660d7bbade6e4ed396fcfb57._comment
new file mode 100644
index 0000000..426c21c
--- /dev/null
+++ b/doc/special_remotes/ipfs/comment_2_564271a8660d7bbade6e4ed396fcfb57._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="rob.syme@92895c98b16fd7a88bed5f10913c522ebfd76c31"
+ nickname="rob.syme"
+ subject="Finding IPFS hash"
+ date="2015-05-26T04:55:32Z"
+ content="""
+I'm using git-annex version: 5.20150522-gb199d65
+
+The example above gives the ipfs hash for the file, but when I run whereis, the hash is not reported:
+
+    $ git annex whereis test.txt
+    whereis test.txt (2 copies) 
+            1bd0f840-2247-4888-9237-596515788671 -- rob@rob-G60JX:/tmp/gitannextest [here]
+            adf361b3-7b1a-43e1-8360-937f7e436e90 -- [ipfs]
+    ok
+
+Is there a way for git-annex to report the file's ipfs hash ID?
+"""]]

Added a comment
diff --git a/doc/bugs/rsync:_protocol_version_mismatch/comment_4_77e59a25c859b6afec8b75f74885ef5e._comment b/doc/bugs/rsync:_protocol_version_mismatch/comment_4_77e59a25c859b6afec8b75f74885ef5e._comment
new file mode 100644
index 0000000..cad761d
--- /dev/null
+++ b/doc/bugs/rsync:_protocol_version_mismatch/comment_4_77e59a25c859b6afec8b75f74885ef5e._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="clacke"
+ subject="comment 4"
+ date="2015-05-24T17:41:17Z"
+ content="""
+Hm, not so sure that \"rebooted, did not help\" was actually true. I take that back.
+
+Now I saw a stray `git-annex-shell recv-key` process mentioning that file. I killed it and now everything seems fine. I will keep this in mind for next time, to see if I can verify that this was actually the cause of the message, but maybe it's a clue.
+"""]]

Added a comment
diff --git a/doc/bugs/git_annex_fsck_on_btrfs_devices/comment_1_f33d4cb9689f89f07bb97460e4f30be8._comment b/doc/bugs/git_annex_fsck_on_btrfs_devices/comment_1_f33d4cb9689f89f07bb97460e4f30be8._comment
new file mode 100644
index 0000000..d186370
--- /dev/null
+++ b/doc/bugs/git_annex_fsck_on_btrfs_devices/comment_1_f33d4cb9689f89f07bb97460e4f30be8._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="eigengrau"
+ subject="comment 1"
+ date="2015-05-24T15:07:34Z"
+ content="""
+I suppose since an I/O error can be intermittent, the file can’t be outright regarded as bad. Also I’m not sure whether the read system call returns a dedicated error code for checksum errors.
+"""]]

Added a comment
diff --git a/doc/bugs/Stale_keys_not_forgotten_upon_git-annex_forget/comment_2_ce97390480a04918cf20c12944ee65ef._comment b/doc/bugs/Stale_keys_not_forgotten_upon_git-annex_forget/comment_2_ce97390480a04918cf20c12944ee65ef._comment
new file mode 100644
index 0000000..d757eef
--- /dev/null
+++ b/doc/bugs/Stale_keys_not_forgotten_upon_git-annex_forget/comment_2_ce97390480a04918cf20c12944ee65ef._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="eigengrau"
+ subject="comment 2"
+ date="2015-05-24T14:58:30Z"
+ content="""
+Thanks! This would be useful. While it probably takes up only little disk space, the noise it creates during fsck would make it harder to discern which data has been unintentionally lost, as opposed to migrated to another back-end.
+"""]]

diff --git a/doc/bugs/git_annex_fsck_on_btrfs_devices.mdwn b/doc/bugs/git_annex_fsck_on_btrfs_devices.mdwn
new file mode 100644
index 0000000..1ad2f65
--- /dev/null
+++ b/doc/bugs/git_annex_fsck_on_btrfs_devices.mdwn
@@ -0,0 +1,14 @@
+### Please describe the problem.
+btrfs automatically validates checksums when data is read. If a checksum fails, instead of giving the corrupted file contents, the read will throw an I/O error. In result, it seems that git-annex fsck will not recognize the file as faulty, and will instead fail with a sha1sum parse error, without dropping the corresponding file as “bad”.
+
+[[!format sh """
+git annex fsck file
+fsck file (checksum...)
+sha1sum: .git/annex/objects/…: Input/output error
+git-annex: sha1sum parse error
+# End of transcript or log.
+"""]]
+
+### What version of git-annex are you using? On what operating system?
+git-annex 5.20150508
+linux 4.0.4

Added a comment: Tahoe-LAFS helper: multiple FURLs for the same grid
diff --git a/doc/special_remotes/tahoe/comment_1_d30f5958cca5dbcb93e4ea56a25586da._comment b/doc/special_remotes/tahoe/comment_1_d30f5958cca5dbcb93e4ea56a25586da._comment
new file mode 100644
index 0000000..63bb8f4
--- /dev/null
+++ b/doc/special_remotes/tahoe/comment_1_d30f5958cca5dbcb93e4ea56a25586da._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="junk@5e3eeba2290e8a3fcf938d9f93b0dfa2565dc7b1"
+ nickname="junk"
+ subject="Tahoe-LAFS helper: multiple FURLs for the same grid"
+ date="2015-05-24T13:48:33Z"
+ content="""
+Hi,
+
+I would like to uses git-annex in combination with Tahoe-LAFS. The grid will consist of private Servers connected though slow DSL-Lines. Thus I would like to use the Tahoe-LAFS helper feature (like a Tahoe-LAFS upload proxy):
+
+https://tahoe-lafs.org/trac/tahoe-lafs/browser/trunk/docs/helper.rst 
+
+This will result in a different FURL for each location pointing to the same Tahoe-LAFS grid. 
+
+How can I setup two git-annex clients to use two different FURLs for the same remote (the same Tahoe-LAFS grid)?
+
+Thank you very much for your help!
+
+Oliver
+"""]]

diff --git a/doc/bugs/incremental_fsck-ing_a_remote_does_not_work_for_files_that_are_not_present_in_current_repository.mdwn b/doc/bugs/incremental_fsck-ing_a_remote_does_not_work_for_files_that_are_not_present_in_current_repository.mdwn
new file mode 100644
index 0000000..ffc3acb
--- /dev/null
+++ b/doc/bugs/incremental_fsck-ing_a_remote_does_not_work_for_files_that_are_not_present_in_current_repository.mdwn
@@ -0,0 +1,103 @@
+### Please describe the problem.
+Incremental fsck keeps information about which time a file was last fsck-ed by setting mtime of the file's parent directory in `.git/annex/objects/`. When we are doing incremental fsck from a remote, files that are not available locally are never marked as checked (since said directory does not exist), so they are checked at every invocation of `git annex fsck --more`.
+
+### What steps will reproduce the problem?
+Create a git-annex repository with some random content. Then add any remote, copy files there, remove them locally and run an incremental fsck from the remote. Interrupt it and run again with `--more`. It will check again all the files, including those that have already been checked.
+
+### What version of git-annex are you using? On what operating system?
+Debian official package, 5.20141125, on Debian sid (more or less up-to-date).
+
+### Please provide any additional information below.
+
+[[!format sh """
+# Create a test repository
+giovanni@amalgama:~$ cd /tmp/
+giovanni@amalgama:/tmp$ mkdir test
+giovanni@amalgama:/tmp$ cd test/
+giovanni@amalgama:/tmp/test$ git init
+Inizializzato un repository Git in /tmp/test/.git/
+giovanni@amalgama:/tmp/test (master)$ git annex init
+init  ok
+(Recording state in git...)
+# Create random content
+giovanni@amalgama:/tmp/test (master)$ dd if=/dev/urandom bs=1M count=20 of=test1
+20+0 record dentro
+20+0 record fuori
+20971520 byte (21 MB) copiati, 1,15928 s, 18,1 MB/s
+giovanni@amalgama:/tmp/test (master)$ dd if=/dev/urandom bs=1M count=20 of=test2
+20+0 record dentro
+20+0 record fuori
+20971520 byte (21 MB) copiati, 1,12974 s, 18,6 MB/s
+giovanni@amalgama:/tmp/test (master)$ dd if=/dev/urandom bs=1M count=20 of=test3
+20+0 record dentro
+20+0 record fuori
+20971520 byte (21 MB) copiati, 1,16881 s, 17,9 MB/s
+giovanni@amalgama:/tmp/test (master)$ dd if=/dev/urandom bs=1M count=20 of=test4
+20+0 record dentro
+20+0 record fuori
+20971520 byte (21 MB) copiati, 1,14387 s, 18,3 MB/s
+giovanni@amalgama:/tmp/test (master)$ git annex add .
+add test1 ok
+add test2 ok
+add test3 ok
+add test4 ok
+(Recording state in git...)
+# Create a remote of type directory and move content there
+giovanni@amalgama:/tmp/test (master)$ mkdir /tmp/dir
+giovanni@amalgama:/tmp/test (master)$ git annex initremote test type=directory encryption=none directory=/tmp/dir
+initremote test ok
+(Recording state in git...)
+giovanni@amalgama:/tmp/test (master)$ git annex move --to test
+move test1 (to test...) 
+ok                      
+move test2 (to test...) 
+ok                      
+move test3 (to test...) 
+ok                      
+move test4 (to test...) 
+ok                      
+(Recording state in git...)
+# Launch a remote incremental fsck
+giovanni@amalgama:/tmp/test (master)$ git annex fsck --from test --incremental
+fsck test1 (checksum...)
+ok
+fsck test2 (checksum...)
+ok
+fsck test3 (checksum...)
+ok
+fsck test4 (checksum...)
+ok
+# Continue it; here I would expect nothing to happen, since all content has already been checked
+giovanni@amalgama:/tmp/test (master)$ git annex fsck --from test --more
+fsck test1 (checksum...)
+ok
+fsck test2 (checksum...)
+ok
+fsck test3 (checksum...)
+ok
+fsck test4 (checksum...)
+ok
+# Bring back content locally and launch again fsck
+giovanni@amalgama:/tmp/test (master)$ git annex get
+get test1 (from test...) 
+ok                      
+get test2 (from test...) 
+ok                      
+get test3 (from test...) 
+ok                      
+get test4 (from test...) 
+ok                      
+(Recording state in git...)
+giovanni@amalgama:/tmp/test (master)$ git annex fsck --from test --incremental
+fsck test1 (checksum...)
+ok
+fsck test2 (checksum...)
+ok
+fsck test3 (checksum...)
+ok
+fsck test4 (checksum...)
+ok
+# Now --more semantics is respected
+giovanni@amalgama:/tmp/test (master)$ git annex fsck --from test --more
+giovanni@amalgama:/tmp/test (master)$
+"""]]

report gcrypt bug
diff --git a/doc/bugs/gcrypt_gives_false___34__remote_ID_has_changed__34___warning_after_a_sync_fails_because_network_is_down.mdwn b/doc/bugs/gcrypt_gives_false___34__remote_ID_has_changed__34___warning_after_a_sync_fails_because_network_is_down.mdwn
new file mode 100644
index 0000000..35e5111
--- /dev/null
+++ b/doc/bugs/gcrypt_gives_false___34__remote_ID_has_changed__34___warning_after_a_sync_fails_because_network_is_down.mdwn
@@ -0,0 +1,43 @@
+### What steps will reproduce the problem?
+
+1. Create a fresh annex repo.  Create a dummy test file and add it to the annex.
+2. `git init --bare` in an empty directory on a remote machine.
+3. `git initremote testremote type=gcrypt encryption=hybrid gitrepo=ssh://machine/the/remote/machine/dir keyid=my_key_id`
+4. `git annex sync testremote --content`
+5. Unplug network/switch off WiFi.
+6. `git annex sync testremote --content`, which fails due to the broken network.
+7. Reconnect network, check that can ssh to remote host.
+8. `git annex sync testremote --content`
+
+gcrypt issues warning `gcrypt: WARNING: Remote ID has changed!`
+
+### What version of git-annex are you using? On what operating system?
+
+git-annex 5.20141125 on Debian Wheezy 32-bit.
+
+### Please provide any additional information below.
+
+This is essentially a gcrypt bug, so I don't know if you want to fix it, and I know that the gcrypt author is inactive.
+
+My diagnosis is that when running `git annex sync testremote --content` when the network is disconnected, git can't SSH to the remote and gcrypt makes the mistake of regenerating the remote ID and setting up a new remote.  So when the network comes back online, the local record of the remote's gcrypt ID is just wrong.  gcrypt ought not to "set up a new repository" when there is a network failure.
+
+    gcrypt: Development version -- Repository format MAY CHANGE
+    gcrypt: Repository not found: ssh://url-here
+    gcrypt: Setting up new repository
+    gcrypt: Remote ID is :id:agVyn7wBG/JGwN9LW5Qn
+    Counting objects: 22, done.
+    Compressing objects: 100% (17/17), done.
+    Total 22 (delta 4), reused 0 (delta 0)
+    gcrypt: Encrypting to:  -r my_key_id_here
+    gcrypt: Requesting manifest signature
+    ssh: Could not resolve hostname my_remote_host_here: No such file or directory
+    fatal: Could not read from remote repository.
+    
+    Please make sure you have the correct access rights
+    and the repository exists.
+    error: failed to push some refs to 'gcrypt::ssh://url-here
+    
+      Pushing to testremote failed.
+    
+      (non-fast-forward problems can be solved by setting receive.denyNonFastforwards to false in the remote's git config)
+    failed

fromkey, registerurl: Allow urls to be specified instead of keys, and generate URL keys.
This is especially useful because the caller doesn't need to generate valid
url keys, which involves some escaping of characters, and may involve
taking a md5sum of the url if it's too long.
diff --git a/Backend/URL.hs b/Backend/URL.hs
index 8ec270e..77397bd 100644
--- a/Backend/URL.hs
+++ b/Backend/URL.hs
@@ -31,8 +31,8 @@ backend = Backend
 	}
 
 {- Every unique url has a corresponding key. -}
-fromUrl :: String -> Maybe Integer -> Annex Key
-fromUrl url size = return $ stubKey
+fromUrl :: String -> Maybe Integer -> Key
+fromUrl url size = stubKey
 	{ keyName = genKeyName url
 	, keyBackendName = "URL"
 	, keySize = size
diff --git a/Command/AddUrl.hs b/Command/AddUrl.hs
index 96a966e..0de4da7 100644
--- a/Command/AddUrl.hs
+++ b/Command/AddUrl.hs
@@ -115,7 +115,7 @@ performRemote r relaxed uri file sz = ifAnnexed file adduri geturi
 
 downloadRemoteFile :: Remote -> Bool -> URLString -> FilePath -> Maybe Integer -> Annex (Maybe Key)
 downloadRemoteFile r relaxed uri file sz = do
-	urlkey <- Backend.URL.fromUrl uri sz
+	let urlkey = Backend.URL.fromUrl uri sz
 	liftIO $ createDirectoryIfMissing True (parentDir file)
 	ifM (Annex.getState Annex.fast <||> pure relaxed)
 		( do
@@ -206,7 +206,7 @@ performQuvi relaxed pageurl videourl file = ifAnnexed file addurl geturl
 #ifdef WITH_QUVI
 addUrlFileQuvi :: Bool -> URLString -> URLString -> FilePath -> Annex (Maybe Key)
 addUrlFileQuvi relaxed quviurl videourl file = do
-	key <- Backend.URL.fromUrl quviurl Nothing
+	let key = Backend.URL.fromUrl quviurl Nothing
 	ifM (pure relaxed <||> Annex.getState Annex.fast)
 		( do
 			cleanup webUUID quviurl file key Nothing
@@ -264,7 +264,7 @@ addUrlFile relaxed url urlinfo file = do
 
 downloadWeb :: URLString -> Url.UrlInfo -> FilePath -> Annex (Maybe Key)
 downloadWeb url urlinfo file = do
-	dummykey <- addSizeUrlKey urlinfo <$> Backend.URL.fromUrl url Nothing
+	let dummykey = addSizeUrlKey urlinfo $ Backend.URL.fromUrl url Nothing
 	let downloader f _ = do
 		showOutput
 		downloadUrl [url] f
@@ -321,7 +321,7 @@ cleanup u url file key mtmp = do
 nodownload :: URLString -> Url.UrlInfo -> FilePath -> Annex (Maybe Key)
 nodownload url urlinfo file
 	| Url.urlExists urlinfo = do
-		key <- Backend.URL.fromUrl url (Url.urlSize urlinfo)
+		let key = Backend.URL.fromUrl url (Url.urlSize urlinfo)
 		cleanup webUUID url file key Nothing
 		return (Just key)
 	| otherwise = do
diff --git a/Command/FromKey.hs b/Command/FromKey.hs
index ebc0e6f..584d913 100644
--- a/Command/FromKey.hs
+++ b/Command/FromKey.hs
@@ -1,6 +1,6 @@
 {- git-annex command
  -
- - Copyright 2010 Joey Hess <id@joeyh.name>
+ - Copyright 2010, 2015 Joey Hess <id@joeyh.name>
  -
  - Licensed under the GNU GPL version 3 or higher.
  -}
@@ -15,6 +15,9 @@ import qualified Annex.Queue
 import Annex.Content
 import Types.Key
 import qualified Annex
+import qualified Backend.URL
+
+import Network.URI
 
 cmd :: [Command]
 cmd = [notDirect $ notBareRepo $
@@ -28,7 +31,7 @@ seek ps = do
 
 start :: Bool -> [String] -> CommandStart
 start force (keyname:file:[]) = do
-	let key = fromMaybe (error "bad key") $ file2key keyname
+	let key = mkKey keyname
 	unless force $ do
 		inbackend <- inAnnex key
 		unless inbackend $ error $
@@ -45,12 +48,19 @@ massAdd = go True =<< map (separate (== ' ')) . lines <$> liftIO getContents
   where
 	go status [] = next $ return status
 	go status ((keyname,f):rest) | not (null keyname) && not (null f) = do
-		let key = fromMaybe (error $ "bad key " ++ keyname) $ file2key keyname
+		let key = mkKey keyname
 		ok <- perform' key f
 		let !status' = status && ok
 		go status' rest
 	go _ _ = error "Expected pairs of key and file on stdin, but got something else."
 
+mkKey :: String -> Key
+mkKey s = case file2key s of
+	Just k -> k
+	Nothing -> case parseURI s of
+		Just _u -> Backend.URL.fromUrl s Nothing
+		Nothing -> error $ "bad key " ++ s
+
 perform :: Key -> FilePath -> CommandPerform
 perform key file = do
 	ok <- perform' key file
diff --git a/Command/ImportFeed.hs b/Command/ImportFeed.hs
index 6d3a176..4bc3f52 100644
--- a/Command/ImportFeed.hs
+++ b/Command/ImportFeed.hs
@@ -370,4 +370,4 @@ clearFeedProblem :: URLString -> Annex ()
 clearFeedProblem url = void $ liftIO . tryIO . removeFile =<< feedState url
 
 feedState :: URLString -> Annex FilePath
-feedState url = fromRepo . gitAnnexFeedState =<< fromUrl url Nothing
+feedState url = fromRepo $ gitAnnexFeedState $ fromUrl url Nothing
diff --git a/Command/RegisterUrl.hs b/Command/RegisterUrl.hs
index d0e8065..4282db5 100644
--- a/Command/RegisterUrl.hs
+++ b/Command/RegisterUrl.hs
@@ -11,9 +11,9 @@ module Command.RegisterUrl where
 
 import Common.Annex
 import Command
-import Types.Key
 import Logs.Web
 import Annex.UUID
+import Command.FromKey (mkKey)
 
 cmd :: [Command]
 cmd = [notDirect $ notBareRepo $
@@ -25,7 +25,7 @@ seek = withWords start
 
 start :: [String] -> CommandStart
 start (keyname:url:[]) = do
-	let key = fromMaybe (error "bad key") $ file2key keyname
+	let key = mkKey keyname
 	showStart "registerurl" url
 	next $ perform key url
 start [] = do
@@ -38,7 +38,7 @@ massAdd = go True =<< map (separate (== ' ')) . lines <$> liftIO getContents
   where
 	go status [] = next $ return status
 	go status ((keyname,u):rest) | not (null keyname) && not (null u) = do
-		let key = fromMaybe (error $ "bad key " ++ keyname) $ file2key keyname
+		let key = mkKey keyname
 		ok <- perform' key u
 		let !status' = status && ok
 		go status' rest
diff --git a/Remote/BitTorrent.hs b/Remote/BitTorrent.hs
index 05326e3..a4ec11b 100644
--- a/Remote/BitTorrent.hs
+++ b/Remote/BitTorrent.hs
@@ -155,7 +155,7 @@ torrentUrlNum u
 
 {- A Key corresponding to the URL of a torrent file. -}
 torrentUrlKey :: URLString -> Annex Key
-torrentUrlKey u = fromUrl (fst $ torrentUrlNum u) Nothing
+torrentUrlKey u = return $ fromUrl (fst $ torrentUrlNum u) Nothing
 
 {- Temporary directory used to download a torrent. -}
 tmpTorrentDir :: URLString -> Annex FilePath
diff --git a/debian/changelog b/debian/changelog
index 5852585..e899df2 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+git-annex (5.20150523) UNRELEASED; urgency=medium
+
+  * fromkey, registerurl: Allow urls to be specified instead of keys,
+    and generate URL keys.
+
+ -- Joey Hess <id@joeyh.name>  Fri, 22 May 2015 22:23:32 -0400
+
 git-annex (5.20150522) unstable; urgency=medium
 
   * import: Refuse to import files that are within the work tree, as that
diff --git a/doc/git-annex-fromkey.mdwn b/doc/git-annex-fromkey.mdwn
index 1126e82..461f42e 100644
--- a/doc/git-annex-fromkey.mdwn
+++ b/doc/git-annex-fromkey.mdwn
@@ -15,6 +15,12 @@ If the key and file are not specified on the command line, they are
 instead read from stdin. Any number of lines can be provided in this
 mode, each containing a key and filename, separated by a single space.
 
+Normally the key is a git-annex formatted key. However, to make it easier
+to use this to add urls, if the key cannot be parsed as a key, and is a
+valid url, an URL key is constructed from the url. Note that this does not
+register the url as a location of the key; use [[git-annex-registerurl]](1)
+to do that.
+
 # OPTIONS
 
 * `--force`
diff --git a/doc/git-annex-registerurl.mdwn b/doc/git-annex-registerurl.mdwn
index 961fcbb..05328ab 100644
--- a/doc/git-annex-registerurl.mdwn
+++ b/doc/git-annex-registerurl.mdwn
@@ -17,6 +17,10 @@ If the key and url are not specified on the command line, they are

(Diff truncated)
Added a comment
diff --git a/doc/bugs/rsync:_protocol_version_mismatch/comment_3_eff8f33134157635387ee681805ff7a8._comment b/doc/bugs/rsync:_protocol_version_mismatch/comment_3_eff8f33134157635387ee681805ff7a8._comment
new file mode 100644
index 0000000..b2a335a
--- /dev/null
+++ b/doc/bugs/rsync:_protocol_version_mismatch/comment_3_eff8f33134157635387ee681805ff7a8._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="clacke"
+ subject="comment 3"
+ date="2015-05-22T22:16:45Z"
+ content="""
+Note that a thousand files went over without a hitch, but this particular file consistently fails.
+"""]]

Added a comment
diff --git a/doc/bugs/rsync:_protocol_version_mismatch/comment_2_531b85c911d390b1b93ee55a8cf5d47e._comment b/doc/bugs/rsync:_protocol_version_mismatch/comment_2_531b85c911d390b1b93ee55a8cf5d47e._comment
new file mode 100644
index 0000000..268f369
--- /dev/null
+++ b/doc/bugs/rsync:_protocol_version_mismatch/comment_2_531b85c911d390b1b93ee55a8cf5d47e._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="clacke"
+ subject="comment 2"
+ date="2015-05-22T21:08:26Z"
+ content="""
+It's weirder than that. I add a cow union mount over it, it works fine.
+
+I copy the file, I drop the file, I remove the union mount. Again it's back in the broken state. Rebooting does not help, so it's not some very insistent lock.
+
+Next I will try a copy of the repo, to see if that is able to carry over whatever strange state this thing is in.
+"""]]

add news item for git-annex 5.20150522
diff --git a/doc/news/version_5.20150406.mdwn b/doc/news/version_5.20150406.mdwn
deleted file mode 100644
index e4dfe00..0000000
--- a/doc/news/version_5.20150406.mdwn
+++ /dev/null
@@ -1,33 +0,0 @@
-git-annex 5.20150406 released with [[!toggle text="these changes"]]
-[[!toggleable text="""
-   * Prevent git-ls-files from double-expanding wildcards when an
-     unexpanded wildcard is passed to a git-annex command like add or find.
-   * Fix make build target. Thanks, Justin Geibel.
-   * Fix GETURLS in external special remote protocol to strip
-     downloader prefix from logged url info before checking for the
-     specified prefix.
-   * importfeed: Avoid downloading a redundant item from a feed whose
-     guid has been downloaded before, even when the url has changed.
-   * importfeed: Always store itemid in metadata; before this was only
-     done when annex.genmetadata was set.
-   * Relax debian package dependencies to git &gt;= 1:1.8.1 rather
-     than needing &gt;= 1:2.0.
-   * test: Fix --list-tests
-   * addurl --file: When used with a special remote that claims
-     urls and checks their contents, don't override the user's provided
-     filename with filenames that the special remote suggests. Also,
-     don't allow adding the url if the special remote says it contains
-     multiple files.
-   * import: --deduplicate and --cleanduplicates now output the keys
-     corresponding to duplicated files they process.
-   * expire: New command, for expiring inactive repositories.
-   * fsck: Record fsck activity for use by expire command.
-   * Fix truncation of parameters that could occur when using xargs git-annex.
-   * Significantly sped up processing of large numbers of directories
-     passed to a single git-annex command.
-   * version: Add --raw
-   * init: Improve fifo test to detect NFS systems that support fifos
-     but not well enough for sshcaching.
-   * --quiet now suppresses progress displays from eg, rsync.
-     (The option already suppressed git-annex's own built-in progress
-     displays.)"""]]
\ No newline at end of file
diff --git a/doc/news/version_5.20150522.mdwn b/doc/news/version_5.20150522.mdwn
new file mode 100644
index 0000000..a14c1a3
--- /dev/null
+++ b/doc/news/version_5.20150522.mdwn
@@ -0,0 +1,30 @@
+git-annex 5.20150522 released with [[!toggle text="these changes"]]
+[[!toggleable text="""
+   * import: Refuse to import files that are within the work tree, as that
+     does not make sense and could cause data loss.
+   * drop: Now supports --all, --unused, and --key.
+   * drop: Now defaults to --all when run in a bare repository.
+     (Previously, did nothing when run in a bare repository.)
+   * get, move, copy, mirror: Concurrent transfers are now supported!
+     For example: git-annex get -J10
+     However, progress bars are not yet displayed for concurrent transfers,
+     pending an updated version of the ascii-progress library.
+   * --quiet now makes progress output by rsync, wget, etc be quiet too.
+   * Take space that will be used by other running downloads into account when
+     checking annex.diskreserve.
+   * Avoid accumulating transfer failure log files unless the assistant is
+     being used.
+   * Fix an unlikely race that could result in two transfers of the same key
+     running at once.
+   * Stale transfer lock and info files will be cleaned up automatically
+     when get/unused/info commands are run.
+   * unused: Add --used-refspec option and annex.used-refspec, which can
+     specify a set of refs to consider used, rather than the default of
+     considering all refs used.
+   * webapp: Fix zombie xdg-open process left when opening file browser.
+     Closes: #[785498](http://bugs.debian.org/785498)
+   * Safer posix fctnl locking implementation, using lock pools and STM.
+   * Build documentation with TZ=UTC for reproducible builds. See #785736.
+   * OSX: Corrected the location of trustedkeys.gpg, so the built-in
+     upgrade code will find it. Fixes OSX upgrade going forward, but
+     older versions won't upgrade themselves due to this problem."""]]
\ No newline at end of file

comment
diff --git a/doc/bugs/rsync:_protocol_version_mismatch/comment_1_672d89a7d06d5ec336381b670a41a9c7._comment b/doc/bugs/rsync:_protocol_version_mismatch/comment_1_672d89a7d06d5ec336381b670a41a9c7._comment
new file mode 100644
index 0000000..8379a7d
--- /dev/null
+++ b/doc/bugs/rsync:_protocol_version_mismatch/comment_1_672d89a7d06d5ec336381b670a41a9c7._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-05-22T19:12:37Z"
+ content="""
+I think I've seen this where the shell was running some command
+at (non-interactive) login that output stuff and so screwed up the rsync
+protocol.
+
+rsync with sufficient -vvvv will print out a lot of debugging info about
+the protocol.
+"""]]

Weird rsync error message, initial report -- unable to reproduce faithfully yet
diff --git a/doc/bugs/rsync:_protocol_version_mismatch.mdwn b/doc/bugs/rsync:_protocol_version_mismatch.mdwn
new file mode 100644
index 0000000..fb55006
--- /dev/null
+++ b/doc/bugs/rsync:_protocol_version_mismatch.mdwn
@@ -0,0 +1,38 @@
+### Please describe the problem.
+This is a weird one. I'm getting rsync `protocol version mismatch -- is your shell clean?` on a particular file.
+
+I have tried to reproduce it but not been able.
+
+ * First time it happened, I went to the problem repo and did a `get`, which worked, destroying the evidence. "Luckily", this happened again a few days later.
+ * I thought maybe it was because there was a partial transfer in `.git/annex/tmp` with some specific characteristics. Nope, if I remove the file in `tmp` the problem remains.
+ * I made another clone think it was the problem repo, transferred the file to that repo, no problem. Dropped it, pointed everything back to the original bad repo. Still bad.
+ * Both sides are running `rsync  version 3.1.0  protocol version 31`.
+
+
+### What steps will reproduce the problem?
+
+Working on it. But I want to put the preliminaries here, in case someone else has seen this.
+
+### What version of git-annex are you using? On what operating system?
+
+Both sides are running `git-annex version: 5.20150508-g883d57f`, on Ubuntu 14.04.2 LTS.
+
+
+### 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 copy --to acozed claes/colt/20150511_174818.jpg 
+copy claes/colt/20150511_174818.jpg (checking acozed...) (to acozed...) 
+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) [sender=3.1.1]
+
+  rsync failed -- run git annex again to resume file transfer
+failed
+git-annex: copy: 1 failed
+
+
+# End of transcript or log.
+"""]]

OSX: Corrected the location of trustedkeys.gpg, so the built-in upgrade code will find it. Fixes OSX upgrade going forward, but older versions won't upgrade themselves due to this problem.
diff --git a/Makefile b/Makefile
index 1bab989..636cc90 100644
--- a/Makefile
+++ b/Makefile
@@ -174,7 +174,7 @@ osxapp: Build/Standalone Build/OSXMkLibs
 	ln -sf git-annex "$(OSXAPP_BASE)/git-annex-shell"
 	gzcat standalone/licences.gz > $(OSXAPP_BASE)/LICENSE
 	cp $(OSXAPP_BASE)/LICENSE tmp/build-dmg/LICENSE.txt
-	cp standalone/trustedkeys.gpg $(OSXAPP_BASE)
+	cp standalone/trustedkeys.gpg $(OSXAPP_DEST)
 
 	./Build/Standalone $(OSXAPP_BASE)
 
diff --git a/debian/changelog b/debian/changelog
index 9c3b8c9..3ada531 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -25,6 +25,9 @@ git-annex (5.20150508.2) UNRELEASED; urgency=medium
     Closes: #785498
   * Safer posix fctnl locking implementation, using lock pools and STM.
   * Build documentation with TZ=UTC for reproducible builds. See #785736.
+  * OSX: Corrected the location of trustedkeys.gpg, so the built-in
+    upgrade code will find it. Fixes OSX upgrade going forward, but
+    older versions won't upgrade themselves due to this problem.
 
  -- Joey Hess <id@joeyh.name>  Mon, 11 May 2015 12:45:06 -0400
 
diff --git a/doc/forum/OSX:_Upgrader:_Failed_to_check_if_upgrade_is_available./comment_1_ac7c1f39e723cbcd49d6497649e7e44f._comment b/doc/forum/OSX:_Upgrader:_Failed_to_check_if_upgrade_is_available./comment_1_ac7c1f39e723cbcd49d6497649e7e44f._comment
new file mode 100644
index 0000000..39eae02
--- /dev/null
+++ b/doc/forum/OSX:_Upgrader:_Failed_to_check_if_upgrade_is_available./comment_1_ac7c1f39e723cbcd49d6497649e7e44f._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-05-22T17:35:11Z"
+ content="""
+Aha, this is a path propel to the trustedkeys.gpg file, it's in bundle/
+in the OSX app, and git-annex tells gpg to look in the parent directory
+instead.
+
+Fixed in git. Unfortunately I can't fix old versions of git-annex so
+OSX users will need to manually upgrade to version 5.20150522 to get this
+fix.
+"""]]

comment
diff --git a/doc/todo/enable_a_discussion_forum_or_support_system/comment_2_b1129b4cdfe39e740c4f7cf0d6ff2b91._comment b/doc/todo/enable_a_discussion_forum_or_support_system/comment_2_b1129b4cdfe39e740c4f7cf0d6ff2b91._comment
new file mode 100644
index 0000000..c025271
--- /dev/null
+++ b/doc/todo/enable_a_discussion_forum_or_support_system/comment_2_b1129b4cdfe39e740c4f7cf0d6ff2b91._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2015-05-22T17:26:08Z"
+ content="""
+I think that mailman 3 could be a good solution for lots of different
+users.
+
+It is emphatically not the kind of thing I enjoy maintaining though! :)
+
+Example: <https://lists.stg.fedoraproject.org/archives/list/devel%40lists.fedoraproject.org/>
+"""]]

response
diff --git a/doc/forum/Invalid_cross-device_link/comment_1_46c35e04c8f8cb7205f08aa71cc4912a._comment b/doc/forum/Invalid_cross-device_link/comment_1_46c35e04c8f8cb7205f08aa71cc4912a._comment
new file mode 100644
index 0000000..96b88ca
--- /dev/null
+++ b/doc/forum/Invalid_cross-device_link/comment_1_46c35e04c8f8cb7205f08aa71cc4912a._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-05-22T17:19:38Z"
+ content="""
+I do this all the time (most recently 12 hours ago), and have never seen
+this problem. At least not in recent memory.
+
+You didn't say which version of git-annex you are using. Perhaps you
+need to upgrade from some old and broken version...
+
+Looking at the current code, it first tries a rename, and if that
+fails for a reason such as the two locations being on different devices,
+it falls back to using `cp`.
+"""]]

comment
diff --git a/doc/bugs/Stale_keys_not_forgotten_upon_git-annex_forget/comment_1_2b34b39ef76f205187b1d44fbbccd7f6._comment b/doc/bugs/Stale_keys_not_forgotten_upon_git-annex_forget/comment_1_2b34b39ef76f205187b1d44fbbccd7f6._comment
new file mode 100644
index 0000000..e5f50c8
--- /dev/null
+++ b/doc/bugs/Stale_keys_not_forgotten_upon_git-annex_forget/comment_1_2b34b39ef76f205187b1d44fbbccd7f6._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-05-22T17:16:28Z"
+ content="""
+`git annex forget` removes historcal data about where files were located in
+the past, but it does not affect the current logs about the current
+location (or lack of location) of files.
+
+It would be possible to extend `git annex forget` to do that, which is one
+approach to possibly solving [[fsck_reports_unsolvable_problem]].
+"""]]

diff --git a/doc/forum/Invalid_cross-device_link.mdwn b/doc/forum/Invalid_cross-device_link.mdwn
new file mode 100644
index 0000000..4dd104c
--- /dev/null
+++ b/doc/forum/Invalid_cross-device_link.mdwn
@@ -0,0 +1,9 @@
+I want to import from an SD card to a mounted annex:
+
+    user@laptop:/media/.../annex/Pictures/(master)$ git annex import /media/.../sdcard/Download/QuickTransfer
+    [...]
+    git-annex: /media/.../sdcard/Download/QuickTransfer/20150428_192110.jpg: rename: unsupported operation (Invalid cross-device link)
+    [...]
+
+Why is it trying to make a cross-device link? As long as it can read the files, 
+it should be OK, no?

diff --git a/doc/forum/Ambiguous_repo_names__63__.mdwn b/doc/forum/Ambiguous_repo_names__63__.mdwn
new file mode 100644
index 0000000..fb96240
--- /dev/null
+++ b/doc/forum/Ambiguous_repo_names__63__.mdwn
@@ -0,0 +1,8 @@
+The output of `git annex info` includes this:
+
+ 	34xx3351-xx14-4039-6xxx-xxx9x5xxxxxx -- wx550 (wx312)
+ 	9x9x07xx-x6x9-464x-7x5x-x3xx42xx7x70 -- wx550
+
+What does this mean? Do I have two different repos both named wx550?
+What is wx312? 
+

diff --git a/doc/forum/OSX:_Upgrader:_Failed_to_check_if_upgrade_is_available..mdwn b/doc/forum/OSX:_Upgrader:_Failed_to_check_if_upgrade_is_available..mdwn
new file mode 100644
index 0000000..1f02b56
--- /dev/null
+++ b/doc/forum/OSX:_Upgrader:_Failed_to_check_if_upgrade_is_available..mdwn
@@ -0,0 +1,36 @@
+I noticed this in my log file...
+
+<pre>
+[2015-05-21 18:10:02 CDT] main: starting assistant version 5.20150508-gf71c23f
+(started...) gpg: keyring `/Applications/git-annex.app/Contents/MacOS/trustedkeys.gpg' created
+...
+[2015-05-21 18:10:02 CDT] Upgrader: Checking if an upgrade is available.
+...
+[2015-05-21 18:10:02 CDT] call: curl ["-s","-f","-L","-C","-","-#","-o","/var/folders/zk/tk15c40n6h1bjl94ntk5md8h0000gn/T/git-annex.tmp.0/info.sig","http://downloads.kitenet.net/git-annex/OSX/current/10.10_Yosemite/git-annex.dmg.info.sig","--user-agent","git-annex/5.20150419-g900e1b6"]
+[2015-05-21 18:10:03 CDT] call: gpg ["--no-default-keyring","--no-auto-check-trustdb","--no-options","--homedir","/var/folders/zk/tk15c40n6h1bjl94ntk5md8h0000gn/T/git-annex-gpg.tmp.0","--keyring","/Applications/git-annex.app/Contents/MacOS/trustedkeys.gpg","--verify","/var/folders/zk/tk15c40n6h1bjl94ntk5md8h0000gn/T/git-annex.tmp.0/info.sig"]
+gpg: Signature made Fri May  8 15:10:28 2015 CDT using DSA key ID 89C809CB
+gpg: Can't check signature: public key not found
+[2015-05-21 18:10:03 CDT] Upgrader: Failed to check if upgrade is available.
+</pre>
+
+So I copied trustedkeys.gpg from the bundle folder to the MacOS folder, replacing the newly created trustedkeys.gpg and now I get this... which is better... ;-)
+
+<pre>
+[2015-05-21 18:17:24 CDT] main: starting assistant version 5.20150508-gf71c23f
+...
+[2015-05-21 18:17:25 CDT] Upgrader: Checking if an upgrade is available.
+...
+[2015-05-21 18:17:25 CDT] call: curl ["-s","-f","-L","-C","-","-#","-o","/var/folders/zk/tk15c40n6h1bjl94ntk5md8h0000gn/T/git-annex.tmp.0/info","http://downloads.kitenet.net/git-annex/OSX/current/10.10_Yosemite/git-annex.dmg.info","--user-agent","git-annex/5.20150508-gf71c23f"]
+...
+[2015-05-21 18:17:25 CDT] call: curl ["-s","-f","-L","-C","-","-#","-o","/var/folders/zk/tk15c40n6h1bjl94ntk5md8h0000gn/T/git-annex.tmp.0/info.sig","http://downloads.kitenet.net/git-annex/OSX/current/10.10_Yosemite/git-annex.dmg.info.sig","--user-agent","git-annex/5.20150508-gf71c23f"]
+[2015-05-21 18:17:25 CDT] call: gpg ["--no-default-keyring","--no-auto-check-trustdb","--no-options","--homedir","/var/folders/zk/tk15c40n6h1bjl94ntk5md8h0000gn/T/git-annex-gpg.tmp.0","--keyring","/Applications/git-annex.app/Contents/MacOS/trustedkeys.gpg","--verify","/var/folders/zk/tk15c40n6h1bjl94ntk5md8h0000gn/T/git-annex.tmp.0/info.sig"]
+gpg: Signature made Fri May  8 15:10:28 2015 CDT using DSA key ID 89C809CB
+gpg: /var/folders/zk/tk15c40n6h1bjl94ntk5md8h0000gn/T/git-annex-gpg.tmp.0/trustdb.gpg: trustdb created
+gpg: Good signature from "git-annex distribution signing key (for Joey Hess) <id@joeyh.name>"
+gpg: WARNING: This key is not certified with a trusted signature!
+gpg:          There is no indication that the signature belongs to the owner.
+Primary key fingerprint: 4005 5C6A FD2D 526B 2961  E78F 5EE1 DBA7 89C8 09CB
+[2015-05-21 18:17:25 CDT] Upgrader: No new version found.
+</pre>
+
+FYI

Added a comment
diff --git a/doc/tips/finding_duplicate_files/comment_12_630b065f41019716a5f6848e0adcd0f0._comment b/doc/tips/finding_duplicate_files/comment_12_630b065f41019716a5f6848e0adcd0f0._comment
new file mode 100644
index 0000000..1f17e67
--- /dev/null
+++ b/doc/tips/finding_duplicate_files/comment_12_630b065f41019716a5f6848e0adcd0f0._comment
@@ -0,0 +1,29 @@
+[[!comment format=mdwn
+ username="CandyAngel"
+ subject="comment 12"
+ date="2015-05-21T15:39:07Z"
+ content="""
+My method uses Perl to do a lot of the work, cutting out the need to sort and being careful about spaces and such. Below is an (**untested**) command line version (my version has the perl in ~/bin/annex-dupe.pl):
+
+    git annex find --format='${key} ${file}\n' > ~/tmp/annex_kf.txt
+    perl -pe '($k,$f) = split / /, $_, 2; $cf{$k}++; $_ = sprintf \"%s%s\n\", ($cf{$k}>1?\"\":\"#\", $f;' ~/tmp/annex_kf.txt > ~/tmp/annex_dupes.txt
+    grep '^#' ~/tmp/annex_dupes.txt | xargs -d'\n' git rm
+
+And the equivalent \"one liner\":
+
+    git annex find --format='${key} ${file}\n' \
+    | perl -pe '($k,$f) = split / /, $_, 2; $cf{$k}++; $_ = sprintf \"%s%s\n\", ($cf{$k}>1?\"\":\"#\", $f;' \
+    | grep '^#' \
+    | xargs -d'\n' git rm
+
+It works by getting a list of keys and paths and passing them to Perl, which prefixes the first instance of each key's path with a '#', which is removed by grep, leaving only duplicate paths being passed to xargs and thus, to 'git rm'.
+
+This can be particularly handy as it lets you delete duplicates from specific subdirectories, just by adding another 'grep DIR/PATH' in front of xargs, without worrying you will lose all references if all instances are in DIR/PATH (because the first one will have been removed from the file list by the first grep!).
+
+For example, after outputting all the duplicates (~/tmp/annex_dupe.txt), I will then do a:
+
+    grep '^#' ~/tmp/annex_dupes.txt | grep 'some/sub/dir/somewhere' | xargs -d'\n' git rm
+    git commit -m \"Cleaned up 'some/sub/dir/somewhere'\"
+
+loop, if I want more control over where things are removed from.
+"""]]

diff --git a/doc/bugs/Stale_keys_not_forgotten_upon_git-annex_forget.mdwn b/doc/bugs/Stale_keys_not_forgotten_upon_git-annex_forget.mdwn
new file mode 100644
index 0000000..4363426
--- /dev/null
+++ b/doc/bugs/Stale_keys_not_forgotten_upon_git-annex_forget.mdwn
@@ -0,0 +1,31 @@
+### Please describe the problem.
+At some point, I migrated all my WORM-backed objects to SHA1E. I then squashed my master branch to get rid of any WORM references and dropped unused objects. Recently, I noticed that the git-annex branch still has all tracking information on the old WORM keys. I tried running git-annex forget, but the old keys are not purged, even though no (local or remote) branch refers to them and no git-annex repository has the data for these keys anymore. Should such keys be purged by git-annex forget, too?
+
+### What steps will reproduce the problem?
+
+[[!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 init /tmp/repo
+cd /tmp/repo
+git annex init
+echo hi > file
+git annex add --backend=WORM file
+git commit -m init
+git annex migrate
+git commit -m migrated
+git checkout --orphan tmp
+git commit -m squashed
+git branch -m master -f
+git annex unused
+git annex dropunused 1 --force
+git annex forget --drop-dead --force
+git ls-tree -r git-annex | grep WORM
+
+# End of transcript or log.
+"""]]
+
+### What version of git-annex are you using? On what operating system?
+git-annex 5.20150508
+Linux 4.0.4
+

Added a comment
diff --git a/doc/bare_repositories/comment_6_bf227861ec3cb2ea474c143218c68133._comment b/doc/bare_repositories/comment_6_bf227861ec3cb2ea474c143218c68133._comment
new file mode 100644
index 0000000..1a43c0a
--- /dev/null
+++ b/doc/bare_repositories/comment_6_bf227861ec3cb2ea474c143218c68133._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://me.yahoo.com/a/bBy7WkgQicYHIiiyj.Vm0TcMbxi2quzbPFef#6f9f7"
+ nickname="Frederik Vanrenterghem"
+ subject="comment 6"
+ date="2015-05-21T06:14:33Z"
+ content="""
+Thanks Anarcat. I actually was dealing with a repository in direct mode, not bare mode. Only realised after today encountering one in bare mode, and reading [[internals]]. Your method worked too, but
+
+    git annex indirect 
+
+would have been quicker I guess.
+"""]]

Its vs it's
diff --git a/doc/tips/using_git_annex_with_no_fixed_hostname_and_optimising_ssh.mdwn b/doc/tips/using_git_annex_with_no_fixed_hostname_and_optimising_ssh.mdwn
index 594d8c4..ade91c9 100644
--- a/doc/tips/using_git_annex_with_no_fixed_hostname_and_optimising_ssh.mdwn
+++ b/doc/tips/using_git_annex_with_no_fixed_hostname_and_optimising_ssh.mdwn
@@ -28,7 +28,7 @@ For the laptop it is easy:
 
     git remote add desktop ssh://desktop/~/annex 
 
-However for the desktop to add an ever changing laptops hostname it's a little tricky.  We make use of remote SSH tunnels to do this.  Essentially we have the laptop (which always knows it's own name and address and knows the address of the desktop) create a tunnel starting on an arbitrary port at the desktop and heads back to the laptop on it's own SSH server port (22).
+However for the desktop to add an ever changing laptops hostname it's a little tricky.  We make use of remote SSH tunnels to do this.  Essentially we have the laptop (which always knows its own name and address and knows the address of the desktop) create a tunnel starting on an arbitrary port at the desktop and heads back to the laptop on its own SSH server port (22).
 
 To do this make part of your laptop's SSH config look like this:
 

diff --git a/doc/bugs/__34__metadata_only__34___git-remote-gcrypt_syncing_files_anyway.mdwn b/doc/bugs/__34__metadata_only__34___git-remote-gcrypt_syncing_files_anyway.mdwn
new file mode 100644
index 0000000..a318692
--- /dev/null
+++ b/doc/bugs/__34__metadata_only__34___git-remote-gcrypt_syncing_files_anyway.mdwn
@@ -0,0 +1,69 @@
+### Please describe the problem.
+The git-annex assistant queues files for transfer to gcrypt git (not SSH) remotes, which shouldn't happen. `git-annex sync gcrypt` doesn't.  
+I think the problem might be that the assistant triggers a content sync, despite showing "metadata only", and that sync --content circumvents gcrypt.
+
+I have a gcrypt remote set up with github, but I can reprodue this issue using a directory as the destination as well.
+
+When I set up the remote and sync it, it works as it should:
+
+    ~/annex (git)-[annex/direct/master] % git remote add gcrypt gcrypt::/tmp/test
+    ~/annex (git)-[annex/direct/master] % git-annex sync gcrypt
+    commit  (recording state in git...)
+    ok
+    pull gcrypt
+    gcrypt: Development version -- Repository format MAY CHANGE
+    gcrypt: Repository not found: /tmp/test
+    ok
+    push gcrypt
+    gcrypt: Development version -- Repository format MAY CHANGE
+    gcrypt: Repository not found: /tmp/test
+    gcrypt: Setting up new repository
+    gcrypt: Remote ID is :id:thetwentycharacterid
+    Counting objects: 469459, done.
+    Compressing objects: 100% (122643/122643), done.
+    Total 469459 (delta 342415), reused 468156 (delta 341616)
+    gcrypt: Encrypting to:  -r fngerprintremoved
+    gcrypt: Requesting manifest signature
+    To gcrypt::/tmp/test
+     * [new branch]      git-annex -> synced/git-annex
+     * [new branch]      annex/direct/master -> synced/master
+    ok
+
+But when I launch the assistant/webapp, it starts queuing and syncing file contents, even though the remote is listed as "metadata only".
+
+After letting the assistant run for a minute:
+
+    ~ % ls /tmp/test/annex/objects/
+    000  043  091  0ed  130  18e  1d8  21c  26c  2b2  2f4  334  371  3ad  3e3  439  471  4b4  525  565  5c3  61b  691  724  788  ...
+
+*And the files aren't encrypted!*
+
+    find /tmp/test/annex/objects/ -type f -exec file {} \; | head -n10
+    /tmp/test/annex/objects/247/100/SHA256E-s5310--06c62006efde5abd7d03dbb15e3725982c80c0eaffde90e3b566fab26d810d6d.opf/SHA256E-s5310--06c62006efde5abd7d03dbb15e3725982c80c0eaffde90e3b566fab26d810d6d.opf: XML 1.0 document text
+    /tmp/test/annex/objects/5f8/851/SHA256E-s36705--a3b71efc462876709de6c95a7b21218fe437fe45ed39cf5da2709be546c360bc.jpg/SHA256E-s36705--a3b71efc462876709de6c95a7b21218fe437fe45ed39cf5da2709be546c360bc.jpg: JPEG image data, JFIF standard 1.01, aspect ratio, density 1x1, segment length 16, baseline, precision 8, 310x500, frames 3
+    /tmp/test/annex/objects/f09/b22/SHA256E-s358928--7e7680e24baf28a82b94cf9931d73a8353ae5c009d81cb4d8c6e313bdc0b22e0/SHA256E-s358928--7e7680e24baf28a82b94cf9931d73a8353ae5c009d81cb4d8c6e313bdc0b22e0: EPUB document
+    /tmp/test/annex/objects/512/38c/SHA256E-s4246--f7dda72a07aa9f11e329e180c873ba1edd45ac80aa270e379ac52e09302ccfa0.opf/SHA256E-s4246--f7dda72a07aa9f11e329e180c873ba1edd45ac80aa270e379ac52e09302ccfa0.opf: XML 1.0 document text
+    /tmp/test/annex/objects/079/b2d/SHA256E-s496807--d5ba2b9a564a199ea33da246d70f43c8f531c53745130c4ae82ac8b5b5180684.epub/SHA256E-s496807--d5ba2b9a564a199ea33da246d70f43c8f531c53745130c4ae82ac8b5b5180684.epub: EPUB document
+    /tmp/test/annex/objects/6e3/e05/SHA256E-s5145--07a4770b8d1c10e46834b895484c20fca7f7e0850a51f8eb1f7c91f175ab2f8a.opf/SHA256E-s5145--07a4770b8d1c10e46834b895484c20fca7f7e0850a51f8eb1f7c91f175ab2f8a.opf: XML 1.0 document text
+    /tmp/test/annex/objects/b65/708/SHA256E-s271061--dc839391472cf5f08edc2807f7dd016a1ce4f5e3113a964882585fd6dcc51ce2.epub/SHA256E-s271061--dc839391472cf5f08edc2807f7dd016a1ce4f5e3113a964882585fd6dcc51ce2.epub: EPUB document
+    /tmp/test/annex/objects/9a4/9d3/SHA256E-s38917--5a1a770c758f2f9b254ad7f2f6b6e33b87f14486322d04b5d25b09569772b9e1.jpg/SHA256E-s38917--5a1a770c758f2f9b254ad7f2f6b6e33b87f14486322d04b5d25b09569772b9e1.jpg: JPEG image data, JFIF standard 1.01, aspect ratio, density 1x1, segment length 16, baseline, precision 8, 305x500, frames 3
+    /tmp/test/annex/objects/4ec/b23/SHA256E-s307073--cbdef5840ad0addde500d2bfbb5e916c71dea6394f647f6663771abdb05a1776/SHA256E-s307073--cbdef5840ad0addde500d2bfbb5e916c71dea6394f647f6663771abdb05a1776: EPUB document
+    /tmp/test/annex/objects/074/106/SHA256E-s307165--9a379564df17b9e1a0b7a2221e81180db447a05a9f1123b52fe2a618462a922e.epub/SHA256E-s307165--9a379564df17b9e1a0b7a2221e81180db447a05a9f1123b52fe2a618462a922e.epub: EPUB document
+
+The above files are part of my Calibre library.
+
+For my github repo, the assistant still shows files queuing but they don't actually show up in the repo. I think it's trying to sync using SSH but failing.
+
+### What steps will reproduce the problem?
+1. Create a git-remote-gcrypt remote on a git server or in a local directory
+2. Open the git-annex webapp, ensuring that syncing is enabled
+
+### What version of git-annex are you using? On what operating system?
+
+    ~ % git-annex version
+    git-annex version: 5.20150519-g87f28bb
+    build flags: Assistant Webapp Webapp-secure Pairing Testsuite S3 Inotify DBus DesktopNotify DNS Feeds Quvi TDFA TorrentParser
+    key/value backends: SHA256E SHA1E SHA512E SHA224E SHA384E SKEIN256E SKEIN512E MD5E SHA256 SHA1 SHA512 SHA224 SHA384 SKEIN256 SKEIN512 MD5 WORM URL
+    remote types: git gcrypt S3 bup directory rsync web bittorrent glacier ddar hook external
+
+I'm running Arch Linux

remove too much time
diff --git a/doc/special_remotes/S3.mdwn b/doc/special_remotes/S3.mdwn
index 1b81659..2b3d07e 100644
--- a/doc/special_remotes/S3.mdwn
+++ b/doc/special_remotes/S3.mdwn
@@ -59,7 +59,6 @@ the S3 remote.
   This is not enabled by default, since other S3 implementations may
   not support multipart uploads or have different limits,
   but can be enabled or changed at any time.
-  time.
 
 * `fileprefix` - By default, git-annex places files in a tree rooted at the
   top of the S3 bucket. When this is set, it's prefixed to the filenames

mention mailman 3
diff --git a/doc/todo/enable_a_discussion_forum_or_support_system.mdwn b/doc/todo/enable_a_discussion_forum_or_support_system.mdwn
index 6596a1e..99f291e 100644
--- a/doc/todo/enable_a_discussion_forum_or_support_system.mdwn
+++ b/doc/todo/enable_a_discussion_forum_or_support_system.mdwn
@@ -115,7 +115,13 @@ enough, exists for a lot of mailing lists...
 Like it or not, web forums do enable a lot of less technical users to
 participate because they only need their web browser, and crossing
 that boundary can be hard for some people. Mailing lists also do not
-necessarily favor collaboration as much as the other systems...
+necessarily favor collaboration as much as the other systems, because
+they are articulated more towards discussion, as opposed to establishing
+common knowledge.
+
+A good option may be Mailman 3 which, with the new web interface, allows
+forum-like functionalities. Mailman 2 also used to have a usenet interface,
+not sure what became of that in Mailman 3.
 
 Web forums
 ==========

Added a comment
diff --git a/doc/forum/__34__git_annex_sync__34___synced_after_8_hours/comment_6_0714eca58513f1059fc246ee152078e7._comment b/doc/forum/__34__git_annex_sync__34___synced_after_8_hours/comment_6_0714eca58513f1059fc246ee152078e7._comment
new file mode 100644
index 0000000..fbf7265
--- /dev/null
+++ b/doc/forum/__34__git_annex_sync__34___synced_after_8_hours/comment_6_0714eca58513f1059fc246ee152078e7._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="candyangel@7b9260fff42e1f6f552e1348007f7409a9101e82"
+ nickname="candyangel"
+ subject="comment 6"
+ date="2015-05-20T14:14:32Z"
+ content="""
+I've just come across something else which has sped up git operations on the index a *lot*.
+
+My $annex/.git/index was over 500M which made operations on the index really slow (git add/rm etc.) as it gets rewritten out in its entirety, every time!
+
+    git update-index --index-version 4
+
+brought it down to 200M, making everything much, much faster!
+
+[There is a warning in the git documentation](http://git-scm.com/docs/git-update-index) that alternative git implementations might not understand it, so bear that in mind if you want to use it.
+"""]]

comment
diff --git a/doc/todo/enable_a_discussion_forum_or_support_system/comment_1_578c0ab40d53dd56bb3f2d98491c5e85._comment b/doc/todo/enable_a_discussion_forum_or_support_system/comment_1_578c0ab40d53dd56bb3f2d98491c5e85._comment
new file mode 100644
index 0000000..4b57009
--- /dev/null
+++ b/doc/todo/enable_a_discussion_forum_or_support_system/comment_1_578c0ab40d53dd56bb3f2d98491c5e85._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-05-19T21:32:58Z"
+ content="""
+Of these, only Discourse seems interesting to me. (Or email list.)
+As long as it supports responding by email, it would work for me, and
+collaboratively editing is a good thing. Of course, we try to do that on
+the tips pages already..
+
+Note that as of today, users can log into this website using
+just their email address.
+"""]]

devblog
diff --git a/doc/devblog/day_286-287__rotten_locks.mdwn b/doc/devblog/day_286-287__rotten_locks.mdwn
new file mode 100644
index 0000000..7db07da
--- /dev/null
+++ b/doc/devblog/day_286-287__rotten_locks.mdwn
@@ -0,0 +1,44 @@
+There's something rotten in POSIX fctnl locking. It's not composable,
+or thread-safe.
+
+The most obvious problem with it is that if you have 2 threads, and they
+both try to take an exclusive lock of the same file (each opening it
+separately) ... They'll both succeed. Unlike 2 separate processes,
+where only one can take the lock.
+
+Then the really crazy bit: If a process has a lock file open and fcntl
+locked, and then the same process opens the lock file again, for any
+reason, closing the new FD will release the lock that was set
+using the other FD.
+
+So, that's a massive gotcha if you're writing complex multithreaded code.
+Or generally for composition of code. Of course, C programmers deal with
+this kind of thing all the time, but in the clean world of Haskell, this is
+a glaring problem. We don't expect to need to worry about this kind of
+unrelated side effect that breaks composition and thread safety.
+
+After noticing this problem affected git-anenx in at least one place,
+I have to assume there could be more. And I don't want to need to worry
+about this problem forever. So, I have been working today on a clean fix
+that I can cleanly switch all my lock-related code to use.
+
+One reasonable approach would be to avoid fcntl locking, and use flock.
+But, flock works even less well on NFS than fcntl, and git-annex relies on
+some fcntl locking features. On Linux, there's an "open file description
+locks" feature that fixes POSIX fnctl locking to not have this horrible
+wart, but that's not portable.
+
+Instead, my approach is to keep track of which files the process has
+locked. If it tries to do something with a lockfile that it already has
+locked, it avoids opening the same file again, instead implements its own
+in-process locking behavior. I use STM to do that in a thread-safe manner.
+
+I should probably break out git-annex's lock file handling code as a
+library. Eventually.. This was about as much fun as a root canal, and I'm
+having a real one tomorrow. :-/
+
+----
+
+git-annex is now included in [Stackage](http://www.stackage.org/)!
+
+Daniel Kahn Gillmor is doing some work on reproducible builds of git-annex.

git-annex is now available in stackage; suggest using to in fromsource to avoid cabal hell issues
diff --git a/doc/install/fromsource.mdwn b/doc/install/fromsource.mdwn
index 3f2987b..fdb7823 100644
--- a/doc/install/fromsource.mdwn
+++ b/doc/install/fromsource.mdwn
@@ -34,12 +34,18 @@ First, install everything git-annex needs to build:
 Now you can build git-annex by running either `make` or `cabal build`
 inside the source tree.
 
-## minimal build with cabal
+## minimal build with cabal and stackage
 
 This can be done anywhere, and builds git-annex without some optional features
 that require harder-to-install C libraries. This is plenty to let you get started with
 git-annex, but it does not include the assistant or webapp.
 
+Be warned that this involves building a lot of Haskell libraries from
+source, and so it has a lot of moving parts, and it's not uncommon for it
+to be broken from time to time. A nice way to avoid such breakage is to
+[configure cabal to use the Stackage repository](http://www.stackage.org/),
+which is a more stable and consistent version of the Hackage repository.
+
 Inside the source tree, run:
 
 	cabal configure -f"-assistant -webapp -webdav -pairing -xmpp -dns"
@@ -48,17 +54,15 @@ Inside the source tree, run:
 	PATH=$HOME/bin:$PATH
 	cabal install --bindir=$HOME/bin
 
-Be warned that this involves building a lot of Haskell libraries from
-source, and so it has a lot of moving parts, and it's not uncommon for it
-to be broken from time to time.
-
-## full build with cabal
+## full build with cabal and stackage
 
 To build with all features enabled, including the assistant and webapp,
 you will need to install several C libraries and their headers,
 including libgnutls, libgsasl, libxml2, and zlib. How to do that for
 your OS is beyond the scope of this page. 
 
+Using [Stackage](http://www.stackage.org/) is again a good idea here!
+
 Once the C libraries are installed, run inside the source tree:
 
 	cabal configure

close
diff --git a/doc/todo/fcntl_locks_break_with_threaded_concurrency.mdwn b/doc/todo/fcntl_locks_break_with_threaded_concurrency.mdwn
index c4d6627..3743886 100644
--- a/doc/todo/fcntl_locks_break_with_threaded_concurrency.mdwn
+++ b/doc/todo/fcntl_locks_break_with_threaded_concurrency.mdwn
@@ -25,3 +25,5 @@ A more generic approach is to use Annex.LockFile for everything,
 and make it check its lock pool via STM for other threads holding a lock.
 (Currently, the pool is only used for shared locks.)
 --[[Joey]] 
+
+> [[fixed|done]] via LockPools. --[[Joey]]

document exit codes of inannex
diff --git a/doc/git-annex-shell.mdwn b/doc/git-annex-shell.mdwn
index 4185774..0313fd7 100644
--- a/doc/git-annex-shell.mdwn
+++ b/doc/git-annex-shell.mdwn
@@ -38,6 +38,10 @@ first "/~/" or "/~user/" is expanded to the specified home directory.
   This checks if all specified keys are present in the annex, 
   and exits zero if so.
 
+  Exits 1 if the key is certianly not present in the annex.
+  Exits 100 if it's unable to tell (perhaps the key is in the process of
+  being removed from the annex).
+
 * dropkey directory [key ...]
 
   This drops the annexed data for the specified keys.

Added a comment
diff --git a/doc/bare_repositories/comment_5_6328134497c0de6a088087fc9cb0e59e._comment b/doc/bare_repositories/comment_5_6328134497c0de6a088087fc9cb0e59e._comment
new file mode 100644
index 0000000..8090685
--- /dev/null
+++ b/doc/bare_repositories/comment_5_6328134497c0de6a088087fc9cb0e59e._comment
@@ -0,0 +1,31 @@
+[[!comment format=mdwn
+ username="https://id.koumbit.net/anarcat"
+ subject="comment 5"
+ date="2015-05-19T12:18:05Z"
+ content="""
+Well, no, i don't think they changed, unless i missed something: there
+shouldn't be a `.git` repository there.
+
+There are [various
+instructions](http://stackoverflow.com/questions/10637378/how-do-i-convert-a-bare-git-repository-into-a-normal-one-in-place)
+on how to do this online. They do seem to agree with the first comment
+above.
+
+Personnally, I would just `git clone` to a different repo and `git
+annex forget` the old one. Unless you have a very complex repository
+with a lot of files, this is simple enough... You could even use `git
+annex reinit` to recycle the previous uuid if that's a concern. So in
+short:
+
+   git clone repo.git repo
+   cd repo
+   git annex info --fast # find the UUID of repo.git
+   git annex move --from $UUID
+   git annex reinit $UUID
+
+Then `repo.git` can be removed if you are certain everything is
+correct in `repo`.
+
+Note that you may want to have backups of everything before you do
+anything, as usual.
+"""]]

diff --git a/doc/bugs/keeps_demanding_ssh_key_even_if_all_sync__39__s_turned_down.mdwn b/doc/bugs/keeps_demanding_ssh_key_even_if_all_sync__39__s_turned_down.mdwn
new file mode 100644
index 0000000..adeb531
--- /dev/null
+++ b/doc/bugs/keeps_demanding_ssh_key_even_if_all_sync__39__s_turned_down.mdwn
@@ -0,0 +1,60 @@
+### Please describe the problem.
+
+May be I was simply wrong to assume that if I disable all sync'ing for all the repos, assistant wouldn't try to contact those remote hosts. But it still does
+
+In the logs, since no time stamp per each line, hard to say either recent ones just continuation of previous entries, or new ones:
+
+[[
+
+[2015-05-18 10:29:39 EDT] Watcher: Performing startup scan
+(started...) ssh: connect to host vagus.cns.dartmouth.edu port 22: No route to host^M
+ssh: connect to host vagus.cns.dartmouth.edu port 22: No route to host^M
+ssh: connect to host vagus.cns.dartmouth.edu port 22: No route to host^M
+ssh: connect to host vagus.cns.dartmouth.edu port 22: No route to host^M
+ssh: connect to host vagus.cns.dartmouth.edu port 22: No route to host^M
+ssh: connect to host vagus.cns.dartmouth.edu port 22: No route to host^M
+...
+]]
+
+and in another
+
+[[
+fsck xppaut_6.11b+1.dfsg.orig.tar.gz ok
+fsck xserver-xorg-input-synaptics_1.6.2+git44-ge28575b.orig.tar.gz ok
+fsck xserver-xorg-video-intel_2.99.917.orig.tar.gz (checksum...)
+ok
+(recording state in git...)
+  ** No known copies exist of python-mne_0.8.3+dfsg.orig.tar.gz
+git-annex: fsck: 1 failed
+
+(process:3954): Gtk-WARNING **: Locale not supported by C library.
+    Using the fallback 'C' locale.
+Write failed: Broken pipe^M
+
+(process:20140): Gtk-WARNING **: Locale not supported by C library.
+    Using the fallback 'C' locale.
+
+(process:20178): Gtk-WARNING **: Locale not supported by C library.
+    Using the fallback 'C' locale.
+git-annex: Daemon is already running.
+
+(process:29035): Gtk-WARNING **: Locale not supported by C library.
+    Using the fallback 'C' locale.
+
+(process:29184): Gtk-WARNING **: Locale not supported by C library.
+    Using the fallback 'C' locale.
+
+(process:30127): Gtk-WARNING **: Locale not supported by C library.
+    Using the fallback 'C' locale.
+
+(process:30817): Gtk-WARNING **: Locale not supported by C library.
+    Using the fallback 'C' locale.
+Write failed: Broken pipe^M
+]]
+
+that host (vagus) is RIP (need to remove from syncs)
+btw which are falling into daemon.log.1 not .log
+
+### What version of git-annex are you using? On what operating system?
+
+5.20150509+gitga10e45d-1~ndall+1

Added a comment: A possible solution
diff --git a/doc/bugs/OSX:_Assistant_leaves_repo_in_inconsistent_state/comment_3_1e0841d71c33fd3919310f1711b6e0b4._comment b/doc/bugs/OSX:_Assistant_leaves_repo_in_inconsistent_state/comment_3_1e0841d71c33fd3919310f1711b6e0b4._comment
new file mode 100644
index 0000000..319b001
--- /dev/null
+++ b/doc/bugs/OSX:_Assistant_leaves_repo_in_inconsistent_state/comment_3_1e0841d71c33fd3919310f1711b6e0b4._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="Marco"
+ subject="A possible solution"
+ date="2015-05-19T11:03:22Z"
+ content="""
+While searching for the problem I found this:
+
+http://feeding.cloud.geek.nz/posts/error-while-running-git-gc/
+> git reflog expire --all --stale-fix
+
+I can't verify this because I nuked the broken repository after recreating it.
+"""]]

Added a comment: Convert bare repository to normal
diff --git a/doc/bare_repositories/comment_4_7cf6103709a7a2710686681a6f406214._comment b/doc/bare_repositories/comment_4_7cf6103709a7a2710686681a6f406214._comment
new file mode 100644
index 0000000..0953d09
--- /dev/null
+++ b/doc/bare_repositories/comment_4_7cf6103709a7a2710686681a6f406214._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://me.yahoo.com/a/bBy7WkgQicYHIiiyj.Vm0TcMbxi2quzbPFef#6f9f7"
+ nickname="Frederik Vanrenterghem"
+ subject="Convert bare repository to normal"
+ date="2015-05-19T09:17:15Z"
+ content="""
+Just wondering what the right steps are to convert a bare repository to a normal one? The comment above from 2.5 years ago includes the creation of a .git directory, which actually already exists. Have things changed in the mean time?
+"""]]

fix links
diff --git a/doc/todo/enable_a_discussion_forum_or_support_system.mdwn b/doc/todo/enable_a_discussion_forum_or_support_system.mdwn
index 1a4e152..6596a1e 100644
--- a/doc/todo/enable_a_discussion_forum_or_support_system.mdwn
+++ b/doc/todo/enable_a_discussion_forum_or_support_system.mdwn
@@ -37,16 +37,14 @@ either][] - so another dead-end.
  [mobile version]: http://meta.stackexchange.com/questions/104458/switch-to-mobile-site-on-standard-browser
  [doesn't support offline access either]: http://meta.stackexchange.com/questions/220036/offline-features-in-stack-exchange-app
 
-Stackexchange runs a [garbled mess of IIS, MSSQL, ASP, Redis and
-Elasticsearch][] so there is probably little hope in integrating into
+Stackexchange runs a [garbled mess][] of IIS, MSSQL, ASP, Redis and
+Elasticsearch so there is probably little hope in integrating into
 something like git. I have asked for the [proverbial pony in this
 stackexchange question][] (yes, it's all very meta), describing the
 use case, but i am not holding my breath for a change.
 
- [garbled mess of IIS, MSSQL, ASP, Redis and Elasticsearch]:
- http://en.wikipedia.org/wiki/Stack_Exchange#Technologies_used
- [proverbial pony in this stackexchange question]:
- http://meta.stackexchange.com/questions/256573/best-way-to-use-stackexchange-sites-offline-or-on-dialup
+ [garbled mess]: http://en.wikipedia.org/wiki/Stack_Exchange#Technologies_used
+ [proverbial pony in this stackexchange question]: http://meta.stackexchange.com/questions/256573/best-way-to-use-stackexchange-sites-offline-or-on-dialup
  
 Askbot
 ======
@@ -102,10 +100,8 @@ discussed by everyone here, in a spirit of consensus building. :)
  [offline tool]: https://github.com/etewiah/offcourse
  [discussion about offline suport in discourse]: https://meta.discourse.org/t/offcourse-a-proof-of-concept-offline-reader-for-discourse/22356
  [discourse]: http://discourse.org/
- [warn against switching existing communities]:
- http://www.discourse.org/faq/#switch
- [officially supported in Docker]:
- https://github.com/discourse/discourse/blob/master/docs/INSTALL.md
+ [warn against switching existing communities]: http://www.discourse.org/faq/#switch
+ [officially supported in Docker]: https://github.com/discourse/discourse/blob/master/docs/INSTALL.md
 
 Mailing lists
 =============

Added a comment
diff --git a/doc/devblog/day_285__tuning_git-annex_unused_refs/comment_3_52179fc326e681d8fbf85ee8963f352c._comment b/doc/devblog/day_285__tuning_git-annex_unused_refs/comment_3_52179fc326e681d8fbf85ee8963f352c._comment
new file mode 100644
index 0000000..f85d633
--- /dev/null
+++ b/doc/devblog/day_285__tuning_git-annex_unused_refs/comment_3_52179fc326e681d8fbf85ee8963f352c._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="https://id.koumbit.net/anarcat"
+ subject="comment 3"
+ date="2015-05-16T21:46:20Z"
+ content="""
+interesting! i didn't think of those requirements, which do seem quite stringent, but i am certainly sensitive to them, considering i will be spending my own significant amount of time with intermittent access soon.
+
+i have opened a todo item to move the discussion somewhere more relevant, see [[todo/enable_a_discussion_forum_or_support_system]].
+"""]]

finally open that discussion directly
diff --git a/doc/todo/enable_a_discussion_forum_or_support_system.mdwn b/doc/todo/enable_a_discussion_forum_or_support_system.mdwn
new file mode 100644
index 0000000..1a4e152
--- /dev/null
+++ b/doc/todo/enable_a_discussion_forum_or_support_system.mdwn
@@ -0,0 +1,130 @@
+I has been [[discussed|devblog/day_268_stressed_out]]
+[[twice|devblog/day_285__tuning_git-annex_unused_refs]] that the
+current [[forum]] support system is not ideal for providing
+support. It constitutes the [largest part of this wiki][] yet we
+sometimes get duplicated questions and it seems the forum may be a
+barrier to entry for people.
+
+ [largest part of this wiki]: http://git-annex.branchable.com/devblog/day_268_stressed_out/#comment-e0814585df0047e6d4e11515aebe1dec
+
+A few alternatives have been proposed, from a mailing list to using a
+StackExchange site. This post is to discuss the possible
+alternatives. The requirement is that the system may be available
+offline and on low-bandwidth connections yet enable conversations
+better than a simple web forum or mailing list; which may end up being
+the only solution considering the first requirements, but let's give
+it a try. :)
+
+Stack exchange
+==============
+
+i looked up how this works in stackexchange, and it turns out they
+provide [regular dumps][] of the data hosted. unfortunately, it's a
+gigantic zip file and not really designed for low-bandwidth
+use. There's also a [data explorer][] that was promising, until i
+realized that the query engine takes up 154KB, three times the space
+of the regular search engine (~54KB, which I guess is way too much for
+dialup).
+
+ [regular dumps]: http://blog.stackoverflow.com/category/cc-wiki-dump/
+ [data explorer]: http://data.stackexchange.com/
+
+Also: there is a [mobile version][] of all the stackexchange sites,
+which take up around 3KB, but still only works online. There's an app
+for mobile devices as well, but it [doesn't support offline access
+either][] - so another dead-end.
+
+ [mobile version]: http://meta.stackexchange.com/questions/104458/switch-to-mobile-site-on-standard-browser
+ [doesn't support offline access either]: http://meta.stackexchange.com/questions/220036/offline-features-in-stack-exchange-app
+
+Stackexchange runs a [garbled mess of IIS, MSSQL, ASP, Redis and
+Elasticsearch][] so there is probably little hope in integrating into
+something like git. I have asked for the [proverbial pony in this
+stackexchange question][] (yes, it's all very meta), describing the
+use case, but i am not holding my breath for a change.
+
+ [garbled mess of IIS, MSSQL, ASP, Redis and Elasticsearch]:
+ http://en.wikipedia.org/wiki/Stack_Exchange#Technologies_used
+ [proverbial pony in this stackexchange question]:
+ http://meta.stackexchange.com/questions/256573/best-way-to-use-stackexchange-sites-offline-or-on-dialup
+ 
+Askbot
+======
+
+Besides, SE sites are based on proprietary software, and i am not sure
+we'd want to advocate that here. There are free software alternatives,
+of which i made an [evaluation about 2 years ago][] after which we
+tried Askbot at [Koumbit][]. it never took off: staff didn't seem
+interested in it so much and we never made people aware of it too
+much. plus, it didn't integrate with existing authentication
+mechanisms (which are a little bit of a mess for us)...
+
+But it does seem like an interesting alternative, and has [primitive
+email integration][] where you can ask questions by email, but not
+answer (!). I haven't looked at such support in other software, but i
+suspect it is similarly not a priority as they struggle to monetize
+their free software...
+
+Most of those free software alternatives of Stackexchange are written
+in Python/Django or Ruby/Rails (iirc) with SQL backends, which would
+probably make git integration... also "challenging".
+
+ [evaluation about 2 years ago]: (https://wiki.koumbit.net/FaqService#A.2BAMk-valuation_logicielle)
+ [Koumbit]: http://koumbit.org/
+ [primitive email integration]: http://askbot.org/doc/sending-email-to-askbot.html
+
+Discourse
+=========
+
+From that point of view, maybe [discourse][] could be an interesting
+alternative. It has built-in email support, as it is designed as an
+alternative to mailing lists. With a simple setting, you can
+collaborate directly by email. What is interesting, compared to the
+mailing list model, is that posts can be collaboratively edited to
+(for example) arrive at a collective wisdom by refining an answer (or
+a question). There are also interesting community moderation and
+reputation systems.
+
+There seems to be some [offline tool][] for Discourse, but it's
+unclear to me how it works, as it seems to be a separate (nodejs!)
+application that connects with a discourse plugin. There's a
+[discussion about offline suport in discourse][] in the meta site...
+
+Discourse uses Ruby/Rails and PostgreSQL, and somewhat is only
+[officially supported in Docker][]...
+
+The discourse people do [warn against switching existing
+communities][] to Discourse because of the resulting friction, so it
+is also in that spirit that I open discussion about this here, that
+is, in the hope the change can be acknowledged, supported and
+discussed by everyone here, in a spirit of consensus building. :)
+
+ [offline tool]: https://github.com/etewiah/offcourse
+ [discussion about offline suport in discourse]: https://meta.discourse.org/t/offcourse-a-proof-of-concept-offline-reader-for-discourse/22356
+ [discourse]: http://discourse.org/
+ [warn against switching existing communities]:
+ http://www.discourse.org/faq/#switch
+ [officially supported in Docker]:
+ https://github.com/discourse/discourse/blob/master/docs/INSTALL.md
+
+Mailing lists
+=============
+
+Of course, the forum could simply be moved to a mailing list. The
+would have the advantage of reducing the barrier of entry to the site,
+reduce the load on the wiki, at the cost of adding the additionnal
+"how do i subscribe to a mailing list" barrier of entry, which, oddly
+enough, exists for a lot of mailing lists...
+
+Like it or not, web forums do enable a lot of less technical users to
+participate because they only need their web browser, and crossing
+that boundary can be hard for some people. Mailing lists also do not
+necessarily favor collaboration as much as the other systems...
+
+Web forums
+==========
+
+There's a plethora of "php-bb-like" software out there, i am just
+ignoring them for now, as I am not very familiar with them and they
+have never been too attractive for me, but people are of course free
+to edit this page to add suggestions! :)

twitter search seems to be too broken to include a feed from it anymore
The search seems to only find spammy tweets. I know people talk about
git-anenx on twitter, but it seems twitter's search does not find those
interesting conversations.
diff --git a/doc/feeds.mdwn b/doc/feeds.mdwn
deleted file mode 100644
index cc63be8..0000000
--- a/doc/feeds.mdwn
+++ /dev/null
@@ -1,4 +0,0 @@
-Aggregating git-annex mentions from elsewhere on the net..
-
-* [[!aggregate expirecount=25 name="twitter" feedurl="http://tmp.kitenet.net/git-annex-twitter.rss" url="http://search.twitter.com/search.atom?q=git-annex"]]
-
diff --git a/doc/index.mdwn b/doc/index.mdwn
index 4834a90..77b61da 100644
--- a/doc/index.mdwn
+++ b/doc/index.mdwn
@@ -2,12 +2,6 @@
 
 [[!sidebar content="""
 [[!inline feeds=no template=bare pages=sidebar]]
-
-[[Feeds]]:
-
-<small>
-[[!inline pages="internal(feeds/*)" archive=yes show=8 feeds=no]]
-</small>
 """]]
 
 <table>

Added a comment
diff --git a/doc/devblog/day_285__tuning_git-annex_unused_refs/comment_2_dae167e473c60dace129c66beb0af384._comment b/doc/devblog/day_285__tuning_git-annex_unused_refs/comment_2_dae167e473c60dace129c66beb0af384._comment
new file mode 100644
index 0000000..41e0922
--- /dev/null
+++ b/doc/devblog/day_285__tuning_git-annex_unused_refs/comment_2_dae167e473c60dace129c66beb0af384._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ subject="comment 2"
+ date="2015-05-16T18:35:22Z"
+ content="""
+Unfortunately stack exchange is nearly unusable for me on dialup. In order for me to contribute to any git-annex communication channels, it needs to be something that can be taken offline, like git or email.
+"""]]

nasty issue with fcntl locks
diff --git a/doc/todo/fcntl_locks_break_with_threaded_concurrency.mdwn b/doc/todo/fcntl_locks_break_with_threaded_concurrency.mdwn
new file mode 100644
index 0000000..c4d6627
--- /dev/null
+++ b/doc/todo/fcntl_locks_break_with_threaded_concurrency.mdwn
@@ -0,0 +1,27 @@
+When using git-annex get -J2, one thread can clear another thread's
+transfer lock.
+
+This happens because fcntl locking is used, and it is not thread-safe.
+<https://github.com/haskell/unix/issues/44>
+
+>        *  If a process closes any  file  descriptor  referring  to  a
+>           file,  then  all  of  the  process's locks on that file are
+>           released, regardless of the file descriptor(s) on which the
+>           locks  were obtained. 
+
+One thread starts a transfer and locks it; the second thread starts a
+transfer of a different file, and in order to check annex.diskreserve,
+checks to see which other transfers are currently running. In doing this
+check, it closes a fd attached to the first thread's lock, which causes the
+lock to be dropped.
+
+This only affects -J mode.
+
+To fix it, probably need to use STM to keep a list of transfers all threads
+in the current process are doing. Then the lock checking code can avoid
+re-opening locks for transfers in the STM list.
+
+A more generic approach is to use Annex.LockFile for everything,
+and make it check its lock pool via STM for other threads holding a lock.
+(Currently, the pool is only used for shared locks.)
+--[[Joey]] 

Added a comment: Disaster recovery
diff --git a/doc/bugs/OSX:_Assistant_leaves_repo_in_inconsistent_state/comment_2_5c5e7356cae8ddf8d2c8964fb69000f5._comment b/doc/bugs/OSX:_Assistant_leaves_repo_in_inconsistent_state/comment_2_5c5e7356cae8ddf8d2c8964fb69000f5._comment
new file mode 100644
index 0000000..5d39e8a
--- /dev/null
+++ b/doc/bugs/OSX:_Assistant_leaves_repo_in_inconsistent_state/comment_2_5c5e7356cae8ddf8d2c8964fb69000f5._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="Marco"
+ subject="Disaster recovery"
+ date="2015-05-15T09:40:16Z"
+ content="""
+Ah, found it:
+
+https://git-annex.branchable.com/design/assistant/disaster_recovery/
+
+> As long as the git repository has at least one remote, another method is to clone the remote, sync from all other remotes, move over .git/config and .git/annex/objects, and tar up the old broken git repo and git annex add it
+"""]]

Added a comment: git annex repair --force
diff --git a/doc/bugs/OSX:_Assistant_leaves_repo_in_inconsistent_state/comment_1_0dfd9eedccb48f1f3d7939677dc96446._comment b/doc/bugs/OSX:_Assistant_leaves_repo_in_inconsistent_state/comment_1_0dfd9eedccb48f1f3d7939677dc96446._comment
new file mode 100644
index 0000000..be48ca8
--- /dev/null
+++ b/doc/bugs/OSX:_Assistant_leaves_repo_in_inconsistent_state/comment_1_0dfd9eedccb48f1f3d7939677dc96446._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="Marco"
+ subject="git annex repair --force"
+ date="2015-05-15T08:01:25Z"
+ content="""
+This command removed all history. It looks like no file was ever added.
+
+Any idea how I should handle this client repository? I could clone again from a backup. Is it possible to keep the annex UUID for a new clone?
+"""]]

diff --git a/doc/bugs/OSX:_Assistant_leaves_repo_in_inconsistent_state.mdwn b/doc/bugs/OSX:_Assistant_leaves_repo_in_inconsistent_state.mdwn
new file mode 100644
index 0000000..c7231cd
--- /dev/null
+++ b/doc/bugs/OSX:_Assistant_leaves_repo_in_inconsistent_state.mdwn
@@ -0,0 +1,151 @@
+### Please describe the problem.
+Shortly after starting the assistant the local client repository is in an inconsistent state. Just using the cli works fine without destroying the repository.
+
+### What steps will reproduce the problem?
+- Working git annex repository
+
+- Start the Git-Annex Assistant
+> git annex assistant
+
+- Wait a short time and then check the repository state:
+> ➜  annex git:(master) ✗ gst
+> On branch master
+> error: Could not read ea63b58d1252e3432280cdce1282eb02035c926e
+> error: Could not read ea63b58d1252e3432280cdce1282eb02035c926e
+> fatal: Failed to traverse parents of commit 108fa97a989aeabff16738558e1aa636c836598b
+
+- refs/heads/synced/git-annex links to an unknown commit
+> ➜  .git git:(master) cat refs/heads/synced/git-annex
+> be8e6023fbb172b12cec8fdbaa8654194f71c4f5% 
+
+> git show be8e6023fbb172b12cec8fdbaa8654194f71c4f5
+> fatal: unable to read source tree (d2959525362dcadd4dbec96a8f18d80cc689a851)
+
+### What version of git-annex are you using? On what operating system?
+- git-annex version: 5.20150508-gf71c23f
+- Mac OSX 10.10.2
+
+### Please provide any additional information below.
+
+[[!format sh """
+
+[2015-05-15 07:06:32 CEST] main: starting assistant version 5.20150508-gf71c23f
+[2015-05-15 07:06:32 CEST] Cronner: Consistency check in progress
+fsck 2015-05-01 07.56.02.jpg (checksum…)
+ok
+fsck 2015-05-01 09.55.58.jpg (checksum…)
+ok
+fsck 2015-05-14 12.38.24.jpg (checksum…)
+ok
+fsck 2015-05-14 12.39.30.jpg (checksum…)
+ok
+fsck 2015-05-14 12.40.49.jpg (checksum…)
+ok
+fsck 2015-05-14 12.40.53.jpg (checksum…)
+ok
+fsck 2015-05-14 12.43.42.jpg (checksum…)
+ok
+fsck 2015-05-14 12.44.16.jpg (checksum…)
+ok
+fsck 2015-05-14 12.45.11.jpg (checksum…)
+ok
+(recording state in git…)
+[2015-05-15 07:06:39 CEST] TransferScanner: Syncing with nas 
+(scanning…) [2015-05-15 07:06:39 CEST] Watcher: Performing startup scan
+gpg: Unterschrift vom Fr  8 Mai 22:10:28 2015 CEST mittels DSA-Schlüssel ID 89C809CB
+gpg: Unterschrift kann nicht geprüft werden: Öffentlicher Schlüssel nicht gefunden
+(started…) 
+[2015-05-15 07:06:41 CEST] Committer: Committing changes to git
+(recording state in git…)
+[2015-05-15 07:06:41 CEST] Pusher: Syncing with nas 
+
+
+0%            0.0 B/s 0s
+2%          32.0KB/s 47s
+...
+90%         467.6KB/s 0s
+                        
+[2015-05-15 07:06:47 CEST] Transferrer: Uploaded 2015-05-1..38.24.jpg
+
+
+0%            0.0 B/s 0s
+1%          32.0KB/s 54s
+...
+91%         534.5KB/s 0s
+                        
+[2015-05-15 07:06:54 CEST] Transferrer: Uploaded 2015-05-1..45.11.jpg
+
+
+0%            0.0 B/s 0s
+2%        16.0KB/s 1m30s
+…
+90%         440.4KB/s 0s
+                        
+[2015-05-15 07:07:01 CEST] Transferrer: Uploaded 2015-05-1..44.16.jpg
+
+
+0%            0.0 B/s 0s
+1%        16.0KB/s 1m42s
+...
+91%         508.2KB/s 0s
+                        
+[2015-05-15 07:07:07 CEST] Transferrer: Uploaded 2015-05-1..43.42.jpg
+
+
+0%            0.0 B/s 0s
+1%        16.0KB/s 1m40s
+...
+91%         371.6KB/s 0s
+                        
+[2015-05-15 07:07:13 CEST] Transferrer: Uploaded 2015-05-1..40.53.jpg
+
+
+0%            0.0 B/s 0s
+1%          32.0KB/s 50s
+...
+91%         495.1KB/s 0s
+                        
+[2015-05-15 07:07:19 CEST] Transferrer: Uploaded 2015-05-1..40.49.jpg
+
+
+0%            0.0 B/s 0s
+1%          32.0KB/s 53s
+...
+92%         528.2KB/s 0s
+                        
+[2015-05-15 07:07:25 CEST] Transferrer: Uploaded 2015-05-1..39.30.jpg
+ssh: connect to host 1.2.3.43 port 22: Operation timed out
+fatal: Could not read from remote repository.
+
+Please make sure you have the correct access rights
+and the repository exists.
+fatal: ‚/Volumes/WD1500GB/annex‘ does not appear to be a git repository
+fatal: Could not read from remote repository.
+
+Please make sure you have the correct access rights
+and the repository exists.
+ssh: connect to host 1.2.3.43 port 22: Operation timed out
+s(recording state in git…)
+fatal: ‚/Volumes/WD1500GB/annex‘ does not appear to be a git repository
+fatal: Could not read from remote repository.
+
+Please make sure you have the correct access rights
+and the repository exists.
+ssh: connect to host 1.2.3.43 port 22: Operation timed out
+fatal: Could not read from remote repository.
+
+Please make sure you have the correct access rights
+and the repository exists.
+[2015-05-15 07:08:16 CEST] Cronner: Attempting to repair aether [here]
+Unpacking all pack files.
+ssh: connect to host 1.2.3.43 port 22: Operation timed out
+fatal: Could not read from remote repository.
+
+Please make sure you have the correct access rights
+and the repository exists.
+ssh: connect to host 1.2.3.36 port 22:sssssh: connect to host 1.2.3.43 port 22: Operation timed out
+fatal: early EOF
+
+
+# End of transcript or log.
+"""]]

diff --git a/doc/bugs/Metadata_changes_are_not_reflected_in_a_view.mdwn b/doc/bugs/Metadata_changes_are_not_reflected_in_a_view.mdwn
new file mode 100644
index 0000000..cf8e106
--- /dev/null
+++ b/doc/bugs/Metadata_changes_are_not_reflected_in_a_view.mdwn
@@ -0,0 +1,31 @@
+### Please describe the problem.
+Changing metadata while being in an active view will not update the view.
+
+### What steps will reproduce the problem?
+(inside a repository)
+
+1. Create a file
+
+        $ uuidgen >file
+
+2. switch into a view
+
+       $ git annex view !blah
+       $ ls
+       file
+
+3. changed the metadata the view is based upon
+
+       $ git annex metadata -t blah file
+       $ ls
+       file
+
+   It would be nice/expected that the view gets updated when the metadata changes, hiding 'file' now
+  
+
+### What version of git-annex are you using? On what operating system?
+
+git-annex version: 5.20141024~bpo70+1
+on debian wheezy with backports
+
+### Please provide any additional information below.

Added a comment: mailing lists and support sites
diff --git a/doc/devblog/day_285__tuning_git-annex_unused_refs/comment_1_a3f0dd4fc8457af7c72040fbe8fd5fee._comment b/doc/devblog/day_285__tuning_git-annex_unused_refs/comment_1_a3f0dd4fc8457af7c72040fbe8fd5fee._comment
new file mode 100644
index 0000000..a94383f
--- /dev/null
+++ b/doc/devblog/day_285__tuning_git-annex_unused_refs/comment_1_a3f0dd4fc8457af7c72040fbe8fd5fee._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="anarcat"
+ subject="mailing lists and support sites"
+ date="2015-05-14T20:26:59Z"
+ content="""
+after years subscribing to zillions of them, i have acquired an allergy to mailing lists. it seems that i get this every once in a while: i'm subscribed to a bunch of them and i stop reading and just hit \"d\" on my mail client. :)
+
+i think there are very interesting alternatives, online web forums (yes yes, i know, bear with me) where knowledge is established and shared instead of just having a threaded conversation. i'm thinking of http://ask.debian.net/ or the stackexchange sites. as i [[analysed before|devblog/day_268_stressed_out/#comment-e0814585df0047e6d4e11515aebe1dec]], the forum is the biggest part of this website (and consequently the git-annex source code!), bug tracker coming in second, and the two together forming the majority of disk usage of the git repository.  there are alternative discussion tools like discourse.org that may also be interesting for people wanting to run such a service.
+
+anyways, the ideas of those is to converge on a set of FAQs and knowledge items more than just have random discussion, and force people to reuse existing topics.
+
+if i had more time, i'd probably setup something like this but really, i can only encourage those initiatives at this point. :)
+"""]]

json missing some output?
diff --git a/doc/bugs/transfer_in_progress_not_present_in_json_output.mdwn b/doc/bugs/transfer_in_progress_not_present_in_json_output.mdwn
new file mode 100644
index 0000000..1e4efe9
--- /dev/null
+++ b/doc/bugs/transfer_in_progress_not_present_in_json_output.mdwn
@@ -0,0 +1,28 @@
+### Please describe the problem.
+
+i can't find a key in the JSON output of `git annex info` for the "transfer in progress" field. is it missing on purpose? or am I missing some field?
+
+### What steps will reproduce the problem?
+
+<pre>
+git annex info
+git annex info --json
+</pre>
+
+
+### What version of git-annex are you using? On what operating system?
+5.20150406-g2a9fbec debian jessie
+
+### 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
+anarcat@desktop008:mp3$ git annex info  --fast --json | grep -i transfer
+anarcat@desktop008:mp3$ git annex info  --fast | grep -i transfer
+transfers in progress:
+
+# End of transcript or log.
+"""]]
+
+[[anarcat]]

devblog
diff --git a/doc/devblog/day_285__tuning_git-annex_unused_refs.mdwn b/doc/devblog/day_285__tuning_git-annex_unused_refs.mdwn
new file mode 100644
index 0000000..b5afaec
--- /dev/null
+++ b/doc/devblog/day_285__tuning_git-annex_unused_refs.mdwn
@@ -0,0 +1,20 @@
+Today I added a feature to `git annex unused` that lets the user tune which
+refs they are interested in using. Annexed objects that are used by other
+refs then are considered unused.
+
+Did a fairly complicated refspec format for this, with globs and
+include/exclude of refs. Example:
+
+	+refs/heads/*:+HEAD^:+refs/tags/*:-refs/tags/old-tag
+
+----
+
+I think that, since Google dropped openid support, there seems to have been
+less activity on this website. Although possibly also a higher signal to
+noise ratio. :) I have been working on some ikiwiki changes to make it
+easier for users who don't have an openid to contiribute. So git-annex's
+website should soon let you log in and make posts with just an email address.
+
+People sometimes ask for a git-annex mailing list. I wouldn't mind having
+one, and would certianly subscribe, but don't see any reason that I should
+be involved in running it.

add annex.used-refspec
diff --git a/Command/Unused.hs b/Command/Unused.hs
index a5698c8..c92ece2 100644
--- a/Command/Unused.hs
+++ b/Command/Unused.hs
@@ -53,7 +53,9 @@ seek = withNothing start
 {- Finds unused content in the annex. -} 
 start :: CommandStart
 start = do
-	!refspec <- maybe allRefSpec (either error id . parseRefSpec)
+	cfgrefspec <- fromMaybe allRefSpec . annexUsedRefSpec
+		<$> Annex.getGitConfig
+	!refspec <- maybe cfgrefspec (either error id . parseRefSpec)
 		<$> Annex.getField (optionName refSpecOption)
 	from <- Annex.getField (optionName unusedFromOption)
 	let (name, action) = case from of
diff --git a/Types/GitConfig.hs b/Types/GitConfig.hs
index c0043ec..aafd97c 100644
--- a/Types/GitConfig.hs
+++ b/Types/GitConfig.hs
@@ -22,6 +22,7 @@ import Types.Distribution
 import Types.Availability
 import Types.NumCopies
 import Types.Difference
+import Types.RefSpec
 import Utility.HumanTime
 
 {- Main git-annex settings. Each setting corresponds to a git-config key
@@ -59,6 +60,7 @@ data GitConfig = GitConfig
 	, coreSymlinks :: Bool
 	, gcryptId :: Maybe String
 	, annexDifferences :: Differences
+	, annexUsedRefSpec :: Maybe RefSpec
 	}
 
 extractGitConfig :: Git.Repo -> GitConfig
@@ -97,6 +99,8 @@ extractGitConfig r = GitConfig
 	, coreSymlinks = getbool "core.symlinks" True
 	, gcryptId = getmaybe "core.gcrypt-id"
 	, annexDifferences = getDifferences r
+	, annexUsedRefSpec = either (const Nothing) Just . parseRefSpec 
+		=<< getmaybe (annex "used-refspec")
 	}
   where
 	getbool k d = fromMaybe d $ getmaybebool k
diff --git a/debian/changelog b/debian/changelog
index cdb371b..c795196 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -18,8 +18,9 @@ git-annex (5.20150508.2) UNRELEASED; urgency=medium
     running at once.
   * Stale transfer lock and info files will be cleaned up automatically
     when get/unused/info commands are run.
-  * unused: Add --used option, which can specify a set of refs to consider
-    used, rather than the default of considering all refs used.
+  * unused: Add --used option and annex.used-refspec, which can specify
+    a set of refs to consider used, rather than the default of considering
+    all refs used.
 
  -- Joey Hess <id@joeyh.name>  Mon, 11 May 2015 12:45:06 -0400
 
diff --git a/doc/git-annex-unused.mdwn b/doc/git-annex-unused.mdwn
index fbb3719..22fac5b 100644
--- a/doc/git-annex-unused.mdwn
+++ b/doc/git-annex-unused.mdwn
@@ -36,7 +36,10 @@ For example, to move all unused data to origin:
   is not in the specified refs (and not used by the work tree) will then be
   considered unused.
 
-# REFSPEC
+  The git configuration annex.used-refspec can be used to configure
+  this in a more permanent fashion.
+
+# REFSPEC FORMAT
 
 The refspec format for --used-refspec is a colon-separated list of
 additions and removals of refs. For example:
diff --git a/doc/git-annex.mdwn b/doc/git-annex.mdwn
index 3dc54a3..3c2e344 100644
--- a/doc/git-annex.mdwn
+++ b/doc/git-annex.mdwn
@@ -813,6 +813,11 @@ Here are all the supported configuration settings.
   When importfeed is used, it stores additional metadata from the feed,
   such as the author, title, etc.
 
+* `annex.used-refspec`
+
+  This controls which refs `git-annex unused` considers to be used.
+  See REFSPEC FORMAT in [[git-annex-unused]](1) for details.
+
 * `annex.queuesize`
 
   git-annex builds a queue of git commands, in order to combine similar

unused: Add --used option, which can specify a set of refs to consider used, rather than the default of considering all refs used.
diff --git a/CmdLine/Usage.hs b/CmdLine/Usage.hs
index 82619a3..ad1d4e5 100644
--- a/CmdLine/Usage.hs
+++ b/CmdLine/Usage.hs
@@ -95,6 +95,8 @@ paramFile :: String
 paramFile = "FILE"
 paramRef :: String
 paramRef = "REF"
+paramRefSpec :: String
+paramRefSpec = "REFSPEC"
 paramGroup :: String
 paramGroup = "GROUP"
 paramExpression :: String
diff --git a/Command/Unused.hs b/Command/Unused.hs
index 4bbde4d..a5698c8 100644
--- a/Command/Unused.hs
+++ b/Command/Unused.hs
@@ -31,34 +31,41 @@ import qualified Remote
 import qualified Annex.Branch
 import Annex.CatFile
 import Types.Key
+import Types.RefSpec
 import Git.FilePath
 import Logs.View (is_branchView)
 import Utility.Bloom
 
 cmd :: [Command]
-cmd = [withOptions [unusedFromOption] $ command "unused" paramNothing seek
-	SectionMaintenance "look for unused file content"]
+cmd = [withOptions [unusedFromOption, refSpecOption] $
+	command "unused" paramNothing seek
+		SectionMaintenance "look for unused file content"]
 
 unusedFromOption :: Option
 unusedFromOption = fieldOption ['f'] "from" paramRemote "remote to check for unused content"
 
+refSpecOption :: Option
+refSpecOption = fieldOption [] "used-refspec" paramRefSpec "refs to consider used (default: all refs)"
+
 seek :: CommandSeek
 seek = withNothing start
 
 {- Finds unused content in the annex. -} 
 start :: CommandStart
 start = do
-	from <- Annex.getField $ optionName unusedFromOption
+	!refspec <- maybe allRefSpec (either error id . parseRefSpec)
+		<$> Annex.getField (optionName refSpecOption)
+	from <- Annex.getField (optionName unusedFromOption)
 	let (name, action) = case from of
-		Nothing -> (".", checkUnused)
-		Just "." -> (".", checkUnused)
-		Just "here" -> (".", checkUnused)
-		Just n -> (n, checkRemoteUnused n)
+		Nothing -> (".", checkUnused refspec)
+		Just "." -> (".", checkUnused refspec)
+		Just "here" -> (".", checkUnused refspec)
+		Just n -> (n, checkRemoteUnused n refspec)
 	showStart "unused" name
 	next action
 
-checkUnused :: CommandPerform
-checkUnused = chain 0
+checkUnused :: RefSpec -> CommandPerform
+checkUnused refspec = chain 0
 	[ check "" unusedMsg $ findunused =<< Annex.getState Annex.fast
 	, check "bad" staleBadMsg $ staleKeysPrune gitAnnexBadDir False
 	, check "tmp" staleTmpMsg $ staleKeysPrune gitAnnexTmpObjectDir True
@@ -71,20 +78,20 @@ checkUnused = chain 0
 		showAction "checking for unused data"
 		-- InAnnex, not InRepository because if a direct mode
 		-- file exists, it is obviously not unused.
-		excludeReferenced =<< getKeysPresent InAnnex
+		excludeReferenced refspec =<< getKeysPresent InAnnex
 	chain _ [] = next $ return True
 	chain v (a:as) = do
 		v' <- a v
 		chain v' as
 
-checkRemoteUnused :: String -> CommandPerform
-checkRemoteUnused name = go =<< fromJust <$> Remote.byNameWithUUID (Just name)
+checkRemoteUnused :: String -> RefSpec -> CommandPerform
+checkRemoteUnused name refspec = go =<< fromJust <$> Remote.byNameWithUUID (Just name)
   where
 	go r = do
 		showAction "checking for unused data"
 		_ <- check "" (remoteUnusedMsg r) (remoteunused r) 0
 		next $ return True
-	remoteunused r = excludeReferenced <=< loggedKeysFor $ Remote.uuid r
+	remoteunused r = excludeReferenced refspec <=< loggedKeysFor $ Remote.uuid r
 
 check :: FilePath -> ([(Int, Key)] -> String) -> Annex [Key] -> Int -> Annex Int
 check file msg a c = do
@@ -145,7 +152,7 @@ dropMsg' s = "\nTo remove unwanted data: git-annex dropunused" ++ s ++ " NUMBER\
  - * Build a bloom filter of all keys referenced by symlinks. This 
  -   is the fastest one to build and will filter out most keys.
  - * If keys remain, build a second bloom filter of keys referenced by
- -   all branches.
+ -   branches maching the RefSpec.
  - * The list is streamed through these bloom filters lazily, so both will
  -   exist at the same time. This means that twice the memory is used,
  -   but they're relatively small, so the added complexity of using a
@@ -157,13 +164,13 @@ dropMsg' s = "\nTo remove unwanted data: git-annex dropunused" ++ s ++ " NUMBER\
  -   Short-circuiting if the first filter filters all the keys handles the
  -   other common case.
  -}
-excludeReferenced :: [Key] -> Annex [Key]
-excludeReferenced ks = runfilter firstlevel ks >>= runfilter secondlevel
+excludeReferenced :: RefSpec -> [Key] -> Annex [Key]
+excludeReferenced refspec ks = runfilter firstlevel ks >>= runfilter secondlevel
   where
 	runfilter _ [] = return [] -- optimisation
 	runfilter a l = bloomFilter show l <$> genBloomFilter show a
 	firstlevel = withKeysReferencedM
-	secondlevel = withKeysReferencedInGit
+	secondlevel = withKeysReferencedInGit refspec
 
 {- Finds items in the first, smaller list, that are not
  - present in the second, larger list.
@@ -258,14 +265,15 @@ withKeysReferenced' mdir initial a = do
 				!v' <- a k f v
 				go v' fs
 
-withKeysReferencedInGit :: (Key -> Annex ()) -> Annex ()
-withKeysReferencedInGit a = do
+withKeysReferencedInGit :: RefSpec -> (Key -> Annex ()) -> Annex ()
+withKeysReferencedInGit refspec a = do
 	current <- inRepo Git.Branch.currentUnsafe
 	shaHead <- maybe (return Nothing) (inRepo . Git.Ref.sha) current
-	showref >>= mapM_ (withKeysReferencedInGitRef a) .
-			relevantrefs (shaHead, current)
+	usedrefs <- applyRefSpec refspec . relevantrefs (shaHead, current)
+		<$> inRepo (Git.Command.pipeReadStrict [Param "show-ref"])
+	forM_ usedrefs $
+		withKeysReferencedInGitRef a
   where
-	showref = inRepo $ Git.Command.pipeReadStrict [Param "show-ref"]
 	relevantrefs headRef = addHead headRef .
 		filter ourbranches .
 		map (separate (== ' ')) .
@@ -293,8 +301,8 @@ withKeysReferencedInGitRef a ref = do
 	showAction $ "checking " ++ Git.Ref.describe ref
 	bare <- isBareRepo
 	(ts,clean) <- inRepo $ if bare
-			then DiffTree.diffIndex ref
-			else DiffTree.diffWorkTree ref
+		then DiffTree.diffIndex ref
+		else DiffTree.diffWorkTree ref
 	let lookAtWorkingTree = not bare && ref == Git.Ref.headRef
 	forM_ ts $ tKey lookAtWorkingTree >=> maybe noop a
 	liftIO $ void clean
diff --git a/Types/RefSpec.hs b/Types/RefSpec.hs
new file mode 100644
index 0000000..42f4c62
--- /dev/null
+++ b/Types/RefSpec.hs
@@ -0,0 +1,44 @@
+{- This is not the same as git's fetch/push refspecs.
+ - 
+ - Copyright 2015 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU GPL version 3 or higher.
+ -}
+
+module Types.RefSpec where
+
+import Common
+import Utility.Glob
+import Git.Types
+
+import Data.Either
+
+type RefSpec = [RefSpecPart]
+
+data RefSpecPart = AddRef Ref | AddMatching Glob | RemoveMatching Glob
+
+allRefSpec :: RefSpec
+allRefSpec = [AddMatching $ compileGlob "*" CaseSensative]
+
+parseRefSpec :: String -> Either String RefSpec
+parseRefSpec v = case partitionEithers (map mk $ split ":" v) of
+	([],refspec) -> Right refspec
+	(e:_,_) -> Left e
+  where
+	mk ('+':s)
+		| any (`elem` s) "*?" =
+			Right $ AddMatching $ compileGlob s CaseSensative
+		| otherwise = Right $ AddRef $ Ref s
+	mk ('-':s) = Right $ RemoveMatching $ compileGlob s CaseSensative
+	mk s = Left $ "bad refspec item \"" ++ s ++ "\" (expected + or - prefix)"
+
+applyRefSpec :: RefSpec -> [Ref] -> [Ref]
+applyRefSpec refspec rs = go [] refspec
+  where
+	go c [] = reverse c
+	go c (AddRef r : rest) = go (r:c) rest
+	go c (AddMatching g : rest) =
+		let add = filter (matchGlob g . fromRef) rs
+		in go (add ++ c) rest
+	go c (RemoveMatching g : rest) = 

(Diff truncated)
more formal spec
diff --git a/doc/todo/unused_by_refspec.mdwn b/doc/todo/unused_by_refspec.mdwn
index 20b9177..7814252 100644
--- a/doc/todo/unused_by_refspec.mdwn
+++ b/doc/todo/unused_by_refspec.mdwn
@@ -17,11 +17,20 @@ departure. Let's allow wildcards as it does, and use leading '+' to add a
 ref, and '-' to remove. Let the user specify multiple such expressions,
 separated by ':'.
 
-	+refs/heads/*:-refs/remotes/*:+refs/tags/*:-refs/tags/old-tag
+	+refs/heads/*:+HEAD^:+refs/tags/*:-refs/tags/old-tag
 
-Note that this needs to be processed by taking all refs matching any '+',
-and then removing any of those that match any '-'
+This is processed by starting with an empty set of refs, and walking the
+refspec in order. 
 
-Also, allow use of HEAD, and anything else that `git show-ref` can handle.
+* Each + is matched against all known refs (from `git show-ref`), and adds
+  everything it matches to the set. If the + does not contain a wildcard,
+  it is literally added to the set, rather than looking in the known refs.
+  This allows "+refs/heads/*" to match all heads, and "+HEAD"
+  to match HEAD, or even "+sha" to match a given SHA, or "+HEAD^" to match
+  the previous head.
+* Each - is matched against the contents of the set, and removes everything
+  it matches, using a lexographic matching with wildcards (not looking at
+  the SHAs that the refs point to, so -refs/heads/master does not remove
+  +HEAD).
 
 --[[Joey]]

Added a comment
diff --git a/doc/todo/unused_by_refspec/comment_1_4612b5f485b313d59eb51bb519eb9471._comment b/doc/todo/unused_by_refspec/comment_1_4612b5f485b313d59eb51bb519eb9471._comment
new file mode 100644
index 0000000..44cc307
--- /dev/null
+++ b/doc/todo/unused_by_refspec/comment_1_4612b5f485b313d59eb51bb519eb9471._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="https://me.yahoo.com/a/EbvxpTI_xP9Aod7Mg4cwGhgjrCrdM5s-#7c0f4"
+ subject="comment 1"
+ date="2015-05-14T16:17:08Z"
+ content="""
+since, if I got it right, I will be able to point to any treeish (or collection of those), I should be able to implement any strategy in mind (e.g. for upgrade drop all not referenced in master, or even its HEAD and HEAD^ to allow a quick roll back).  So sounds good to me -- thanks joey!
+"""]]

Added a comment: confirmed
diff --git a/doc/bugs/git-annex-shell_doesn__39__t_work_as_expected/comment_3_b4b8f2c595a1add70c176cf51d27b72a._comment b/doc/bugs/git-annex-shell_doesn__39__t_work_as_expected/comment_3_b4b8f2c595a1add70c176cf51d27b72a._comment
new file mode 100644
index 0000000..9e35f34
--- /dev/null
+++ b/doc/bugs/git-annex-shell_doesn__39__t_work_as_expected/comment_3_b4b8f2c595a1add70c176cf51d27b72a._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="anarcat"
+ subject="confirmed"
+ date="2015-05-14T15:50:32Z"
+ content="""
+so this is confirmed: i had git-annex installed from packages, and git-annex in /opt/bin/, installed using the standalone binary. `~/.config/git-annex/program` points to the latter, `$PATH` to the former.
+
+really confusing bug... removing the package works around the issue.
+"""]]

Added a comment
diff --git a/doc/forum/Symlink_points_to_old_version/comment_2_9bf097d27a64743a420cba0136787165._comment b/doc/forum/Symlink_points_to_old_version/comment_2_9bf097d27a64743a420cba0136787165._comment
new file mode 100644
index 0000000..7563a1e
--- /dev/null
+++ b/doc/forum/Symlink_points_to_old_version/comment_2_9bf097d27a64743a420cba0136787165._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://me.yahoo.com/a/StKYI.ZuofVB3xNCCzjJo.V7Fg--#11600"
+ nickname="Per K"
+ subject="comment 2"
+ date="2015-05-14T09:31:09Z"
+ content="""
+Thank you for the response. Sorry I didn't think of the possibility that the PDF reader could be the problem. I have done the same operation many times and never encountered this problem before though. The culprit is Apple's Preview.app. It now shows the new version and to my knowledge I haven't done anything in the meantime. Guess it is just time passed that has fixed \"the problem\".
+
+Thank you!
+"""]]

Added a comment: transcript
diff --git a/doc/bugs/git-annex_unused_--from_s3_doesn__39__t/comment_2_b624d895c85f1595dcb0872c88fb4e30._comment b/doc/bugs/git-annex_unused_--from_s3_doesn__39__t/comment_2_b624d895c85f1595dcb0872c88fb4e30._comment
new file mode 100644
index 0000000..f48429e
--- /dev/null
+++ b/doc/bugs/git-annex_unused_--from_s3_doesn__39__t/comment_2_b624d895c85f1595dcb0872c88fb4e30._comment
@@ -0,0 +1,110 @@
+[[!comment format=mdwn
+ username="skew"
+ subject="transcript"
+ date="2015-05-14T04:37:33Z"
+ content="""
+Hey Joey, after playing around a bit more, I noticed that the behavior was happening when I'm in a subdirectory, but not when I'm in the root of the repo. I also managed to reproduce the issue with a new repo (and a different type of remote):
+
+[[!format txt \"\"\"
+[john@laptop tmp]$ git init annextest3
+Initialized empty Git repository in /home/john/tmp/annextest3/.git/
+[john@laptop tmp]$ cd annextest3/
+[john@laptop annextest3]$ git annex init laptop
+init laptop ok
+(Recording state in git...)
+[john@laptop annextest3]$ git annex initremote rsyncnet type=rsync rsyncurl=user@server.rsync.net:/path/to/annextest3 encryption=none
+initremote rsyncnet ok
+(Recording state in git...)
+[john@laptop annextest3]$ mkdir docs
+[john@laptop annextest3]$ echo \"first version\" > docs/test.txt
+[john@laptop annextest3]$ git annex add docs/test.txt
+add docs/test.txt ok
+(Recording state in git...)
+[john@laptop annextest3]$ git annex sync --content
+commit  ok
+copy docs/test.txt copy docs/test.txt (checking rsyncnet...) (to rsyncnet...) 
+sending incremental file list
+./
+1a5/
+1a5/235/
+1a5/235/SHA256E-s14--0533c80dc85756cf8cd5181e68d6520f5ffc4585def452d26f59756a5c2548b1.txt/
+1a5/235/SHA256E-s14--0533c80dc85756cf8cd5181e68d6520f5ffc4585def452d26f59756a5c2548b1.txt/SHA256E-s14--0533c80dc85756cf8cd5181e68d6520f5ffc4585def452d26f59756a5c2548b1.txt
+             14 100%    0.00kB/s    0:00:00 (xfr#1, to-chk=0/5)
+ok
+(Recording state in git...)
+[john@laptop annextest3]$ git annex whereis
+whereis docs/test.txt (2 copies) 
+  	139b18e5-1fd0-4144-a551-4e997333b8ae -- [rsyncnet]
+   	7187a4c5-d9ae-471d-9b4b-843c37bfb3c3 -- laptop [here]
+ok
+[john@laptop annextest3]$ git annex unlock docs/test.txt
+unlock docs/test.txt (copying...) ok
+[john@laptop annextest3]$ echo \"second version\" > docs/test.txt 
+[john@laptop annextest3]$ git annex add docs/test.txt
+add docs/test.txt ok
+(Recording state in git...)
+[john@laptop annextest3]$ git annex sync --content
+commit  ok
+copy docs/test.txt copy docs/test.txt (checking rsyncnet...) (to rsyncnet...) 
+sending incremental file list
+6ad/
+6ad/09f/
+6ad/09f/SHA256E-s15--66ed1142ab3b2f1cdb29e8b81c9471444a5d9e6fb657a54d089073ab8bd34e27.txt/
+6ad/09f/SHA256E-s15--66ed1142ab3b2f1cdb29e8b81c9471444a5d9e6fb657a54d089073ab8bd34e27.txt/SHA256E-s15--66ed1142ab3b2f1cdb29e8b81c9471444a5d9e6fb657a54d089073ab8bd34e27.txt
+             15 100%    0.00kB/s    0:00:00 (xfr#1, to-chk=0/5)
+ok
+(Recording state in git...)
+[john@laptop annextest3]$ git annex unused
+unused . (checking for unused data...) (checking master...) 
+  Some annexed data is no longer used by any files:
+    NUMBER  KEY
+    1       SHA256E-s14--0533c80dc85756cf8cd5181e68d6520f5ffc4585def452d26f59756a5c2548b1.txt
+  (To see where data was previously used, try: git log --stat -S'KEY')
+  
+  To remove unwanted data: git-annex dropunused NUMBER
+  
+ok
+[john@laptop annextest3]$ git annex unused --from rsyncnet
+unused rsyncnet (checking for unused data...) (checking master...) 
+  Some annexed data on rsyncnet is not used by any files:
+    NUMBER  KEY
+    1       SHA256E-s14--0533c80dc85756cf8cd5181e68d6520f5ffc4585def452d26f59756a5c2548b1.txt
+  (To see where data was previously used, try: git log --stat -S'KEY')
+  
+  To remove unwanted data: git-annex dropunused --from rsyncnet NUMBER
+  
+ok
+[john@laptop annextest3]$ cd docs/
+[john@laptop docs]$ git annex unused
+unused . (checking for unused data...) (checking master...) 
+  Some annexed data is no longer used by any files:
+    NUMBER  KEY
+    1       SHA256E-s14--0533c80dc85756cf8cd5181e68d6520f5ffc4585def452d26f59756a5c2548b1.txt
+  (To see where data was previously used, try: git log --stat -S'KEY')
+  
+  To remove unwanted data: git-annex dropunused NUMBER
+  
+ok
+[john@laptop docs]$ git annex unused --from rsyncnet
+unused rsyncnet (checking for unused data...) ok
+[john@laptop docs]$ git annex whereis --unused
+[john@laptop docs]$ cd ..
+[john@laptop annextest3]$ git annex whereis --unused
+[john@laptop annextest3]$ git annex unused
+unused . (checking for unused data...) (checking master...) 
+  Some annexed data is no longer used by any files:
+    NUMBER  KEY
+    1       SHA256E-s14--0533c80dc85756cf8cd5181e68d6520f5ffc4585def452d26f59756a5c2548b1.txt
+  (To see where data was previously used, try: git log --stat -S'KEY')
+  
+  To remove unwanted data: git-annex dropunused NUMBER
+  
+ok
+[john@laptop annextest3]$ git annex whereis --unused
+whereis SHA256E-s14--0533c80dc85756cf8cd5181e68d6520f5ffc4585def452d26f59756a5c2548b1.txt (2 copies) 
+  	139b18e5-1fd0-4144-a551-4e997333b8ae -- [rsyncnet]
+   	7187a4c5-d9ae-471d-9b4b-843c37bfb3c3 -- laptop [here]
+ok
+[john@laptop annextest3]$
+\"\"\"]]
+"""]]

response
diff --git a/doc/forum/Symlink_points_to_old_version/comment_1_c9c777333a01865e95332ea7ff1e6cf7._comment b/doc/forum/Symlink_points_to_old_version/comment_1_c9c777333a01865e95332ea7ff1e6cf7._comment
new file mode 100644
index 0000000..febe4c9
--- /dev/null
+++ b/doc/forum/Symlink_points_to_old_version/comment_1_c9c777333a01865e95332ea7ff1e6cf7._comment
@@ -0,0 +1,41 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-05-13T15:46:00Z"
+ content="""
+The symlink should point to the new version, unless git-annex is catastropically
+broken, and this can be easily demonstrated that git-annex is not catastropically
+broken:
+
+	joey@darkstar:~/tmp/demo>cat foo.pdf 
+	original pdf
+	joey@darkstar:~/tmp/demo>git annex edit foo.pdf
+	unlock foo.pdf (copying...) ok
+	joey@darkstar:~/tmp/demo>echo "added page" >> foo.pdf 
+	joey@darkstar:~/tmp/demo>git annex add foo.pdf
+	add foo.pdf ok
+	(recording state in git...)
+	joey@darkstar:~/tmp/demo>git commit -m foo
+	[master 8d7f117] foo
+	 1 file changed, 1 insertion(+), 1 deletion(-)
+	joey@darkstar:~/tmp/demo>cat foo.pdf 
+	original pdf
+	added page
+
+So, what's really going on for you to see what you see when you look at the
+pdf? My guess is that your pdf editor/viewer is doing something bad/smart when
+it encounters the symlink. Perhaps it's loading an old cached version of the
+pdf rather than following the symlink or something.
+
+When you use `git annex edit`, the file stops being a symlink, and
+so whatever smart/bad behavior is causing the problem is avoided.
+
+If this is the case, switching to direct mode would avoid the problem.
+(`git annex direct`)
+
+If I were using a program and verfied that it has such bad/smart behavior
+on symlinks, I'd complain vigorously to its creators; it should't matter
+if a program is asked to open a symlink or not, it should behave the same either way.
+Unfortunately, it seems that some programs go out of their way to get
+this wrong and all we can do about it is filed bugs and/or use direct mode.
+"""]]

design
diff --git a/doc/todo/unused_by_refspec.mdwn b/doc/todo/unused_by_refspec.mdwn
new file mode 100644
index 0000000..20b9177
--- /dev/null
+++ b/doc/todo/unused_by_refspec.mdwn
@@ -0,0 +1,27 @@
+Currently `git annex unused` assumes that all branches (including remote
+tracking branches) and tags are "used" and finds only objects not used by
+any of those refs.
+
+That's a reasonable default, but in some cases, we don't care about
+specific refs. Perhaps we don't consider remote tracking branches
+important. Or perhaps we only want objects in HEAD to be considered used.
+
+This could be handled by adding an option to specify a refspec when running
+git-annex unused. Only matching refs would be checked. It's probably worth
+making this be both a command-line option --used-refspec, as well as a
+annex.used-refspec config setting.
+
+git's refspec format is not quite right (since it specifies a local side
+and a remote side for push/pull). But, it can be used as a point of
+departure. Let's allow wildcards as it does, and use leading '+' to add a
+ref, and '-' to remove. Let the user specify multiple such expressions,
+separated by ':'.
+
+	+refs/heads/*:-refs/remotes/*:+refs/tags/*:-refs/tags/old-tag
+
+Note that this needs to be processed by taking all refs matching any '+',
+and then removing any of those that match any '-'
+
+Also, allow use of HEAD, and anything else that `git show-ref` can handle.
+
+--[[Joey]]

update
diff --git a/doc/devblog/day_284__development.mdwn b/doc/devblog/day_284__development.mdwn
index 1204d3e..7ecf684 100644
--- a/doc/devblog/day_284__development.mdwn
+++ b/doc/devblog/day_284__development.mdwn
@@ -23,3 +23,11 @@ assistant is not being used. Looked into also cleaning up stale
 .git/annex/transfer/{upload,download}/ files (from interrupted transfers).
 But, since those are used as lock files, it's difficult to remove them
 in a concurrency safe way.
+
+Update: Unfortunately, I turned out to have stumbled over an apparent bug
+in haskell's implementation of file locking.
+<https://github.com/haskell/unix/issues/44> Had to work around that.
+
+Happily, the workaround also let me implement cleanup of stale transfer
+info files, left behind when a git-annex process was interrupted. So,
+.git/annex/transfer/ will entirely stop accumulating cruft!

Stale transfer lock and info files will be cleaned up automatically when get/unused/info commands are run.
Deleting lock files is tricky, tricky stuff. I think I got it right!
diff --git a/Annex/Transfer.hs b/Annex/Transfer.hs
index d8f19eb..2511ae4 100644
--- a/Annex/Transfer.hs
+++ b/Annex/Transfer.hs
@@ -71,7 +71,7 @@ runTransfer' ignorelock t file shouldretry transferobserver transferaction = do
 	(lck, inprogress) <- liftIO $ prep tfile mode info
 	if inprogress && not ignorelock
 		then do
-			showNote "transfer already in progress"
+			showNote "transfer already in progress, or unable to take transfer lock"
 			return False
 		else do
 			ok <- retry info metervar $ transferaction meter
diff --git a/Logs/Transfer.hs b/Logs/Transfer.hs
index 0ee69b6..69b1603 100644
--- a/Logs/Transfer.hs
+++ b/Logs/Transfer.hs
@@ -123,17 +123,35 @@ startTransferInfo file = TransferInfo
 	<*> pure file
 	<*> pure False
 
-{- If a transfer is still running, returns its TransferInfo. -}
+{- If a transfer is still running, returns its TransferInfo.
+ - 
+ - If no transfer is running, attempts to clean up the stale
+ - lock and info files. This can happen if a transfer process was
+ - interrupted.
+ -}
 checkTransfer :: Transfer -> Annex (Maybe TransferInfo)
 checkTransfer t = do
 	tfile <- fromRepo $ transferFile t
+	let cleanstale = do
+		void $ tryIO $ removeFile tfile
+		void $ tryIO $ removeFile $ transferLockFile tfile
 #ifndef mingw32_HOST_OS
 	liftIO $ do
-		v <- getLockStatus (transferLockFile tfile)
+		let lck = transferLockFile tfile
+		v <- getLockStatus lck
 		case v of
 			Just (pid, _) -> catchDefaultIO Nothing $
 				readTransferInfoFile (Just pid) tfile
-			Nothing -> return Nothing
+			Nothing -> do
+				-- Take a non-blocking lock while deleting
+				-- the stale lock file.
+				r <- tryLockExclusive Nothing lck
+				case r of
+					Just lockhandle -> do
+						cleanstale
+						dropLock lockhandle
+					_ -> noop
+				return Nothing
 #else
 	v <- liftIO $ lockShared $ transferLockFile tfile
 	liftIO $ case v of
@@ -141,7 +159,7 @@ checkTransfer t = do
 			readTransferInfoFile Nothing tfile
 		Just lockhandle -> do
 			dropLock lockhandle
-			void $ tryIO $ removeFile $ transferLockFile tfile
+			cleanstale
 			return Nothing
 #endif
 
diff --git a/debian/changelog b/debian/changelog
index 746706b..6b5c8df 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -16,6 +16,8 @@ git-annex (5.20150508.2) UNRELEASED; urgency=medium
     being used.
   * Fix an unlikely race that could result in two transfers of the same key
     running at once.
+  * Stale transfer lock and info files will be cleaned up automatically
+    when get/unused/info commands are run.
 
  -- Joey Hess <id@joeyh.name>  Mon, 11 May 2015 12:45:06 -0400
 
diff --git a/doc/bugs/transfer_lock_file_removal_bug.mdwn b/doc/bugs/transfer_lock_file_removal_bug.mdwn
index ca698b2..021ce08 100644
--- a/doc/bugs/transfer_lock_file_removal_bug.mdwn
+++ b/doc/bugs/transfer_lock_file_removal_bug.mdwn
@@ -33,3 +33,29 @@ Oh BTW, this race cannot happen on windows, since on windows, an open lock
 file cannot be deleted by another process.
 
 > [[fixed|done]]
+
+Let's also consider if this change will allow for safely expiring stale 
+lock files..
+
+Situation before with expiry would have been buggy (which is why it never
+tried to expire them):
+
+1. first process creates lock file, takes lock, is interrupted (no more
+   lock)
+2. second process wants to delete stale lock file; checks if it's locked;
+   isn't
+3. third process opens existing lock file, prepares to take lock
+4. second process deletes lock file
+5. third process takes lock
+6. third process is now doing a transfer w/o a (visible) lock
+
+But, after this bug fix, the third process checks if it's lock file
+exists after taking the lock. Since the second process deleted it,
+the third process fails with an error "transfer in progress"
+which is perhaps not accurate, but at least it stopped.
+
+For this to work though, the second process needs to actually take
+the lock, in non-blocking mode. If it succeeds, it can keep the lock
+held while deleting the lock file. This ensures that when the third process
+takes the lock, the lock file will already be deleted by the time it checks
+if it's there.

Fix an unlikely race that could result in two transfers of the same key running at once.
As discussed in bug report.
diff --git a/Annex/Transfer.hs b/Annex/Transfer.hs
index 1d7f2b9..14a8886 100644
--- a/Annex/Transfer.hs
+++ b/Annex/Transfer.hs
@@ -87,9 +87,12 @@ runTransfer' ignorelock t file shouldretry transferobserver transferaction = do
 		r <- tryLockExclusive (Just mode) lck
 		case r of
 			Nothing -> return (Nothing, True)
-			Just lockhandle -> do
+			Just lockhandle -> ifM (checkSaneLock lck lockhandle)
+				( do
 					void $ tryIO $ writeTransferInfoFile info tfile
 					return (Just lockhandle, False)
+				, return (Nothing, True)
+				)
 #else
 	prep tfile _mode info = do
 		let lck = transferLockFile tfile
diff --git a/Utility/LockFile/Posix.hs b/Utility/LockFile/Posix.hs
index a5775db..9013bd3 100644
--- a/Utility/LockFile/Posix.hs
+++ b/Utility/LockFile/Posix.hs
@@ -16,6 +16,7 @@ module Utility.LockFile.Posix (
 	checkLocked,
 	getLockStatus,
 	dropLock,
+	checkSaneLock,
 ) where
 
 import Utility.Exception
@@ -97,3 +98,17 @@ getLockStatus' lockfile = go =<< catchMaybeIO open
 
 dropLock :: LockHandle -> IO ()
 dropLock (LockHandle fd) = closeFd fd
+
+-- Checks that the lock file still exists, and is the same file that was
+-- locked to get the LockHandle.
+--
+-- This check is useful if the lock file might get deleted by something
+-- else.
+checkSaneLock :: LockFile -> LockHandle -> IO Bool
+checkSaneLock lockfile (LockHandle fd) =
+	go =<< catchMaybeIO (getFileStatus lockfile)
+  where
+	go Nothing = return False
+	go (Just st) = do
+		fdst <- getFdStatus fd
+		return $ deviceID fdst == deviceID st && fileID fdst == fileID st
diff --git a/debian/changelog b/debian/changelog
index ef62eaf..746706b 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -14,6 +14,8 @@ git-annex (5.20150508.2) UNRELEASED; urgency=medium
     checking annex.diskreserve.
   * Avoid accumulating transfer failure log files unless the assistant is
     being used.
+  * Fix an unlikely race that could result in two transfers of the same key
+    running at once.
 
  -- Joey Hess <id@joeyh.name>  Mon, 11 May 2015 12:45:06 -0400
 
diff --git a/doc/bugs/transfer_lock_file_removal_bug.mdwn b/doc/bugs/transfer_lock_file_removal_bug.mdwn
new file mode 100644
index 0000000..ca698b2
--- /dev/null
+++ b/doc/bugs/transfer_lock_file_removal_bug.mdwn
@@ -0,0 +1,35 @@
+There's a race that can result in 2 concurrent downloads
+of the same key. This can happen because the transfer lock files get
+deleted after a transfer completes.
+
+Scenario:
+
+1. first process creates lock file, takes lock, starts download
+2. second process opens existing lock file
+3. first process finishes/fails download, so deletes lock file, and then
+   drops lock
+4. second process takes lock (exclusive, non-blocking) of deleted file!
+5. third process sees no lock file, so creates a new one, takes lock,
+   starts download
+
+Worst-case, this might result in data loss, if the two concurrent
+downloaders confuse one-another. Perhaps the second one overwrites the file
+the first was downloading, and then the first, thinking it's written the
+file, moves it into the object directory.
+
+Note that the window between 4-5 can be as long as it takes for a
+file to download. However, the window between 2-4 is very narrow indeed,
+since the second process is not blocking on the lock.
+So, this is very unlikely to happen.
+
+But, it could. Can it be prevented?
+
+Yes: The second process, after taking the lock, can check that
+the lock file exists, and has the same dev and fileno as the fd it has
+locked. If the lock file doesn't exist, or is different, then the
+second process can give up.
+
+Oh BTW, this race cannot happen on windows, since on windows, an open lock
+file cannot be deleted by another process.
+
+> [[fixed|done]]

devblog
diff --git a/doc/devblog/day_284__development.mdwn b/doc/devblog/day_284__development.mdwn
new file mode 100644
index 0000000..1204d3e
--- /dev/null
+++ b/doc/devblog/day_284__development.mdwn
@@ -0,0 +1,25 @@
+Implemented `git annex drop --all`. This also added for free drop with
+`--unused` and `--key`, which overlap with `git annexdropunused` and
+`git annex dropkey`.
+
+The `concurrentprogress` branch had gone too long without being merged, and
+had a lot of merge conflicts. I resolved those, and went ahead and merged
+it into master. However, since the ascii-progress library is not ready yet,
+I made it a build flag, and it will build without it by default. So, `git
+annex get -J5` can be used now, but no progress bars will display yet.
+
+When doing concurrent downloads, either with the new -J or by hand by
+running multiple processes, there was a bug in the diskreserve
+checking code. It didn't consider the disk space that was in the process of
+being used by other concurrent downloads, so would let more downloads
+start up than there was space for.
+
+I was able to fix this pretty easily, thanks to the transfer log files.
+Those were originally added just to let the webapp display transfers, but
+proved very helpful here!
+
+Finally, made .git/annex/transfer/failed/ files stop accumulating when the
+assistant is not being used. Looked into also cleaning up stale
+.git/annex/transfer/{upload,download}/ files (from interrupted transfers).
+But, since those are used as lock files, it's difficult to remove them
+in a concurrency safe way.

update
diff --git a/doc/todo/parallel_get.mdwn b/doc/todo/parallel_get.mdwn
index d2d865f..9aa229a 100644
--- a/doc/todo/parallel_get.mdwn
+++ b/doc/todo/parallel_get.mdwn
@@ -76,3 +76,6 @@ See also: [[parallel_possibilities]]
 > It has nice support for multiple progress bars, and is portable.
 > I have filed 7 issues on it, around 4 of which need to get fixed before
 > it's suitable for git-annex to use.. --[[Joey]]
+
+>> `git annex get -JN` works now, but lacks any progress display.
+>> Waiting on some updates to ascii-progress. --[[Joey]]

Merge branch 'master' into concurrentprogress
Conflicts:
Command/Fsck.hs
Messages.hs
Remote/Directory.hs
Remote/Git.hs
Remote/Helper/Special.hs
Types/Remote.hs
debian/changelog
git-annex.cabal
drop: Now supports --all, --unused, and --key.
diff --git a/Command/Drop.hs b/Command/Drop.hs
index a3ac876..698dd7b 100644
--- a/Command/Drop.hs
+++ b/Command/Drop.hs
@@ -27,7 +27,7 @@ cmd = [withOptions (dropOptions) $ command "drop" paramPaths seek
 	SectionCommon "indicate content of files not currently wanted"]
 
 dropOptions :: [Option]
-dropOptions = dropFromOption : annexedMatchingOptions ++ [autoOption]
+dropOptions = dropFromOption : annexedMatchingOptions ++ [autoOption] ++ keyOptions
 
 dropFromOption :: Option
 dropFromOption = fieldOption ['f'] "from" paramRemote "drop content from a remote"
@@ -36,23 +36,32 @@ seek :: CommandSeek
 seek ps = do
 	from <- getOptionField dropFromOption Remote.byNameWithUUID
 	auto <- getOptionFlag autoOption
-	withFilesInGit (whenAnnexed $ start auto from) ps
+	withKeyOptions auto
+		(startKeys auto from)
+		(withFilesInGit $ whenAnnexed $ start auto from)
+		ps
 
 start :: Bool -> Maybe Remote -> FilePath -> Key -> CommandStart
-start auto from file key = checkDropAuto auto from file key $ \numcopies ->
+start auto from file key = start' auto from key (Just file)
+
+start' :: Bool -> Maybe Remote -> Key -> AssociatedFile -> CommandStart
+start' auto from key afile = checkDropAuto auto from afile key $ \numcopies ->
 	stopUnless want $
 		case from of
-			Nothing -> startLocal (Just file) numcopies key Nothing
+			Nothing -> startLocal afile numcopies key Nothing
 			Just remote -> do
 				u <- getUUID
 				if Remote.uuid remote == u
-					then startLocal (Just file) numcopies key Nothing
-					else startRemote (Just file) numcopies key remote
+					then startLocal afile numcopies key Nothing
+					else startRemote afile numcopies key remote
   where
 	want
-		| auto = wantDrop False (Remote.uuid <$> from) (Just key) (Just file)
+		| auto = wantDrop False (Remote.uuid <$> from) (Just key) afile
 		| otherwise = return True
 
+startKeys :: Bool -> Maybe Remote -> Key -> CommandStart
+startKeys auto from key = start' auto from key Nothing
+
 startLocal :: AssociatedFile -> NumCopies -> Key -> Maybe Remote -> CommandStart
 startLocal afile numcopies key knownpresentremote = stopUnless (inAnnex key) $ do
 	showStart' "drop" key afile
@@ -154,8 +163,8 @@ requiredContent = do
 
 {- In auto mode, only runs the action if there are enough
  - copies on other semitrusted repositories. -}
-checkDropAuto :: Bool -> Maybe Remote -> FilePath -> Key -> (NumCopies -> CommandStart) -> CommandStart
-checkDropAuto auto mremote file key a = go =<< getFileNumCopies file
+checkDropAuto :: Bool -> Maybe Remote -> AssociatedFile -> Key -> (NumCopies -> CommandStart) -> CommandStart
+checkDropAuto auto mremote afile key a = go =<< maybe getNumCopies getFileNumCopies afile
   where
 	go numcopies
 		| auto = do
diff --git a/debian/changelog b/debian/changelog
index 58921d5..6b3dfb3 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -2,6 +2,7 @@ git-annex (5.20150508.2) UNRELEASED; urgency=medium
 
   * import: Refuse to import files that are within the work tree, as that
     does not make sense and could cause data loss.
+  * drop: Now supports --all, --unused, and --key.
 
  -- Joey Hess <id@joeyh.name>  Mon, 11 May 2015 12:45:06 -0400
 
diff --git a/doc/git-annex-drop.mdwn b/doc/git-annex-drop.mdwn
index 3fd1346..c19a716 100644
--- a/doc/git-annex-drop.mdwn
+++ b/doc/git-annex-drop.mdwn
@@ -35,6 +35,21 @@ safe to do so.
   the last repository that is storing their content. Data loss can
   result from using this option.
 
+* `--all`
+
+  Rather than specifying a filename or path to drop, this option can be
+  used to drop all available versions of all files.
+
+  This is the default behavior when running git-annex drop in a bare repository.
+
+* `--unused`
+
+  Drop files found by last run of git-annex unused.
+
+* `--key=keyname`
+
+  Use this option to drop a specified key.
+
 * file matching options
 
   The [[git-annex-matching-options]](1)

diff --git a/doc/forum/Symlink_points_to_old_version.mdwn b/doc/forum/Symlink_points_to_old_version.mdwn
new file mode 100644
index 0000000..257a7d5
--- /dev/null
+++ b/doc/forum/Symlink_points_to_old_version.mdwn
@@ -0,0 +1,13 @@
+Hello everyone,
+
+I have some PDF documents in a git annex repository. I appended a page to (several) of these PDF documents the following way:
+
+- `git annex edit file.pdf`
+- Append page to file.pdf
+- `git annex add file.pdf`
+- `git commit`
+
+If I now look at file.pdf it will not have the appended page. But if do `git annex edit file.pdf` again I will get the version with the appended page. `git annex add file.pdf` and the page "disappears" again. Anyone got any tips on how to solve this "mystery"?
+
+All the best,
+Per

Added a comment: Create symlink in the root directory
diff --git a/doc/forum/Multiple_repos_on_same_path/comment_1_67ed823c4c40f5acf12b48eb75d7afa8._comment b/doc/forum/Multiple_repos_on_same_path/comment_1_67ed823c4c40f5acf12b48eb75d7afa8._comment
new file mode 100644
index 0000000..5ab93d9
--- /dev/null
+++ b/doc/forum/Multiple_repos_on_same_path/comment_1_67ed823c4c40f5acf12b48eb75d7afa8._comment
@@ -0,0 +1,32 @@
+[[!comment format=mdwn
+ username="https://sunny256.wordpress.com/"
+ nickname="sunny256"
+ subject="Create symlink in the root directory"
+ date="2015-05-12T13:04:18Z"
+ content="""
+My way of dealing with this is to create a symlink in the root directory that point to the root directory, like
+
+[[!format sh \"\"\"
+$ cd /
+$ sudo ln -sv . compname
+[sudo] password for sunny: hunter2
+'compname' -> '.'
+$ ls -l compname
+lrwxrwxrwx 1 root root 1 May 12 14:52 compname -> .
+$
+\"\"\"]]
+
+where `compname` is the hostname for the computer. Now you can create paths like
+
+[[!format sh \"\"\"
+git remote add comp-a /comp-a/home/my_user/data/repo
+git remote add comp-b /comp-b/home/my_user/data/repo
+\"\"\"]]
+
+This is also useful in other scripts where fetching data from the right directory on the wrong computer is bad. Also, this is a cheap way for a script to determine which computer it's running on:
+
+[[!format sh \"\"\"
+test -L \"/comp-a\" && echo Running on computer comp-a
+\"\"\"]]
+
+"""]]

Added a comment
diff --git a/doc/forum/Using_a_glacier_remote_as_a_backup/comment_2_41d47f0ca2e05e3296face5f89b819da._comment b/doc/forum/Using_a_glacier_remote_as_a_backup/comment_2_41d47f0ca2e05e3296face5f89b819da._comment
new file mode 100644
index 0000000..66b08b2
--- /dev/null
+++ b/doc/forum/Using_a_glacier_remote_as_a_backup/comment_2_41d47f0ca2e05e3296face5f89b819da._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnwNDA50ZupMvOgpgDqzDRyu5B-mYlVwa4"
+ nickname="Andreas"
+ subject="comment 2"
+ date="2015-05-12T06:52:04Z"
+ content="""
+Actually, I just removed all annexed files to try out disaster recovery. I stumbled across the `undo` command. Unfortunately, it does not seem available on Ubuntu running version 5.20141125 shipped by vivid (`git-annex: Unknown command 'undo'`).
+
+Am I missing something, or how do I get a version supporting `undo`?
+
+thanks
+Andreas
+
+
+"""]]

Added a comment: re: backup my data to blue ray disks
diff --git a/doc/forum/How_do_I_backup_my_data_to_blue_ray_disks__63__/comment_2_d79387905af9f8dce77f9aa85f2d6a03._comment b/doc/forum/How_do_I_backup_my_data_to_blue_ray_disks__63__/comment_2_d79387905af9f8dce77f9aa85f2d6a03._comment
new file mode 100644
index 0000000..4d7caf7
--- /dev/null
+++ b/doc/forum/How_do_I_backup_my_data_to_blue_ray_disks__63__/comment_2_d79387905af9f8dce77f9aa85f2d6a03._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://me.yahoo.com/a/e1w.8yMTnpUh.5fOXneP92pTdy23XJPwx84uLSM-#aca7c"
+ nickname="Michael"
+ subject="re: backup my data to blue ray disks"
+ date="2015-05-11T21:13:19Z"
+ content="""
+Thank you for your response. The disks are BD-R, so they are not rewritable. My experience in the past with rewritable disks has been that they work about as well as the average TV infomercial product. Do you have any opinions or suggestions on using par2 files on the disks?
+"""]]

comment
diff --git a/doc/forum/Using_a_glacier_remote_as_a_backup/comment_1_bb6022943ec739b1e80351c76f259e89._comment b/doc/forum/Using_a_glacier_remote_as_a_backup/comment_1_bb6022943ec739b1e80351c76f259e89._comment
new file mode 100644
index 0000000..c6899e4
--- /dev/null
+++ b/doc/forum/Using_a_glacier_remote_as_a_backup/comment_1_bb6022943ec739b1e80351c76f259e89._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-05-11T16:58:01Z"
+ content="""
+Your status shows that test.txt is deleted.
+`git annex get` does not un-delete files, it just gets the *content*
+of a file (whether that file is deleted or not).
+
+You can use normal git commands to un-delete the file. Ie, "git checkout
+text.txt". If you're using direct mode, you can't use such commands, but
+can use "git annex undo" to undo a deletion.
+
+Normally, if you have a bare repo, you'll want to clone it to get a non-bare
+repo. I suspect you did something else that resulted in your repo being in
+this state were files are deleted.
+"""]]
diff --git a/doc/git-annex-undo.mdwn b/doc/git-annex-undo.mdwn
index 391b373..1fda477 100644
--- a/doc/git-annex-undo.mdwn
+++ b/doc/git-annex-undo.mdwn
@@ -15,7 +15,7 @@ When passed a directory, undoes the last change that was made to the
 contents of that directory.
   
 Running undo a second time will undo the undo, returning the working
-tree to the same state it had before. In order for undoing an undo of
+tree to the same state it had before. To support undoing an undo of
 staged changes, any staged changes are first committed by the
 undo command.
 

import: Refuse to import files that are within the work tree, as that does not make sense and could cause data loss.
diff --git a/Command/Import.hs b/Command/Import.hs
index eb21fae..fffa301 100644
--- a/Command/Import.hs
+++ b/Command/Import.hs
@@ -9,6 +9,7 @@ module Command.Import where
 
 import Common.Annex
 import Command
+import qualified Git
 import qualified Annex
 import qualified Command.Add
 import Utility.CopyFile
@@ -62,6 +63,10 @@ getDuplicateMode = go . catMaybes <$> mapM getflag [minBound..maxBound]
 seek :: CommandSeek
 seek ps = do
 	mode <- getDuplicateMode
+	repopath <- liftIO . absPath =<< fromRepo Git.repoPath
+	inrepops <- liftIO $ filter (dirContains repopath) <$> mapM absPath ps
+	unless (null inrepops) $ do
+		error $ "cannot import files from inside the working tree (use git annex add instead): " ++ unwords inrepops
 	withPathContents (start mode) ps
 
 start :: DuplicateMode -> (FilePath, FilePath) -> CommandStart
diff --git a/debian/changelog b/debian/changelog
index cd7ade7..58921d5 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+git-annex (5.20150508.2) UNRELEASED; urgency=medium
+
+  * import: Refuse to import files that are within the work tree, as that
+    does not make sense and could cause data loss.
+
+ -- Joey Hess <id@joeyh.name>  Mon, 11 May 2015 12:45:06 -0400
+
 git-annex (5.20150508.1) unstable; urgency=medium
 
   * Now builds cleanly using ghc 7.10 (as well as ghc back to 7.6).
diff --git a/doc/bugs/Data_loss_when_doing___96__git_annex_import_--force__96__.mdwn b/doc/bugs/Data_loss_when_doing___96__git_annex_import_--force__96__.mdwn
index 8c61ba8..60e04fc 100644
--- a/doc/bugs/Data_loss_when_doing___96__git_annex_import_--force__96__.mdwn
+++ b/doc/bugs/Data_loss_when_doing___96__git_annex_import_--force__96__.mdwn
@@ -57,3 +57,6 @@ drwx------ 55 jkt jkt 8.0K May  8 13:54 ..
 drwxr-xr-x  8 jkt jkt  119 May  8 13:55 .git
 """]]
 ...and the file is gone :(.
+
+> You should use `git annex add` in this case, not import. 
+> I've made import refuse to run in this case. [[done]] --[[Joey]]

bug submitter appears to have been wrong
diff --git a/doc/bugs/__34__transfers_in_progress__34___gets_the_direction_wrong.mdwn b/doc/bugs/__34__transfers_in_progress__34___gets_the_direction_wrong.mdwn
index 4ef1656..e0b02a7 100644
--- a/doc/bugs/__34__transfers_in_progress__34___gets_the_direction_wrong.mdwn
+++ b/doc/bugs/__34__transfers_in_progress__34___gets_the_direction_wrong.mdwn
@@ -48,3 +48,8 @@ If you need more info, I'm "kuno" in the #git-annex IRC channel.
 
 # End of transcript or log.
 """]]
+
+> When I follow those steps, I see "uploading bigfile" in repo B,
+> which is indeed the case since repo A is downloading that file from B.
+> 
+> I suspect you're the one who got confused. [[done]] --[[Joey]]

diff --git a/doc/todo/transfer_between_git-annexes.mdwn b/doc/todo/transfer_between_git-annexes.mdwn
new file mode 100644
index 0000000..ccb6908
--- /dev/null
+++ b/doc/todo/transfer_between_git-annexes.mdwn
@@ -0,0 +1,20 @@
+What do you think of the ability to transfer a file between unrelated annexes? With "migrate" already taken, I would suggest "catapult" (or "teleport")!
+
+    git annex catapult dir1/ $HOME/otherannex/somedir/
+    git annex catapult dir2/thisfile.jpg $HOME/otherannex/somedir/
+
+git-annex would then:
+
+* Get list of present files
+* Copy the file to temporary space in $HOME/otherannex/.git/annex
+* fsck file
+* Move file to $HOME/otherannex/.git/annnex/objects
+* Create symlinks/directories in $HOME/otherannex/somedir/
+* Stage symlinks
+* Drop content and rm symlink
+
+with the usual modifiers (e.g. --fast would skip the fsck, --force to skip non-present files?).
+
+Reason I ask: I have a huge annex from importing the contents of a bunch of random harddrives and will eventually sort the contents into various other annexes I can put files into (personal, general family, specific people). Having git-annex guiding and checking the transfers from the sorting annex to the individual ones would be really nice.
+
+Not having this isn't a showstopper (I can use rsync) so no worries if you don't think it is worth it or think it is but put it on the backburner :) Would just be a nice-to-have.

Added a comment
diff --git a/doc/devblog/day_283__lazy_sunday/comment_1_fdc6da890e2dc6b86b6a5fe2ebceea4a._comment b/doc/devblog/day_283__lazy_sunday/comment_1_fdc6da890e2dc6b86b6a5fe2ebceea4a._comment
new file mode 100644
index 0000000..e5d4d4c
--- /dev/null
+++ b/doc/devblog/day_283__lazy_sunday/comment_1_fdc6da890e2dc6b86b6a5fe2ebceea4a._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="spwhitton"
+ subject="comment 1"
+ date="2015-05-11T09:02:10Z"
+ content="""
+I'd be interested to hear your reasons for preferring tabs over spaces, if it's anything more than an aesthetic preference.
+
+The [GHC trac](https://ghc.haskell.org/trac/ghc/ticket/9230) suggests that it was turned on by default because beginners accidentally mix tabs and spaces and get very confused.
+"""]]

diff --git a/doc/forum/A_git-annex_helper.mdwn b/doc/forum/A_git-annex_helper.mdwn
new file mode 100644
index 0000000..23a568e
--- /dev/null
+++ b/doc/forum/A_git-annex_helper.mdwn
@@ -0,0 +1,6 @@
+Hi,
+I have developed a [sort-of-a-GUI](http://github.com/atrent/AdMinchiam/tree/master/ga-gui) for git-annex and I'd like you to test it if you have time, see README and [screenshots](http://github.com/atrent/AdMinchiam/blob/master/ga-gui/Screenshots/GitAnnexGUI_020.png), the idea is very simple: visually tag items then generate a script based on editable templates.
+
+The only problem at the moment is the very slow git-annex data acquisition; not my fault, on very large annexes, in terms of number of files, the 'git-annex list' and 'git-annex metadata' commands take AGES...
+
+Thank you

disable horrible tab warning, needed in every file that Setup.hs pulls in
This is certianly a cabal bug for not passing the build options in the
cabal file when building Setup.hs.
And, why oh why did ghc enable this warning by default? So unhappy with
this choice.
diff --git a/Utility/Data.hs b/Utility/Data.hs
index 5ecd218..27c0a82 100644
--- a/Utility/Data.hs
+++ b/Utility/Data.hs
@@ -5,6 +5,8 @@
  - License: BSD-2-clause
  -}
 
+{-# OPTIONS_GHC -fno-warn-tabs #-}
+
 module Utility.Data where
 
 {- First item in the list that is not Nothing. -}
diff --git a/Utility/Directory.hs b/Utility/Directory.hs
index 0c95d96..7322cd8 100644
--- a/Utility/Directory.hs
+++ b/Utility/Directory.hs
@@ -6,6 +6,7 @@
  -}
 
 {-# LANGUAGE CPP #-}
+{-# OPTIONS_GHC -fno-warn-tabs #-}
 
 module Utility.Directory where
 
diff --git a/Utility/Exception.hs b/Utility/Exception.hs
index ab47ae9..9d4236c 100644
--- a/Utility/Exception.hs
+++ b/Utility/Exception.hs
@@ -6,6 +6,7 @@
  -}
 
 {-# LANGUAGE ScopedTypeVariables #-}
+{-# OPTIONS_GHC -fno-warn-tabs #-}
 
 module Utility.Exception (
 	module X,
diff --git a/Utility/FileSystemEncoding.hs b/Utility/FileSystemEncoding.hs
index 139b74f..41c5972 100644
--- a/Utility/FileSystemEncoding.hs
+++ b/Utility/FileSystemEncoding.hs
@@ -6,6 +6,7 @@
  -}
 
 {-# LANGUAGE CPP #-}
+{-# OPTIONS_GHC -fno-warn-tabs #-}
 
 module Utility.FileSystemEncoding (
 	fileEncoding,
diff --git a/Utility/Misc.hs b/Utility/Misc.hs
index 1fa08dd..45d5a06 100644
--- a/Utility/Misc.hs
+++ b/Utility/Misc.hs
@@ -6,6 +6,7 @@
  -}
 
 {-# LANGUAGE CPP #-}
+{-# OPTIONS_GHC -fno-warn-tabs #-}
 
 module Utility.Misc where
 
diff --git a/Utility/Monad.hs b/Utility/Monad.hs
index 878e0da..ac75104 100644
--- a/Utility/Monad.hs
+++ b/Utility/Monad.hs
@@ -5,6 +5,8 @@
  - License: BSD-2-clause
  -}
 
+{-# OPTIONS_GHC -fno-warn-tabs #-}
+
 module Utility.Monad where
 
 import Data.Maybe
diff --git a/Utility/OSX.hs b/Utility/OSX.hs
index 22028e2..f6aba50 100644
--- a/Utility/OSX.hs
+++ b/Utility/OSX.hs
@@ -5,6 +5,8 @@
  - License: BSD-2-clause
  -}
 
+{-# OPTIONS_GHC -fno-warn-tabs #-}
+
 module Utility.OSX where
 
 import Utility.UserInfo
diff --git a/Utility/Path.hs b/Utility/Path.hs
index d8fab10..8e3c2bd 100644
--- a/Utility/Path.hs
+++ b/Utility/Path.hs
@@ -6,6 +6,7 @@
  -}
 
 {-# LANGUAGE PackageImports, CPP #-}
+{-# OPTIONS_GHC -fno-warn-tabs #-}
 
 module Utility.Path where
 
diff --git a/Utility/PosixFiles.hs b/Utility/PosixFiles.hs
index 5a94ead..4550beb 100644
--- a/Utility/PosixFiles.hs
+++ b/Utility/PosixFiles.hs
@@ -8,6 +8,7 @@
  -}
 
 {-# LANGUAGE CPP #-}
+{-# OPTIONS_GHC -fno-warn-tabs #-}
 
 module Utility.PosixFiles (
 	module X,
diff --git a/Utility/Process.hs b/Utility/Process.hs
index 86a25ab..9f98596 100644
--- a/Utility/Process.hs
+++ b/Utility/Process.hs
@@ -7,6 +7,7 @@
  -}
 
 {-# LANGUAGE CPP, Rank2Types #-}
+{-# OPTIONS_GHC -fno-warn-tabs #-}
 
 module Utility.Process (
 	module X,
diff --git a/Utility/SafeCommand.hs b/Utility/SafeCommand.hs
index efa14b4..0704e69 100644
--- a/Utility/SafeCommand.hs
+++ b/Utility/SafeCommand.hs
@@ -5,6 +5,8 @@
  - License: BSD-2-clause
  -}
 
+{-# OPTIONS_GHC -fno-warn-tabs #-}
+
 module Utility.SafeCommand where
 
 import System.Exit
diff --git a/Utility/Tmp.hs b/Utility/Tmp.hs
index dc55981..de970fe 100644
--- a/Utility/Tmp.hs
+++ b/Utility/Tmp.hs
@@ -6,6 +6,7 @@
  -}
 
 {-# LANGUAGE CPP #-}
+{-# OPTIONS_GHC -fno-warn-tabs #-}
 
 module Utility.Tmp where
 
diff --git a/Utility/UserInfo.hs b/Utility/UserInfo.hs
index dbb09e7..7e94caf 100644
--- a/Utility/UserInfo.hs
+++ b/Utility/UserInfo.hs
@@ -6,6 +6,7 @@
  -}
 
 {-# LANGUAGE CPP #-}
+{-# OPTIONS_GHC -fno-warn-tabs #-}
 
 module Utility.UserInfo (
 	myHomeDir,
diff --git a/doc/devblog/day_283__lazy_sunday.mdwn b/doc/devblog/day_283__lazy_sunday.mdwn
index 502e63b..2850e2c 100644
--- a/doc/devblog/day_283__lazy_sunday.mdwn
+++ b/doc/devblog/day_283__lazy_sunday.mdwn
@@ -1,3 +1,7 @@
 Lazy afternoon spent porting git-anenx to build under ghc 7.10. Required
 rather a lot of changes to build, and even more to build cleanly after the
 AMP transition.
+
+Unfortunately, ghc 7.10 has started warning about every line that uses tab
+for indentation. I had to add additional cruft to turn those warnings off
+everywhere, and cannot say I'm happy about this at all.

devblog
diff --git a/doc/devblog/day_283__lazy_sunday.mdwn b/doc/devblog/day_283__lazy_sunday.mdwn
new file mode 100644
index 0000000..502e63b
--- /dev/null
+++ b/doc/devblog/day_283__lazy_sunday.mdwn
@@ -0,0 +1,3 @@
+Lazy afternoon spent porting git-anenx to build under ghc 7.10. Required
+rather a lot of changes to build, and even more to build cleanly after the
+AMP transition.

fix man page example formatting
diff --git a/doc/bugs/man_page_has_example_lines_joined_into_a_single_line.mdwn b/doc/bugs/man_page_has_example_lines_joined_into_a_single_line.mdwn
index 366f2e8..397666a 100644
--- a/doc/bugs/man_page_has_example_lines_joined_into_a_single_line.mdwn
+++ b/doc/bugs/man_page_has_example_lines_joined_into_a_single_line.mdwn
@@ -14,3 +14,5 @@ git-annex version: 5.20150409+git126-ga29f683-1~ndall+1
 
 # End of transcript or log.
 """]]
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/git-annex-schedule.mdwn b/doc/git-annex-schedule.mdwn
index 78ca7a5..bffb15e 100644
--- a/doc/git-annex-schedule.mdwn
+++ b/doc/git-annex-schedule.mdwn
@@ -31,10 +31,10 @@ To schedule multiple jobs, separate them with "; ".
   
   Some examples:
   
-          fsck self 30m every day at any time
-          fsck self 1h every month at 3 AM
-          fsck self 1h on day 1 of every month at any time
-          fsck self 1h every week divisible by 2 at any time
+	fsck self 30m every day at any time
+	fsck self 1h every month at 3 AM
+	fsck self 1h on day 1 of every month at any time
+	fsck self 1h every week divisible by 2 at any time
 
 # SEE ALSO
 

diff --git a/doc/bugs/man_page_has_example_lines_joined_into_a_single_line.mdwn b/doc/bugs/man_page_has_example_lines_joined_into_a_single_line.mdwn
new file mode 100644
index 0000000..366f2e8
--- /dev/null
+++ b/doc/bugs/man_page_has_example_lines_joined_into_a_single_line.mdwn
@@ -0,0 +1,16 @@
+
+[[!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 help schedule | grep -A3 examples
+man: can't set the locale; make sure $LC_* and $LANG are correct
+       Some examples:
+
+       fsck self 30m every day at any time fsck self 1h every month at 3 AM fsck self 1h on day 1 of every month at any time fsck self 1h every week divisible by 2 at any time
+
+$> git annex version
+git-annex version: 5.20150409+git126-ga29f683-1~ndall+1
+# about to build a fresh standlone
+
+# End of transcript or log.
+"""]]

diff --git a/doc/bugs/__34__transfers_in_progress__34___gets_the_direction_wrong.mdwn b/doc/bugs/__34__transfers_in_progress__34___gets_the_direction_wrong.mdwn
index 4ef2743..4ef1656 100644
--- a/doc/bugs/__34__transfers_in_progress__34___gets_the_direction_wrong.mdwn
+++ b/doc/bugs/__34__transfers_in_progress__34___gets_the_direction_wrong.mdwn
@@ -1,18 +1,17 @@
 ### Please describe the problem.
 
-07:32 warp@18-volt:/mnt/zooyork/annex/somerepo (master)$ git annex info --fast
-repository mode: indirect
-trusted repositories: 0
-semitrusted repositories: 4
-	00000000-0000-0000-0000-000000000001 -- web
- 	3dca408f-ccfd-48df-a8a0-b7d517a482ef -- zooyork [here]
- 	9fbb4e2c-4ed9-47b4-877c-74d2eeea6296 -- [kirby]
- 	d1b57403-2bc2-41d8-9a8e-eec0d3f31e67 -- [pucca]
-untrusted repositories: 0
-transfers in progress: 
-	downloading folder/some-large-file.mp4 from pucca
-available local disk space: 232.2 gigabytes (+1 megabyte reserved)
-
+    07:32 warp@18-volt:/mnt/zooyork/annex/somerepo (master)$ git annex info --fast
+    repository mode: indirect
+    trusted repositories: 0
+    semitrusted repositories: 4
+    	00000000-0000-0000-0000-000000000001 -- web
+     	3dca408f-ccfd-48df-a8a0-b7d517a482ef -- zooyork [here]
+     	9fbb4e2c-4ed9-47b4-877c-74d2eeea6296 -- [kirby]
+     	d1b57403-2bc2-41d8-9a8e-eec0d3f31e67 -- [pucca]
+    untrusted repositories: 0
+    transfers in progress: 
+    	downloading folder/some-large-file.mp4 from pucca
+    available local disk space: 232.2 gigabytes (+1 megabyte reserved)
 
 The "transfers in progress" section of the above "git annex info" output describes a file being downloaded from pucca, presumably to [here], which is zooyork.  This does not describe the transfer correctly, when I ran the "git annex info --fast" command another git annex process was downloading folder/some-large-file.mp4 from zooyork to pucca (so, in the other direction than git annex info described).
 
@@ -24,18 +23,18 @@ The "transfers in progress" section of the above "git annex info" output describ
 
 ### What version of git-annex are you using? On what operating system?
 
-07:37 warp@18-volt:/mnt/zooyork/annex$ git annex version
-git-annex version: 5.20141105-g8b19598
-build flags: Assistant Webapp Webapp-secure Pairing Testsuite S3 WebDAV Inotify DBus DesktopNotify XMPP DNS Feeds Quvi TDFA CryptoHash
-key/value backends: SHA256E SHA1E SHA512E SHA224E SHA384E SKEIN256E SKEIN512E SHA256 SHA1 SHA512 SHA224 SHA384 SKEIN256 SKEIN512 WORM URL
-remote types: git gcrypt S3 bup directory rsync web webdav tahoe glacier ddar hook external
-
-07:37 warp@18-volt:/mnt/zooyork/annex$ lsb_release -a
-No LSB modules are available.
-Distributor ID:	Ubuntu
-Description:	Ubuntu 14.04 LTS
-Release:	14.04
-Codename:	trusty
+    07:37 warp@18-volt:/mnt/zooyork/annex$ git annex version
+    git-annex version: 5.20141105-g8b19598
+    build flags: Assistant Webapp Webapp-secure Pairing Testsuite S3 WebDAV Inotify DBus DesktopNotify XMPP DNS Feeds Quvi TDFA CryptoHash
+    key/value backends: SHA256E SHA1E SHA512E SHA224E SHA384E SKEIN256E SKEIN512E SHA256 SHA1 SHA512 SHA224 SHA384 SKEIN256 SKEIN512 WORM URL
+    remote types: git gcrypt S3 bup directory rsync web webdav tahoe glacier ddar hook external
+
+    07:37 warp@18-volt:/mnt/zooyork/annex$ lsb_release -a
+    No LSB modules are available.
+    Distributor ID:	Ubuntu
+    Description:	Ubuntu 14.04 LTS
+    Release:	14.04
+    Codename:	trusty
 
 
 ### Please provide any additional information below.