Merge branch 'master' of ssh://git-annex.branchable.com

doc/bugs/OSX_case_insensitive_filesystem/comment_8_3384bca070d84220efe166a398eed8a4._comment

@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="thowz"
+ subject="reinject files"
+ date="2016-05-04T00:52:38Z"
+ content="""
+Here's a way to put files into their proper case-sensitive folders using `git-annex reinject --known`:
+
+    # Enable write permissions on directories containing misfiled items
+    chmod u+w `find -xtype l -printf \"%l\n\" | sed -r \"s/.*(\.git\/annex\/objects\/)[^\/]*\/[^\/]*\/([^\/]*).*/\1*\/*\/\2/\" | sort | uniq`
+    
+    # Reinject those files into the annex
+    git-annex reinject --known `find -xtype l -printf \"%l\n\" | sed -r \"s/.*(\.git\/annex\/objects\/)[^\/]*\/[^\/]*\/([^\/]*.*)/\1*\/*\/\2/\" | sort | uniq`
+
+    # Remove empty directories (rmdir will fail on the non-empty directories)
+    find .git/annex/objects -mindepth 3 -maxdepth 3 -type d -exec rmdir {} \;
+    find .git/annex/objects -mindepth 2 -maxdepth 2 -type d -exec rmdir {} \;
+"""]]

doc/forum/S3_remote_not_available.mdwn

@@ -0,0 +1,31 @@
+One of my remotes is S3 (named s3). I used to be able to run
+
+    $ git annex sync s3 --content
+
+But now I'm getting the following error:
+
+    commit  
+    On branch master
+    nothing to commit, working directory clean
+    ok
+    git-annex: there is no available git remote named "s3"
+
+My `.git/config` file contains following lines which I would assume mean that the remote is there:
+
+    [remote "s3"]
+            annex-s3 = true
+            annex-uuid = bd9af194-b736-4114-a689-9a8bf212fb18
+            fetch = 
+            annex-sync = false
+
+As far as I can tell only change I did was to install newer version of git-annex, currently I have:
+
+    git-annex version: 6.20160418
+    build flags: Assistant Webapp Pairing Testsuite WebDAV FsEvents XMPP ConcurrentOutput TorrentParser MagicMime Feeds Quvi
+    key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 SHA1E SHA1 MD5E MD5 WORM URL
+    remote types: git gcrypt bup directory rsync web bittorrent webdav tahoe glacier ddar hook external
+    local repository version: 6
+    supported repository versions: 5 6
+    upgrade supported from repository versions: 0 1 2 4 5
+
+How do I recover access to that remote?

doc/forum/race_condition_with_drop_-J__63__.mdwn

@@ -0,0 +1,7 @@
+When I run a command like: "git-annex drop . -J 20"
+
+I get: "git-annex: content is locked"
+
+Running with -J 5 works.
+
+EDIT: Even as low as -J 2 runs into problems. The issue is simply more likely to trigger with more threads.

doc/git-annex-drop/comment_1_ecb863aea64eadbaeb7759c5cb0bf5a5._comment

@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="zpeters@669a56d871ec94de11e1bf63f4a21e80ea90b2fa"
+ nickname="zpeters"
+ subject="Choose which remote to lock when dropping"
+ date="2016-05-03T23:37:09Z"
+ content="""
+I might have a unique situation but i have a git annex repo that has multiple remotes for the same actual location.  I have a server at home and when i'm \"out in the world\" i use it's external IP and when i'm at home i use it's internal IP.  It appears that when i do an git annex drop on my laptop to compares and locks whichever remote is alphabetically first.  
+
+What i'm wondering is is there a way to tell git annex which remote i want to compare against?  For example when i'm remote i want to do something like \"git annex drop . --compare remoteServer\"
+
+Thank you!
+"""]]

doc/news/version_6.20160419/comment_1_b7d20a64e3ddb99a30920e8f614abe6c._comment

@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="zfnupbos@a80a4f4cf5dde7ac4988ef0d077052c95fe1e058"
+ nickname="zfnupbos"
+ subject="version clarification"
+ date="2016-05-04T01:05:52Z"
+ content="""
+is this 6.20160419 or 6.20160428?
+
+It was released on the 28th, and 'git-annex version' shows git-annex version: 6.20160428-g1f253e8. But many places refer to it as 6.20160419.
+"""]]