Recent changes to this wiki:

initial report
diff --git a/doc/todo/annex_add___40__-u__124__--update__41___mode.mdwn b/doc/todo/annex_add___40__-u__124__--update__41___mode.mdwn
new file mode 100644
index 0000000..8331176
--- /dev/null
+++ b/doc/todo/annex_add___40__-u__124__--update__41___mode.mdwn
@@ -0,0 +1,3 @@
+to supplement 'git add -u' behavior -- to add only updated (tracked only, no untracked) files to be committed.  ATM all files would be added, including untracked.
+
+[[!meta author=yoh]]

initial report
diff --git a/doc/bugs/annex_doesn__39__t_fixup_symlinks_when___34__git_commit_path__95__to__95__repo__34___is_used.mdwn b/doc/bugs/annex_doesn__39__t_fixup_symlinks_when___34__git_commit_path__95__to__95__repo__34___is_used.mdwn
new file mode 100644
index 0000000..b72788f
--- /dev/null
+++ b/doc/bugs/annex_doesn__39__t_fixup_symlinks_when___34__git_commit_path__95__to__95__repo__34___is_used.mdwn
@@ -0,0 +1,79 @@
+### Please describe the problem.
+
+whenever we 'git mv' some files from one dir to another, "git commit path_to_that_repo" seems to cause git annex to not fix up the symlinks
+
+### What steps will reproduce the problem?
+
+see below complete examples
+
+### What version of git-annex are you using? On what operating system?
+
+6.20170307+gitg24ade8a25-1~ndall+1
+
+### Please provide any additional information below.
+
+correct operation:
+
+[[!format sh """
+
+hopa:/tmp/testl
+$> builtin cd /tmp/; chmod +w -R /tmp/testl; rm -rf /tmp/testl; mkdir /tmp/testl && cd /tmp/testl && git init && git annex init && mkdir d && echo 123 > d/123 && git annex add d/123 && git commit -m added && git mv d/123 123 && git annex add . && echo -e '#!/bin/sh\ngit annex pre-commit --debug . >/tmp/precommit.log 2>&1\n' >| .git/hooks/pre-commit && git commit -m msg && ls -l 123 && git status && cat /tmp/precommit.log                                             
+Initialized empty Git repository in /tmp/testl/.git/
+init  ok
+(recording state in git...)
+add d/123 ok
+(recording state in git...)
+[master (root-commit) a04d6e9] added
+ 1 file changed, 1 insertion(+)
+ create mode 120000 d/123
+[master 1be2c88] msg
+ 2 files changed, 1 insertion(+), 1 deletion(-)
+ create mode 120000 123
+ delete mode 120000 d/123
+lrwxrwxrwx 1 yoh yoh 178 Mar 22 14:52 123 -> .git/annex/objects/G6/qW/SHA256E-s4--181210f8f9c779c26da1d9b2075bde0127302ee0e3fca38c9a83f5b1dd8e5d3b/SHA256E-s4--181210f8f9c779c26da1d9b2075bde0127302ee0e3fca38c9a83f5b1dd8e5d3b
+On branch master
+nothing to commit, working tree clean
+[2017-03-22 14:52:45.459507064] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","diff","--cached","--name-only","-z","--diff-filter=ACMRT","--","."]
+fix 123 ok
+[2017-03-22 14:52:45.46373033] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","diff","--name-only","--diff-filter=T","-z","--cached","--","."]
+[2017-03-22 14:52:45.46776695] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","symbolic-ref","-q","HEAD"]
+[2017-03-22 14:52:45.471690183] process done ExitSuccess
+[2017-03-22 14:52:45.471781853] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","refs/heads/master"]
+[2017-03-22 14:52:45.475456411] process done ExitSuccess
+(recording state in git...)
+[2017-03-22 14:52:45.475535994] feed: xargs ["-0","git","--git-dir=.git","--work-tree=.","--literal-pathspecs","add","--force","--"]
+[2017-03-22 14:52:45.482800008] process done ExitSuccess
+"""]]
+
+and this time commit with the path: (git commit -m msg /tmp/testl)
+
+[[!format sh """
+$> builtin cd /tmp/; chmod +w -R /tmp/testl; rm -rf /tmp/testl; mkdir /tmp/testl && cd /tmp/testl && git init && git annex init && mkdir d && echo 123 > d/123 && git annex add d/123 && git commit -m added && git mv d/123 123 && git annex add . && echo -e '#!/bin/sh\ngit annex pre-commit --debug . >/tmp/precommit.log 2>&1\n' >| .git/hooks/pre-commit && git commit -m msg /tmp/testl && ls -l 123 && git status && cat /tmp/precommit.log                                                                                                                                                      
+Initialized empty Git repository in /tmp/testl/.git/
+init  ok
+(recording state in git...)
+add d/123 ok
+(recording state in git...)
+[master (root-commit) 1438090] added
+ 1 file changed, 1 insertion(+)
+ create mode 120000 d/123
+[master 8912aa3] msg
+ 1 file changed, 0 insertions(+), 0 deletions(-)
+ rename d/123 => 123 (100%)
+lrwxrwxrwx 1 yoh yoh 181 Mar 22 14:52 123 -> ../.git/annex/objects/G6/qW/SHA256E-s4--181210f8f9c779c26da1d9b2075bde0127302ee0e3fca38c9a83f5b1dd8e5d3b/SHA256E-s4--181210f8f9c779c26da1d9b2075bde0127302ee0e3fca38c9a83f5b1dd8e5d3b
+On branch master
+nothing to commit, working tree clean
+[2017-03-22 14:52:55.857221368] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","diff","--name-only","--diff-filter=T","-z","--cached","--","."]
+[2017-03-22 14:52:55.861708907] process done ExitSuccess
+[2017-03-22 14:52:55.861809182] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","symbolic-ref","-q","HEAD"]
+[2017-03-22 14:52:55.865393029] process done ExitSuccess
+[2017-03-22 14:52:55.865471585] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","refs/heads/master"]
+[2017-03-22 14:52:55.869145816] process done ExitSuccess
+
+
+"""]]
+
+
+note that there is no "(recording state in git...) ..." portion in the output!
+
+[[!meta author=yoh]]

diff --git a/doc/bugs/git_annex_enableremote_ignoring_encryption_changes.mdwn b/doc/bugs/git_annex_enableremote_ignoring_encryption_changes.mdwn
new file mode 100644
index 0000000..e73b2ce
--- /dev/null
+++ b/doc/bugs/git_annex_enableremote_ignoring_encryption_changes.mdwn
@@ -0,0 +1,118 @@
+### Please describe the problem.
+
+Git-Annex enableremote ignores encryption changes to a hybrid-cypher gcrypt remote. So it is not possible to add or remove keys.
+
+
+### What steps will reproduce the problem?
+
+Having a bare repo prepared do:
+
+    git annex initremote $remotename type=gcrypt encryption=hybrid gitrepo=ssh://giessen@magierenklave.de/annex/test keyid=$myfirstkey
+        initremote $remotename (encryption setup) (to gpg keys: $myfirstkey) $user@$hosts's password:
+    (...)
+    git annex sync $remotename
+        (...)
+    git annex info $remotename
+        (...)
+        uuid: $remoteuuid
+        (...)
+        encryption: hybrid (to gpg keys: $myfirstkey)
+        (...)
+    git config --get remote.$remotename.gcrypt-participants
+        $myfirstkey
+
+So far, so good. Now we try adding another key
+
+    git annex enableremote $remotename keyid+=$mysecondkey
+        enableremote $remotename ok
+
+The command returns instantly, no interaction with the remote.
+
+    git annex sync $remotename
+        (...)
+    git annex info $remotename
+        (...)
+        uuid: $remoteuuid
+        (...)
+        encryption: hybrid (to gpg keys: $myfirstkey)
+        (...)
+    git config --get remote.$remotename.gcrypt-participants
+        $myfirstkey
+
+Obviously our change had no effect. This can be verified by the repository being inaccessible to the second key.
+
+A very hacky workaround seems to be:
+
+    git remote remove server.test
+(we need this or git will complain about the remote already existing and annex will fail)
+    git annex enableremote $remoteuuid keyid+=$mysecondkey
+        enableremote $remoteuuid (encryption update) (to gpg keys: $myfirstkey $mysecondkey) $user@$hosts's password:
+        (...)
+    git annex info $remotename
+        (...)
+        encryption: hybrid (to gpg keys: $myfirstkey $mysecondkey)
+        (...)
+    git config --get remote.$remotename.gcrypt-participants
+        $myfirstkey $mysecondkey
+
+...which yields the expected results but is somewhat counterintuitive and probably a bad abuse of enableremote. 
+
+### What version of git-annex are you using? On what operating system?
+
+git annex version:
+
+    git-annex version: 6.20170302-gb35a50cca
+    build flags: Assistant Webapp Pairing Testsuite S3(multipartupload)(storageclasses) WebDAV Inotify DBus DesktopNotify 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 p2p S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external
+    local repository version: 6
+    supported repository versions: 3 5 6
+    upgrade supported from repository versions: 0 1 2 3 4 5
+    operating system: linux x86_64
+
+uname -a
+
+    Linux $host.$domain 4.9.3-1-default #1 SMP PREEMPT Thu Jan 12 11:32:53 UTC 2017 (2c7dfab) x86_64 x86_64 x86_64 GNU/Linux
+
+### Please provide any additional information below.
+
+gpg is running with -vvv so please don't mind the extra-verbose gpg-output.
+
+[[!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
+:~/test> git annex enableremote test keyid+=$mysecondkey
+enableremote test ok
+:~/test> git remote remove test
+:~/test> git annex enableremote 1291d1b4-dac1-5c44-b09e-e04c03b755d6 keyid+=$mysecondkey
+enableremote 1291d1b4-dac1-5c44-b09e-e04c03b755d6 (encryption update) (to gpg keys: $myfirstkey $mysecondkey) user@server's password: 
+gcrypt: Decrypting manifest
+gpg: Signatur vom Mi 22 Mär 2017 14:50:39 CET
+gpg:                mittels RSA-Schlüssel 0144XXXXXXXXXXXXXXXXXXXXXXX
+gpg: Korrekte Signatur von "XXXXXX" [ultimativ]
+gcrypt: Remote ID is :id:Zfhze/U8YGNRIWmfNUV5
+Von gcrypt::ssh://user@server/annex/test
+ * [neuer Branch]    synced/git-annex -> test/synced/git-annex
+ * [neuer Branch]    synced/master    -> test/synced/master
+ * [neuer Branch]    git-annex        -> test/git-annex
+ * [neuer Branch]    master           -> test/master
+user@server's password: 
+gcrypt: Decrypting manifest
+gpg: Signatur vom Mi 22 Mär 2017 14:50:39 CET
+gpg:                mittels RSA-Schlüssel 0144XXXXXXXXXXXXXXXXXXXXXX
+gpg: Korrekte Signatur von "XXXXXX" [ultimativ]
+Everything up-to-date
+user@server's password: 
+ok
+ok
+(recording state in git...)
+# End of transcript or log.
+"""]]
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+Yes, definitively. I enjoy using annex to backup and manage my data. I would love to see it used more often and am currently trying to get my boss to introduce it for storage of the digital backups of our documents. While preparing an encrypted test-setup I stumbled upon this. :)
+
+Thanks
+
+Jörn

removed
diff --git a/doc/encryption/comment_7_60b251fea4b4c84e31ec0cd69779aec8._comment b/doc/encryption/comment_7_60b251fea4b4c84e31ec0cd69779aec8._comment
deleted file mode 100644
index f5286b4..0000000
--- a/doc/encryption/comment_7_60b251fea4b4c84e31ec0cd69779aec8._comment
+++ /dev/null
@@ -1,20 +0,0 @@
-[[!comment format=mdwn
- username="joern.mankiewicz@06fb5bc9b732f143dee3606866362f562531310d"
- nickname="joern.mankiewicz"
- avatar="http://cdn.libravatar.org/avatar/446365f4d50dddc42965fa0432e70cdb"
- subject="Workflow for adding a keyid in hybrid-enc lateron and re-encrypting? "
- date="2017-03-21T22:08:22Z"
- content="""
-Hi folks!
-
-We are considering introducing git-annex with gcrypt in hybrid mode as secure storage for common data in our company and I'd rather not delete and reinit the repo everytime when somebody new is granted access.
-A little testing with current git-annex showed, that GCRYPT_FULL_REPACK with a forced git-push of all branches makes the git-repo accessible (I get the files) to the newcomer but not the annexed data (gpg error \"No secret key\" in git annex get, git annex info secretRepo just lists my first key).
-
-Has anybody sucessfully tested adding keyids in hybrid-encryption later on? Which further steps where needed to make it work? 
-
-Thanks for any input! :)
-
-Cheers 
-
-Jörn
-"""]]

Added a comment: Workflow for adding a keyid in hybrid-enc lateron and re-encrypting?
diff --git a/doc/encryption/comment_8_3849eb24c3682644e263bae107747dee._comment b/doc/encryption/comment_8_3849eb24c3682644e263bae107747dee._comment
new file mode 100644
index 0000000..393d18e
--- /dev/null
+++ b/doc/encryption/comment_8_3849eb24c3682644e263bae107747dee._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="joern.mankiewicz@06fb5bc9b732f143dee3606866362f562531310d"
+ nickname="joern.mankiewicz"
+ avatar="http://cdn.libravatar.org/avatar/446365f4d50dddc42965fa0432e70cdb"
+ subject="Workflow for adding a keyid in hybrid-enc lateron and re-encrypting? "
+ date="2017-03-21T22:08:30Z"
+ content="""
+Hi folks!
+
+We are considering introducing git-annex with gcrypt in hybrid mode as secure storage for common data in our company and I'd rather not delete and reinit the repo everytime when somebody new is granted access.
+A little testing with current git-annex showed, that GCRYPT_FULL_REPACK with a forced git-push of all branches makes the git-repo accessible (I get the files) to the newcomer but not the annexed data (gpg error \"No secret key\" in git annex get, git annex info secretRepo just lists my first key).
+
+Has anybody sucessfully tested adding keyids in hybrid-encryption later on? Which further steps where needed to make it work? 
+
+Thanks for any input! :)
+
+Cheers 
+
+Jörn
+"""]]

Added a comment: Workflow for adding a keyid in hybrid-enc lateron and re-encrypting?
diff --git a/doc/encryption/comment_7_60b251fea4b4c84e31ec0cd69779aec8._comment b/doc/encryption/comment_7_60b251fea4b4c84e31ec0cd69779aec8._comment
new file mode 100644
index 0000000..f5286b4
--- /dev/null
+++ b/doc/encryption/comment_7_60b251fea4b4c84e31ec0cd69779aec8._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="joern.mankiewicz@06fb5bc9b732f143dee3606866362f562531310d"
+ nickname="joern.mankiewicz"
+ avatar="http://cdn.libravatar.org/avatar/446365f4d50dddc42965fa0432e70cdb"
+ subject="Workflow for adding a keyid in hybrid-enc lateron and re-encrypting? "
+ date="2017-03-21T22:08:22Z"
+ content="""
+Hi folks!
+
+We are considering introducing git-annex with gcrypt in hybrid mode as secure storage for common data in our company and I'd rather not delete and reinit the repo everytime when somebody new is granted access.
+A little testing with current git-annex showed, that GCRYPT_FULL_REPACK with a forced git-push of all branches makes the git-repo accessible (I get the files) to the newcomer but not the annexed data (gpg error \"No secret key\" in git annex get, git annex info secretRepo just lists my first key).
+
+Has anybody sucessfully tested adding keyids in hybrid-encryption later on? Which further steps where needed to make it work? 
+
+Thanks for any input! :)
+
+Cheers 
+
+Jörn
+"""]]

Added a comment: Tracking GUIDs
diff --git a/doc/tips/downloading_podcasts/comment_27_e343aeda7c16c834599fb3caab2a51a2._comment b/doc/tips/downloading_podcasts/comment_27_e343aeda7c16c834599fb3caab2a51a2._comment
new file mode 100644
index 0000000..ec2aef0
--- /dev/null
+++ b/doc/tips/downloading_podcasts/comment_27_e343aeda7c16c834599fb3caab2a51a2._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="ewen"
+ avatar="http://cdn.libravatar.org/avatar/605b2981cb52b4af268455dee7a4f64e"
+ subject="Tracking GUIDs"
+ date="2017-03-21T21:46:27Z"
+ content="""
+@joey - thanks, that's prompt feature request fulfilment :-)
+
+Looking more closely at the duplicates, it turns out that not *everything* got duplicated, just the \"older\" episodes.  It turns out the newer episodes do have `guid` values saved (as `itemid` in the metadata) and the older episodes do not.  I think this is most likely because I *was* running a fairly old git-annex until about October 2016, on a fairly old OS install, but then upgraded to a more recent one (now about 6 months old) which does track them.  My assumption (without checking every file) is the episodes downloaded before October 2016 are ones that got duplicated.
+
+I've edited the main page and added a note that GUIDs are tracked in versions since 2015, since I didn't obviously find that listed anywhere before.
+
+Ewen
+"""]]

Add note about tracking guids since 2015
diff --git a/doc/tips/downloading_podcasts.mdwn b/doc/tips/downloading_podcasts.mdwn
index e118254..2926c67 100644
--- a/doc/tips/downloading_podcasts.mdwn
+++ b/doc/tips/downloading_podcasts.mdwn
@@ -14,7 +14,9 @@ git-annex will avoid downloading a file from a feed if its url has already
 been stored in the repository before. So once a file is downloaded,
 you can move it around, delete it, `git annex drop` its content, etc,
 and it will not be downloaded again by repeated runs of
-`git annex importfeed`. Just how a podcatcher should behave.
+`git annex importfeed`. Just how a podcatcher should behave.  (git-annex versions 
+since 2015 also tracks the podcast `guid` values, as metadata, to help avoid 
+duplication if the media file url changes; use `git annex metadata ...` to inspect.)
 
 ## templates
 

add news item for git-annex 6.20170321
diff --git a/doc/news/version_6.20170101.mdwn b/doc/news/version_6.20170101.mdwn
deleted file mode 100644
index 1bb5de6..0000000
--- a/doc/news/version_6.20170101.mdwn
+++ /dev/null
@@ -1,46 +0,0 @@
-News for git-annex 6.20170101:
-
-   XMPP support has been removed from the assistant in this release.
-   If your repositories used XMPP to keep in sync, that will no longer
-   work, and you should enable some other remote to keep them in sync.
-   A ssh server is one way, or use the new Tor pairing feature.
-
-git-annex 6.20170101 released with [[!toggle text="these changes"]]
-[[!toggleable text="""
-   * XMPP support has been removed from the assistant in this release.
-     If your repositories used XMPP to keep in sync, that will no longer
-     work, and you should enable some other remote to keep them in sync.
-     A ssh server is one way, or use the new Tor pairing feature.
-   * p2p --pair makes it easy to pair repositories, over Tor, using
-     Magic Wormhole codes to find the other repository.
-     See http://git-annex.branchable.com/tips/peer\_to\_peer\_network\_with\_tor/
-   * webapp: The "Share with a friend" and "Share with your other devices"
-     pages have been changed to pair repositories using Tor and Magic Wormhole.
-   * metadata --batch: Fix bug when conflicting metadata changes were
-     made in the same batch run.
-   * Pass annex.web-options to wget and curl after other options, so that
-     eg --no-show-progress can be set by the user to disable the default
-     --show-progress.
-   * Revert ServerAliveInterval change in 6.20161111, which caused problems
-     with too many old versions of ssh and unusual ssh configurations.
-     It should have not been needed anyway since ssh is supposted to
-     have TCPKeepAlive enabled by default.
-   * Make all --batch input, as well as fromkey and registerurl stdin
-     be processed without requiring it to be in the current encoding.
-   * p2p: --link no longer takes a remote name, instead the --name
-     option can be used.
-   * Linux standalone: Improve generation of locale definition files,
-     supporting locales such as en\_GB.UTF-8.
-   * rekey --force: Incorrectly marked the new key's content as being
-     present in the local repo even when it was not.
-   * enable-tor: Put tor sockets in /var/lib/tor-annex/, rather
-     than in /etc/tor/hidden\_service/.
-   * enable-tor: No longer needs to be run as root.
-   * enable-tor: When run as a regular user, also tests a connection back to
-     the hidden service over tor.
-   * Support all common locations of the torrc file.
-   * Always use filesystem encoding for all file and handle reads and
-     writes.
-   * Fix build with directory-1.3.
-   * Debian: Suggest tor and magic-wormhole.
-   * Debian: Build webapp on armel."""]]
\ No newline at end of file
diff --git a/doc/news/version_6.20170321.mdwn b/doc/news/version_6.20170321.mdwn
new file mode 100644
index 0000000..864c626
--- /dev/null
+++ b/doc/news/version_6.20170321.mdwn
@@ -0,0 +1,28 @@
+git-annex 6.20170321 released with [[!toggle text="these changes"]]
+[[!toggleable text="""
+   * Bugfix: Passing a command a filename that does not exist sometimes
+     did not display an error, when a path to a directory was also passed.
+   * status: Propigate nonzero exit code from git status.
+   * Linux standalone builds put the bundled ssh last in PATH,
+     so any system ssh will be preferred over it.
+   * assistant: Add 1/200th second delay between checking each file
+     in the full transfer scan, to avoid using too much CPU.
+   * get -J: Improve distribution of jobs amoung remotes when there are more
+     jobs than remotes.
+   * fsck -q: When a file has bad content, include the name of the file
+     in the warning message.
+   * Windows: Improve handling of shebang in external special remote
+     program, searching for the program in the PATH.
+   * Drop support for building with old versions of dns, http-conduit,
+     directory, feed, and http-types.
+   * Windows: Fix bug in shell script shebang lookup code that
+     caused a "delayed read on closed handle" error.
+   * git-annex-shell: Fix bug when used with a recently cloned repository,
+     where "merging" messages were included in the output of configlist
+     (and perhaps other commands) and caused a "Failed to get annex.uuid
+     configuration" error.
+   * Support GIT\_SSH and GIT\_SSH\_COMMAND, which are handled close the same
+     as they are by git. However, unlike git, git-annex sometimes needs to
+     pass the -n parameter when using these.
+   * sync --content-of=path (-C path) added for when you want to sync
+     only some files' contents, not the whole working tree."""]]
\ No newline at end of file

comment
diff --git a/doc/upgrades/comment_1_85fb435417aea2763f9e6631680bd5fa/comment_1_22eece2c51cd36a54a67434b317ee6e3._comment b/doc/upgrades/comment_1_85fb435417aea2763f9e6631680bd5fa/comment_1_22eece2c51cd36a54a67434b317ee6e3._comment
new file mode 100644
index 0000000..51d5965
--- /dev/null
+++ b/doc/upgrades/comment_1_85fb435417aea2763f9e6631680bd5fa/comment_1_22eece2c51cd36a54a67434b317ee6e3._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2017-03-21T17:43:33Z"
+ content="""
+@rok it's a consequence of using smudge/clean filters; git add passes
+the file through the filters.
+"""]]

comment
diff --git a/doc/bugs/cannot___40__or_how__63____41___to_pass_socket_path_with_a_space_in_its_path_via_annex-ssh-options/comment_1_d773dee03276e9b0e0b75d0709b76278._comment b/doc/bugs/cannot___40__or_how__63____41___to_pass_socket_path_with_a_space_in_its_path_via_annex-ssh-options/comment_1_d773dee03276e9b0e0b75d0709b76278._comment
new file mode 100644
index 0000000..002f9d1
--- /dev/null
+++ b/doc/bugs/cannot___40__or_how__63____41___to_pass_socket_path_with_a_space_in_its_path_via_annex-ssh-options/comment_1_d773dee03276e9b0e0b75d0709b76278._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2017-03-21T17:38:57Z"
+ content="""
+You can't accomplish this with `remote.<name>.annex-ssh-options`,
+since it is not exposed to the shell, and the parser just breaks it up into
+words.
+
+A smarter parser would be needed. Or you could configure it in
+~/.ssh/config, or perhaps make a ssh config file elsewhere and use
+annex-ssh-options to pass -F to ssh to make it use this other config file.
+
+Now that git-annex supports `GIT_SSH_COMMAND`, which is exposed to the
+shell, you should be able to accomplish it that way. I don't know if that
+would work in your use case, since the environment variable affects all ssh
+remotes, not just one.
+"""]]

comment
diff --git a/doc/tips/downloading_podcasts/comment_26_a69b4c033d85406675bb70e6996590ce._comment b/doc/tips/downloading_podcasts/comment_26_a69b4c033d85406675bb70e6996590ce._comment
new file mode 100644
index 0000000..c884f05
--- /dev/null
+++ b/doc/tips/downloading_podcasts/comment_26_a69b4c033d85406675bb70e6996590ce._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 26"""
+ date="2017-03-21T17:28:27Z"
+ content="""
+@ewen importfeed already tracks guids, since 2015. Relevant commit is
+[[!commit f95a8c867223b2e17d036d0d3377bf0fc9d3adff]]
+
+You may well have an
+older version of git-annex that didn't do that. But there are probably also
+feeds that lack a useful guid, or that even make a change that changes the
+guid of an existing item.
+
+With `git annex metadata`, you can see the `itemid` which is where the guid
+is stored.
+
+PS, please post in [[todo]] when you have a request..
+"""]]

removed
diff --git a/doc/todo/sync_content_of_a_single_directory_or_file/comment_2_4657daddd48c646510ae79394327d7b1._comment b/doc/todo/sync_content_of_a_single_directory_or_file/comment_2_4657daddd48c646510ae79394327d7b1._comment
deleted file mode 100644
index 6555cf9..0000000
--- a/doc/todo/sync_content_of_a_single_directory_or_file/comment_2_4657daddd48c646510ae79394327d7b1._comment
+++ /dev/null
@@ -1,8 +0,0 @@
-[[!comment format=mdwn
- username="konubinix"
- avatar="http://cdn.libravatar.org/avatar/72f2376231d98f52c59abd26745174fc"
- subject="Nice job!"
- date="2017-03-21T15:35:37Z"
- content="""
-I've been waiting for this for 5 years. I can't wait to use this :-).
-"""]]

removed
diff --git a/doc/todo/sync_content_of_a_single_directory_or_file/comment_3_55791b4f74a5fdf88d3fe69e4bad3486._comment b/doc/todo/sync_content_of_a_single_directory_or_file/comment_3_55791b4f74a5fdf88d3fe69e4bad3486._comment
deleted file mode 100644
index 0c80442..0000000
--- a/doc/todo/sync_content_of_a_single_directory_or_file/comment_3_55791b4f74a5fdf88d3fe69e4bad3486._comment
+++ /dev/null
@@ -1,8 +0,0 @@
-[[!comment format=mdwn
- username="konubinix"
- avatar="http://cdn.libravatar.org/avatar/72f2376231d98f52c59abd26745174fc"
- subject="Nice job!"
- date="2017-03-21T15:35:44Z"
- content="""
-I've been waiting for this for 5 years. I can't wait to use this :-).
-"""]]

removed
diff --git a/doc/todo/sync_content_of_a_single_directory_or_file/comment_4_a5739fd49aded0bb7e5b1e0deb36baa5._comment b/doc/todo/sync_content_of_a_single_directory_or_file/comment_4_a5739fd49aded0bb7e5b1e0deb36baa5._comment
deleted file mode 100644
index 11fd1ca..0000000
--- a/doc/todo/sync_content_of_a_single_directory_or_file/comment_4_a5739fd49aded0bb7e5b1e0deb36baa5._comment
+++ /dev/null
@@ -1,8 +0,0 @@
-[[!comment format=mdwn
- username="konubinix"
- avatar="http://cdn.libravatar.org/avatar/72f2376231d98f52c59abd26745174fc"
- subject="Nice job!"
- date="2017-03-21T15:35:56Z"
- content="""
-I've been waiting for this for 5 years. I can't wait to use this :-).
-"""]]

removed
diff --git a/doc/todo/sync_content_of_a_single_directory_or_file/comment_5_0957194956f2591edad945eaca7bd91f._comment b/doc/todo/sync_content_of_a_single_directory_or_file/comment_5_0957194956f2591edad945eaca7bd91f._comment
deleted file mode 100644
index 3a97261..0000000
--- a/doc/todo/sync_content_of_a_single_directory_or_file/comment_5_0957194956f2591edad945eaca7bd91f._comment
+++ /dev/null
@@ -1,8 +0,0 @@
-[[!comment format=mdwn
- username="konubinix"
- avatar="http://cdn.libravatar.org/avatar/72f2376231d98f52c59abd26745174fc"
- subject="Nice job!"
- date="2017-03-21T15:36:07Z"
- content="""
-I've been waiting for this for 5 years. I can't wait to use this :-).
-"""]]

removed
diff --git a/doc/todo/sync_content_of_a_single_directory_or_file/comment_6_5d3a04d871f7437b75d79299cbd372a8._comment b/doc/todo/sync_content_of_a_single_directory_or_file/comment_6_5d3a04d871f7437b75d79299cbd372a8._comment
deleted file mode 100644
index aebbc59..0000000
--- a/doc/todo/sync_content_of_a_single_directory_or_file/comment_6_5d3a04d871f7437b75d79299cbd372a8._comment
+++ /dev/null
@@ -1,8 +0,0 @@
-[[!comment format=mdwn
- username="konubinix"
- avatar="http://cdn.libravatar.org/avatar/72f2376231d98f52c59abd26745174fc"
- subject="Nice job!"
- date="2017-03-21T15:36:18Z"
- content="""
-I've been waiting for this for 5 years. I can't wait to use this :-).
-"""]]

Added a comment: Nice job!
diff --git a/doc/todo/sync_content_of_a_single_directory_or_file/comment_6_5d3a04d871f7437b75d79299cbd372a8._comment b/doc/todo/sync_content_of_a_single_directory_or_file/comment_6_5d3a04d871f7437b75d79299cbd372a8._comment
new file mode 100644
index 0000000..aebbc59
--- /dev/null
+++ b/doc/todo/sync_content_of_a_single_directory_or_file/comment_6_5d3a04d871f7437b75d79299cbd372a8._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="konubinix"
+ avatar="http://cdn.libravatar.org/avatar/72f2376231d98f52c59abd26745174fc"
+ subject="Nice job!"
+ date="2017-03-21T15:36:18Z"
+ content="""
+I've been waiting for this for 5 years. I can't wait to use this :-).
+"""]]

Added a comment: Nice job!
diff --git a/doc/todo/sync_content_of_a_single_directory_or_file/comment_5_0957194956f2591edad945eaca7bd91f._comment b/doc/todo/sync_content_of_a_single_directory_or_file/comment_5_0957194956f2591edad945eaca7bd91f._comment
new file mode 100644
index 0000000..3a97261
--- /dev/null
+++ b/doc/todo/sync_content_of_a_single_directory_or_file/comment_5_0957194956f2591edad945eaca7bd91f._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="konubinix"
+ avatar="http://cdn.libravatar.org/avatar/72f2376231d98f52c59abd26745174fc"
+ subject="Nice job!"
+ date="2017-03-21T15:36:07Z"
+ content="""
+I've been waiting for this for 5 years. I can't wait to use this :-).
+"""]]

Added a comment: Nice job!
diff --git a/doc/todo/sync_content_of_a_single_directory_or_file/comment_4_a5739fd49aded0bb7e5b1e0deb36baa5._comment b/doc/todo/sync_content_of_a_single_directory_or_file/comment_4_a5739fd49aded0bb7e5b1e0deb36baa5._comment
new file mode 100644
index 0000000..11fd1ca
--- /dev/null
+++ b/doc/todo/sync_content_of_a_single_directory_or_file/comment_4_a5739fd49aded0bb7e5b1e0deb36baa5._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="konubinix"
+ avatar="http://cdn.libravatar.org/avatar/72f2376231d98f52c59abd26745174fc"
+ subject="Nice job!"
+ date="2017-03-21T15:35:56Z"
+ content="""
+I've been waiting for this for 5 years. I can't wait to use this :-).
+"""]]

Added a comment: Nice job!
diff --git a/doc/todo/sync_content_of_a_single_directory_or_file/comment_3_55791b4f74a5fdf88d3fe69e4bad3486._comment b/doc/todo/sync_content_of_a_single_directory_or_file/comment_3_55791b4f74a5fdf88d3fe69e4bad3486._comment
new file mode 100644
index 0000000..0c80442
--- /dev/null
+++ b/doc/todo/sync_content_of_a_single_directory_or_file/comment_3_55791b4f74a5fdf88d3fe69e4bad3486._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="konubinix"
+ avatar="http://cdn.libravatar.org/avatar/72f2376231d98f52c59abd26745174fc"
+ subject="Nice job!"
+ date="2017-03-21T15:35:44Z"
+ content="""
+I've been waiting for this for 5 years. I can't wait to use this :-).
+"""]]

Added a comment: Nice job!
diff --git a/doc/todo/sync_content_of_a_single_directory_or_file/comment_2_4657daddd48c646510ae79394327d7b1._comment b/doc/todo/sync_content_of_a_single_directory_or_file/comment_2_4657daddd48c646510ae79394327d7b1._comment
new file mode 100644
index 0000000..6555cf9
--- /dev/null
+++ b/doc/todo/sync_content_of_a_single_directory_or_file/comment_2_4657daddd48c646510ae79394327d7b1._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="konubinix"
+ avatar="http://cdn.libravatar.org/avatar/72f2376231d98f52c59abd26745174fc"
+ subject="Nice job!"
+ date="2017-03-21T15:35:37Z"
+ content="""
+I've been waiting for this for 5 years. I can't wait to use this :-).
+"""]]

Added a comment: Nice job!
diff --git a/doc/todo/sync_content_of_a_single_directory_or_file/comment_1_2db914588ea635aeaf7031c5ca418b2f._comment b/doc/todo/sync_content_of_a_single_directory_or_file/comment_1_2db914588ea635aeaf7031c5ca418b2f._comment
new file mode 100644
index 0000000..a881ebb
--- /dev/null
+++ b/doc/todo/sync_content_of_a_single_directory_or_file/comment_1_2db914588ea635aeaf7031c5ca418b2f._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="konubinix"
+ avatar="http://cdn.libravatar.org/avatar/72f2376231d98f52c59abd26745174fc"
+ subject="Nice job!"
+ date="2017-03-21T15:35:27Z"
+ content="""
+I've been waiting for this for 5 years. I can't wait to use this :-).
+"""]]

Added a comment: Track GUIDs to avoid duplicate downloads
diff --git a/doc/tips/downloading_podcasts/comment_25_2ee88c3375eca23fe34cab65df1e7aeb._comment b/doc/tips/downloading_podcasts/comment_25_2ee88c3375eca23fe34cab65df1e7aeb._comment
new file mode 100644
index 0000000..4f39988
--- /dev/null
+++ b/doc/tips/downloading_podcasts/comment_25_2ee88c3375eca23fe34cab65df1e7aeb._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="ewen"
+ avatar="http://cdn.libravatar.org/avatar/605b2981cb52b4af268455dee7a4f64e"
+ subject="Track GUIDs to avoid duplicate downloads"
+ date="2017-03-21T08:59:59Z"
+ content="""
+While tracking podcast media URLs usually works to avoid duplicate downloads, when it fails it usually fails spectacularly. In particular if a podcast feed decides to update all the URLs (for old and new podcasts) to use a different URL scheme, then suddenly that looks like a huge volume of new URLs, and all of them get downloaded again -- even if the content has actually already been retrieved from a different URL (ie, older URL scheme). For instance the `acast.com` service has changed their URL scheme a couple of times in the last 1-2 years, rewriting all the historical URLs, so I have three copies of many of the episodes on podcasts on their service :-( (Many downloaded; some skipped once I caught the bulk download and stopped it/reran with `--fast` or `--relaxed` to make placeholders instead. `acast.com` seem to have managed to cause even more confusion by rewriting many of the older `mp3` files with new `id3` tags, thus changing the file size/hashes -- it definitely made cleaning up more complicated.)
+
+Some (all?) podcast feeds also have a `guid` field, which specifies what should be a unique per-episode and unchanging, that other podcatchers use to track \"seen this\" content.  In theory that `guid` value should be stable even across media URL changes -- at least if it isn't, then a podcaster changing the `guid` *and* media URL will almost certainly induce re-downloads in most podcatchers, and thus hopefully realise early on (eg, during testing) rather than in production.
+
+Can `git-annex` be extended to track the `guid` values as well as the filenames, so `git annex importfeed` can avoid downloading episodes where it has already processed that `guid`, and instead just add the newly listed url as an alternate web URL for that specific episode (which has been my manual work around).  Perhaps the episode `guid` could be stored as additional metadata, along with some sort of feed unique ID (link?), and then an index built/consulted when `importfeed` runs (although that \"feed unique ID\" would probably also have to be updatable by the user, to cope with \"the feed URL has now changed from `http://` to `https://` which also seems to be happening a bunch at present.)
+
+Ewen
+
+PS: Apologies for duplicate partial comment; I think my browser decided some key combination meant \"do default form action\", which is post -- and I wasn't finished writing.  I couldn't see a way to edit the comment, hence deleting/readding.
+
+"""]]

removed
diff --git a/doc/tips/downloading_podcasts/comment_25_211b8f829070021e977c6de9eebf829f._comment b/doc/tips/downloading_podcasts/comment_25_211b8f829070021e977c6de9eebf829f._comment
deleted file mode 100644
index 7588598..0000000
--- a/doc/tips/downloading_podcasts/comment_25_211b8f829070021e977c6de9eebf829f._comment
+++ /dev/null
@@ -1,10 +0,0 @@
-[[!comment format=mdwn
- username="ewen"
- avatar="http://cdn.libravatar.org/avatar/605b2981cb52b4af268455dee7a4f64e"
- subject="Track GUIDs to avoid duplicate downloads"
- date="2017-03-21T08:48:04Z"
- content="""
-While tracking podcast media URLs *usually* works to avoid duplicate downloads, when it fails it usually fails spectacularly.  In particular if a podcast feed decides to update *all* the URLs (for old and new podcasts) to use a different URL scheme, then suddenly that looks like a huge volume of new URLs, and all of them get downloaded -- even if the content has actually already been retrieved from a different URL.  For instance the `acast.com` service has changed their URL scheme a couple of times in the last 1-2 years, rewriting all the historical URLs, so I have three copies of many of the episodes on podcasts on their service :-(  (Many downloaded; some skipped once I caught the bulk download and stopped it/reran with `--fast` or `--relaxed` to make placeholders instead.  `acast.com` seem to have managed to cause even more confusion by rewriting many of the older `mp3` files with new `id3)
-
-Some (all?) podcast feeds also have a `guid` field, which specifies what should be a unique per-episode
-"""]]

Added a comment: Track GUIDs to avoid duplicate downloads
diff --git a/doc/tips/downloading_podcasts/comment_25_211b8f829070021e977c6de9eebf829f._comment b/doc/tips/downloading_podcasts/comment_25_211b8f829070021e977c6de9eebf829f._comment
new file mode 100644
index 0000000..7588598
--- /dev/null
+++ b/doc/tips/downloading_podcasts/comment_25_211b8f829070021e977c6de9eebf829f._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="ewen"
+ avatar="http://cdn.libravatar.org/avatar/605b2981cb52b4af268455dee7a4f64e"
+ subject="Track GUIDs to avoid duplicate downloads"
+ date="2017-03-21T08:48:04Z"
+ content="""
+While tracking podcast media URLs *usually* works to avoid duplicate downloads, when it fails it usually fails spectacularly.  In particular if a podcast feed decides to update *all* the URLs (for old and new podcasts) to use a different URL scheme, then suddenly that looks like a huge volume of new URLs, and all of them get downloaded -- even if the content has actually already been retrieved from a different URL.  For instance the `acast.com` service has changed their URL scheme a couple of times in the last 1-2 years, rewriting all the historical URLs, so I have three copies of many of the episodes on podcasts on their service :-(  (Many downloaded; some skipped once I caught the bulk download and stopped it/reran with `--fast` or `--relaxed` to make placeholders instead.  `acast.com` seem to have managed to cause even more confusion by rewriting many of the older `mp3` files with new `id3)
+
+Some (all?) podcast feeds also have a `guid` field, which specifies what should be a unique per-episode
+"""]]

Added a comment: Beware global configurations!
diff --git a/doc/tips/largefiles/comment_8_f036356b23a4690705a2b4df604e82ba._comment b/doc/tips/largefiles/comment_8_f036356b23a4690705a2b4df604e82ba._comment
new file mode 100644
index 0000000..d984589
--- /dev/null
+++ b/doc/tips/largefiles/comment_8_f036356b23a4690705a2b4df604e82ba._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="joern.mankiewicz@06fb5bc9b732f143dee3606866362f562531310d"
+ nickname="joern.mankiewicz"
+ avatar="http://cdn.libravatar.org/avatar/446365f4d50dddc42965fa0432e70cdb"
+ subject="Beware global configurations!"
+ date="2017-03-20T22:47:50Z"
+ content="""
+Thanks, joey.
+
+Your last comment brought me onto the right track. The Problem was not in the repository, but an old stale global .gitconfig in my homedir. I just checked $XDG_CONFIG_HOME/git/config were currently my global git-config is residing and totaly forgot about this old config. Stupid me!
+
+    git config --show-origin --get annex.largefiles
+
+was my savior here as it clearly indicated that there is indeed a (unintended) config setting and where to find the file. So i can strongly recommend anybody experiencing strange behavior to try this one-liner. It might have saved me hours of time.
+
+Thanks for your help! :)
+
+Cheers
+
+Jörn
+"""]]

comment
diff --git a/doc/tips/largefiles/comment_7_35a634c5e6d780972b9e938065837988._comment b/doc/tips/largefiles/comment_7_35a634c5e6d780972b9e938065837988._comment
new file mode 100644
index 0000000..bcb87bb
--- /dev/null
+++ b/doc/tips/largefiles/comment_7_35a634c5e6d780972b9e938065837988._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 7"""
+ date="2017-03-20T21:18:24Z"
+ content="""
+Note that if annex.largefiles is set in git config (including global git
+config), it overrides the .gitattributes setting. So a reasonable guess
+would be that you set it in the git config.
+"""]]

response
diff --git a/doc/tips/largefiles/comment_6_639b1492271643566846b48fe13f7b8d._comment b/doc/tips/largefiles/comment_6_639b1492271643566846b48fe13f7b8d._comment
new file mode 100644
index 0000000..7c5733f
--- /dev/null
+++ b/doc/tips/largefiles/comment_6_639b1492271643566846b48fe13f7b8d._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 6"""
+ date="2017-03-20T21:16:30Z"
+ content="""
+@joern.mankiewicz, you need to file a bug report with enough information to
+reproduce your problem.
+
+annex.largefiles in .gitattributes works fine:
+
+	joey@darkstar:~/tmp> git init ttt
+	Initialized empty Git repository in /home/joey/tmp/ttt/.git/
+	joey@darkstar:~/tmp> cd ttt
+	joey@darkstar:~/tmp/ttt> git annex init
+	init  ok
+	(recording state in git...)
+	joey@darkstar:~/tmp/ttt> echo '* annex.largefiles=nothing' > .gitattributes
+	joey@darkstar:~/tmp/ttt> touch foo
+	joey@darkstar:~/tmp/ttt> git annex add foo
+	add foo (non-large file; adding content to git repository) ok
+	(recording state in git...)
+"""]]

devblog
diff --git a/doc/devblog/day_453_release_prep.mdwn b/doc/devblog/day_453_release_prep.mdwn
new file mode 100644
index 0000000..8a0a90d
--- /dev/null
+++ b/doc/devblog/day_453_release_prep.mdwn
@@ -0,0 +1,13 @@
+Preparing for a release tomorrow. Yury fixed the Windows autobuilder over
+the weekend. The OSX autobuilder was broken by my changes Friday, which
+turned out to have a simple bug that took quite a long time to chase down.
+
+Also added `git annex sync --content-of=path` to sync the contents of files
+in a path, rather than in the whole work tree as `--content` does. I would
+have rather made this be `--content=path` but optparse-applicative 
+[does not support](https://github.com/pcapriotti/optparse-applicative/issues/243)
+options that can be either boolean or have a string value. Really,
+I'd rather `git annex sync path` do it, but that would be ambiguous
+with the remote name parameter.
+
+Today's work was sponsored by Jake Vosloo on Patreon.

Added a comment: Git-annex ignores annex.largefiles in .gitattributes
diff --git a/doc/tips/largefiles/comment_5_20c6702f83dbade1ac4d6eee30c40b4b._comment b/doc/tips/largefiles/comment_5_20c6702f83dbade1ac4d6eee30c40b4b._comment
new file mode 100644
index 0000000..1bded60
--- /dev/null
+++ b/doc/tips/largefiles/comment_5_20c6702f83dbade1ac4d6eee30c40b4b._comment
@@ -0,0 +1,32 @@
+[[!comment format=mdwn
+ username="joern.mankiewicz@06fb5bc9b732f143dee3606866362f562531310d"
+ nickname="joern.mankiewicz"
+ avatar="http://cdn.libravatar.org/avatar/446365f4d50dddc42965fa0432e70cdb"
+ subject="Git-annex ignores annex.largefiles in .gitattributes"
+ date="2017-03-20T20:58:12Z"
+ content="""
+Hi guys!
+
+*sigh*
+
+Currently I am pulling my hair, maybe anybody here can clear things up a bit. I tried to setup a brand new mixed content repo with git-annex but it bluntly ignores my .gitattributes and annexes everything. When I set largefiles in config everything is fine and restrictions are applied right, in .gitattributes even a \"* annex.largefiles=nothing\" has no effect. All attributes show up right with git check-attr, I double checked. :-/ Same thing with a newly initialized minimal example repo. 
+
+I tried git-annex as distributed by openSUSE and the current stand-alone-package (in case it's a distribution bug), too. So no clues here, too.
+
+Output of git annex version:
+
+git-annex version: 6.20170302-gb35a50cca
+build flags: Assistant Webapp Pairing Testsuite S3(multipartupload)(storageclasses) WebDAV Inotify DBus DesktopNotify 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 p2p S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external
+
+System: OpenSUSE Tumbleweed
+Linux 4.9.3-1-default #1 SMP PREEMPT Thu Jan 12 11:32:53 UTC 2017 (2c7dfab) x86_64 x86_64 x86_64 GNU/Linux
+
+
+Any ideas? After trying around for hours I am somewhat flabberghasted. Did I miss some config- or buildoption to enable support for .gitattributes? 
+
+Kind regards
+
+Jörn
+"""]]

sync --content-of=path
For when you want to sync only some files' contents, not the whole working
tree.
This commit was sponsored by Anthony DeRobertis on Patreon.
diff --git a/CHANGELOG b/CHANGELOG
index ceaa043..7c81241 100644
--- a/CHANGELOG
+++ b/CHANGELOG
@@ -24,6 +24,8 @@ git-annex (6.20170301.2) UNRELEASED; urgency=medium
   * Support GIT_SSH and GIT_SSH_COMMAND, which are handled close the same
     as they are by git. However, unlike git, git-annex sometimes needs to
     pass the -n parameter when using these.
+  * sync --content-of=path (-C path) added for when you want to sync
+    only some files' contents, not the whole working tree.
 
  -- Joey Hess <id@joeyh.name>  Thu, 02 Mar 2017 12:51:40 -0400
 
diff --git a/Command/Sync.hs b/Command/Sync.hs
index d4d45e2..f2c1945 100644
--- a/Command/Sync.hs
+++ b/Command/Sync.hs
@@ -63,7 +63,7 @@ cmd :: Command
 cmd = withGlobalOptions [jobsOption] $
 	command "sync" SectionCommon 
 		"synchronize local repository with remotes"
-		(paramRepeating paramRemote) (seek <$$> optParser)
+		(paramRepeating paramRemote) (seek <--< optParser)
 
 data SyncOptions  = SyncOptions
 	{ syncWith :: CmdParams
@@ -74,6 +74,7 @@ data SyncOptions  = SyncOptions
 	, pushOption :: Bool
 	, contentOption :: Bool
 	, noContentOption :: Bool
+	, contentOfOption :: [FilePath]
 	, keyOptions :: Maybe KeyOptions
 	}
 
@@ -109,8 +110,29 @@ optParser desc = SyncOptions
 		( long "no-content"
 		<> help "do not transfer file contents"
 		)
+	<*> many (strOption
+		( long "content-of"
+		<> short 'C'
+		<> help "transfer file contents of files in a given location"
+		<> metavar paramPath
+		))
 	<*> optional parseAllOption
 
+-- Since prepMerge changes the working directory, FilePath options
+-- have to be adjusted.
+instance DeferredParseClass SyncOptions where
+	finishParse v = SyncOptions
+		<$> pure (syncWith v)
+		<*> pure (commitOption v)
+		<*> pure (noCommitOption v)
+		<*> pure (messageOption v)
+		<*> pure (pullOption v)
+		<*> pure (pushOption v)
+		<*> pure (contentOption v)
+		<*> pure (noContentOption v)
+		<*> liftIO (mapM absPath (contentOfOption v))
+		<*> pure (keyOptions v)
+
 seek :: SyncOptions -> CommandSeek
 seek o = allowConcurrentOutput $ do
 	prepMerge
@@ -148,6 +170,7 @@ seek o = allowConcurrentOutput $ do
 	mapM_ (commandAction . withbranch . pushRemote o) gitremotes
   where
 	shouldsynccontent = pure (contentOption o)
+		<||> pure (not (null (contentOfOption o)))
 		<||> (pure (not (noContentOption o)) <&&> getGitConfigVal annexSyncContent)
 
 type CurrBranch = (Maybe Git.Branch, Maybe Adjustment)
@@ -510,7 +533,7 @@ seekSyncContent o rs = do
 	mvar <- liftIO newEmptyMVar
 	bloom <- case keyOptions o of
 		Just WantAllKeys -> Just <$> genBloomFilter (seekworktree mvar [])
-		_ -> seekworktree mvar [] (const noop) >> pure Nothing
+		_ -> seekworktree mvar (contentOfOption o) (const noop) >> pure Nothing
 	withKeyOptions' (keyOptions o) False
 		(return (seekkeys mvar bloom))
 		(const noop)
diff --git a/doc/git-annex-sync.mdwn b/doc/git-annex-sync.mdwn
index e29698c..97c63d3 100644
--- a/doc/git-annex-sync.mdwn
+++ b/doc/git-annex-sync.mdwn
@@ -73,6 +73,14 @@ by running "git annex sync" on the remote.
   This behavior can be overridden by configuring the preferred content
   of a repository. See [[git-annex-preferred-content]](1).
 
+* `--content-of=path` `-C path`
+
+  While --content operates on all annexed files in the work tree,
+  --content-of allows limiting the transferred files to ones in a given
+  location.
+
+  This option can be repeated multiple times with different paths.
+
 * `--all`
 
   This option, when combined with `--content`, makes all available versions
diff --git a/doc/todo/sync_content_of_a_single_directory_or_file.mdwn b/doc/todo/sync_content_of_a_single_directory_or_file.mdwn
index bbb036f..90eb3b4 100644
--- a/doc/todo/sync_content_of_a_single_directory_or_file.mdwn
+++ b/doc/todo/sync_content_of_a_single_directory_or_file.mdwn
@@ -9,3 +9,6 @@ currently takes. Perhaps `git annex sync --dir==thedir`, which
 automatically enables content syncing?
 
 --[[Joey]]
+
+> Going with --content-of, so it's clear it enables content syncing.
+> With a -C short option. [[done]] --[[Joey]]

todo
diff --git a/doc/todo/sync_content_of_a_single_directory_or_file.mdwn b/doc/todo/sync_content_of_a_single_directory_or_file.mdwn
new file mode 100644
index 0000000..bbb036f
--- /dev/null
+++ b/doc/todo/sync_content_of_a_single_directory_or_file.mdwn
@@ -0,0 +1,11 @@
+`git annex sync --content` operates on the whole work tree, not only the
+current directory. This is different than other git-annex commands, and
+makes sense in a way since git pull works like that too. But, sometimes
+I only want the content of a single directory, or perhaps file. 
+
+This could be implemented as `git annex sync --content thedir`, except
+that would conflict with the name of the remote to sync with that it
+currently takes. Perhaps `git annex sync --dir==thedir`, which
+automatically enables content syncing?
+
+--[[Joey]]

diff --git a/doc/forum/special_remote_which_applies_a_lossless_operation_in__47__out.mdwn b/doc/forum/special_remote_which_applies_a_lossless_operation_in__47__out.mdwn
new file mode 100644
index 0000000..37a60bc
--- /dev/null
+++ b/doc/forum/special_remote_which_applies_a_lossless_operation_in__47__out.mdwn
@@ -0,0 +1,9 @@
+Hi,
+
+I'd like to modify the directory special remote, to compress/deflate files before the store/retrieve operations. Purpose is to gain size, with a lossless compression, different depending on the file type (LZMA as a default, dropbox-lepton for jpegs, etc...).
+
+Before I go on, I wonder if the file content modification will interfere with git annex internals.
+It seems it won't, from what I see in the special remote basic exemple given in https://git-annex.branchable.com/special_remotes/external/
+Can someone confirm ?
+
+Thks

devblog
diff --git a/doc/devblog/day_452__GIT_SSH.mdwn b/doc/devblog/day_452__GIT_SSH.mdwn
new file mode 100644
index 0000000..7ba94df
--- /dev/null
+++ b/doc/devblog/day_452__GIT_SSH.mdwn
@@ -0,0 +1,17 @@
+Found a bug in git-annex-shell where verbose messages would sometimes make
+it output things git-annex didn't expect.
+
+While fixing that, I wanted to add a test case, but the test suite actually
+does not test git-annex-shell at all. It would need to ssh, which test
+suites should not do. So, I took a detour..
+
+Support for `GIT_SSH` and `GIT_SSH_COMMAND` has been requested before for
+various reasons. So I implemented that, which took 4 hours. (With one
+little possible compatability caveat, since git-annex needs to pass the -n
+parameter to ssh sometimes, and git's interface doesn't allow for such a
+parameter.)
+
+Now the test suite can use those environment variables to make mock ssh
+remotes be accessed using local `sh` instead of `ssh`.
+
+Today's work was sponsored by Trenton Cronholm on Patreon.

Support GIT_SSH and GIT_SSH_COMMAND
They are handled close the same as they are by git. However, unlike git,
git-annex sometimes needs to pass the -n parameter when using these.
So, this has the potential for breaking some setup, and perhaps there ought
to be a ANNEX_USE_GIT_SSH=1 needed to use these. But I'd rather avoid that
if possible, so let's see if anyone complains.
Almost all places where "ssh" was run have been changed to support the env
vars. Anything still calling sshOptions does not support them. In
particular, rsync special remotes don't. Seems that annex-rsync-transport
already gives sufficient control there.
(Fixed in passing: Remote.Helper.Ssh.toRepo used to extract
remoteAnnexSshOptions and pass them to sshOptions, which was redundant
since sshOptions also extracts those.)
This commit was sponsored by Jeff Goeke-Smith on Patreon.
diff --git a/Annex/Ssh.hs b/Annex/Ssh.hs
index f01cb64..4f2b492 100644
--- a/Annex/Ssh.hs
+++ b/Annex/Ssh.hs
@@ -9,6 +9,8 @@
 
 module Annex.Ssh (
 	ConsumeStdin(..),
+	SshCommand,
+	sshCommand,
 	sshOptions,
 	sshCacheDir,
 	sshReadPort,
@@ -37,6 +39,7 @@ import Utility.Env
 import Utility.FileSystemEncoding
 import Types.CleanupActions
 import Git.Env
+import Git.Ssh
 #ifndef mingw32_HOST_OS
 import Annex.Perms
 import Annex.LockPool
@@ -47,8 +50,22 @@ import Annex.LockPool
  - not be allowed to consume the process's stdin. -}
 data ConsumeStdin = ConsumeStdin | NoConsumeStdin
 
+{- Generates a command to ssh to a given host (or user@host) on a given
+ - port. This includes connection caching parameters, and any ssh-options.
+ - If GIT_SSH or GIT_SSH_COMMAND is set, they are used instead. -}
+sshCommand :: ConsumeStdin -> (SshHost, Maybe SshPort) -> RemoteGitConfig -> SshCommand -> Annex (FilePath, [CommandParam])
+sshCommand cs (host, port) gc remotecmd =
+	go =<< liftIO (gitSsh host port remotecmd)
+  where
+	go (Just (c, ps)) = return (c, consumeStdinParams cs ++ ps)
+	go Nothing = do
+		ps <- sshOptions cs (host, port) gc []
+		return ("ssh", Param host:ps++[Param remotecmd])
+
 {- Generates parameters to ssh to a given host (or user@host) on a given
- - port. This includes connection caching parameters, and any ssh-options. -}
+ - port. This includes connection caching parameters, and any
+ - ssh-options. Note that the host to ssh to and the command to run
+ - are not included in the returned options. -}
 sshOptions :: ConsumeStdin -> (String, Maybe Integer) -> RemoteGitConfig -> [CommandParam] -> Annex [CommandParam]
 sshOptions cs (host, port) gc opts = go =<< sshCachingInfo (host, port)
   where
@@ -61,12 +78,14 @@ sshOptions cs (host, port) gc opts = go =<< sshCachingInfo (host, port)
 		, map Param (remoteAnnexSshOptions gc)
 		, opts
 		, portParams port
-		, case cs of
-			ConsumeStdin -> []
-			NoConsumeStdin -> [Param "-n"]
+		, consumeStdinParams cs
 		, [Param "-T"]
 		]
 
+consumeStdinParams :: ConsumeStdin -> [CommandParam]
+consumeStdinParams ConsumeStdin = []
+consumeStdinParams NoConsumeStdin = [Param "-n"]
+
 {- Returns a filename to use for a ssh connection caching socket, and
  - parameters to enable ssh connection caching. -}
 sshCachingInfo :: (String, Maybe Integer) -> Annex (Maybe FilePath, [CommandParam])
@@ -285,19 +304,24 @@ inRepoWithSshOptionsTo remote gc a =
 {- To make any git commands be run with ssh caching enabled,
  - and configured ssh-options alters the local Git.Repo's gitEnv
  - to set GIT_SSH=git-annex, and set sshOptionsEnv when running git
- - commands. -}
+ - commands.
+ -
+ - If GIT_SSH or GIT_SSH_COMMAND are set, this has no effect. -}
 sshOptionsTo :: Git.Repo -> RemoteGitConfig -> Git.Repo -> Annex Git.Repo
 sshOptionsTo remote gc localr
 	| not (Git.repoIsUrl remote) || Git.repoIsHttp remote = unchanged
 	| otherwise = case Git.Url.hostuser remote of
 		Nothing -> unchanged
-		Just host -> do
-			(msockfile, _) <- sshCachingInfo (host, Git.Url.port remote)
-			case msockfile of
-				Nothing -> use []
-				Just sockfile -> do
-					prepSocket sockfile
-					use (sshConnectionCachingParams sockfile)
+		Just host -> ifM (liftIO gitSshEnvSet)
+			( unchanged
+			, do
+				(msockfile, _) <- sshCachingInfo (host, Git.Url.port remote)
+				case msockfile of
+					Nothing -> use []
+					Just sockfile -> do
+						prepSocket sockfile
+						use (sshConnectionCachingParams sockfile)
+			)
   where
 	unchanged = return localr
 
@@ -313,7 +337,7 @@ sshOptionsTo remote gc localr
 				liftIO $ do
 					localr' <- addGitEnv localr sshOptionsEnv
 						(toSshOptionsEnv sshopts)
-					addGitEnv localr' "GIT_SSH" command
+					addGitEnv localr' gitSshEnv command
 
 runSshOptions :: [String] -> String -> IO ()
 runSshOptions args s = do
diff --git a/CHANGELOG b/CHANGELOG
index 281c59d..ceaa043 100644
--- a/CHANGELOG
+++ b/CHANGELOG
@@ -21,6 +21,9 @@ git-annex (6.20170301.2) UNRELEASED; urgency=medium
     where "merging" messages were included in the output of configlist
     (and perhaps other commands) and caused a "Failed to get annex.uuid
     configuration" error.
+  * Support GIT_SSH and GIT_SSH_COMMAND, which are handled close the same
+    as they are by git. However, unlike git, git-annex sometimes needs to
+    pass the -n parameter when using these.
 
  -- Joey Hess <id@joeyh.name>  Thu, 02 Mar 2017 12:51:40 -0400
 
diff --git a/Command/Map.hs b/Command/Map.hs
index eb08037..ae568f8 100644
--- a/Command/Map.hs
+++ b/Command/Map.hs
@@ -224,10 +224,10 @@ tryScan r
 		(pipedconfig, return Nothing) "configlist" [] []
 	manualconfiglist = do
 		gc <- Annex.getRemoteGitConfig r
-		sshparams <- Ssh.toRepo NoConsumeStdin r gc [Param sshcmd]
-		liftIO $ pipedconfig "ssh" sshparams
+		(sshcmd, sshparams) <- Ssh.toRepo NoConsumeStdin r gc remotecmd
+		liftIO $ pipedconfig sshcmd sshparams
 	  where
-		sshcmd = "sh -c " ++ shellEscape
+		remotecmd = "sh -c " ++ shellEscape
 			(cddir ++ " && " ++ "git config --null --list")
 		dir = Git.repoPath r
 		cddir
diff --git a/Git/Ssh.hs b/Git/Ssh.hs
new file mode 100644
index 0000000..b5d90d7
--- /dev/null
+++ b/Git/Ssh.hs
@@ -0,0 +1,68 @@
+{- GIT_SSH and GIT_SSH_COMMAND support
+ -
+ - Copyright 2017 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU GPL version 3 or higher.
+ -}
+
+module Git.Ssh where
+
+import Common
+import Utility.Env
+
+import Data.Char
+
+gitSshEnv :: String
+gitSshEnv = "GIT_SSH"
+
+gitSshCommandEnv :: String
+gitSshCommandEnv = "GIT_SSH_COMMAND"
+
+gitSshEnvSet :: IO Bool
+gitSshEnvSet = anyM (isJust <$$> getEnv) [gitSshEnv, gitSshCommandEnv]
+
+-- Either a hostname, or user@host
+type SshHost = String
+
+type SshPort = Integer
+
+-- Command to run on the remote host. It is run by the shell
+-- there, so any necessary shell escaping of parameters in it should
+-- already be done.
+type SshCommand = String
+
+-- | Checks for GIT_SSH and GIT_SSH_COMMAND and if set, returns
+-- a command and parameters to run to ssh.
+gitSsh :: SshHost -> Maybe SshPort -> SshCommand -> IO (Maybe (FilePath, [CommandParam]))
+gitSsh host mp cmd = do
+	gsc <- getEnv gitSshCommandEnv
+	case gsc of
+		Just c
+			-- git only runs the command with the shell
+			-- when it contains spaces; otherwise it's
+			-- treated the same as GIT_SSH
+			| any isSpace c -> ret "sh"
+				[ [ Param "-c"
+				  , Param (c ++ " \"$@\"")
+				  , Param c
+				  ]
+				, gitps
+				-- cmd is already shell escaped
+				-- for the remote side, but needs to be
+				-- shell-escaped once more since it's
+				-- passed through the local shell.
+				, [ Param $ shellEscape $ cmd ]
+				]
+			| otherwise -> ret c [ gitps, [Param cmd]]
+		Nothing -> do

(Diff truncated)
git-annex-shell: run all commands with noMessages
Fix bug when used with a recently cloned repository, where
"merging" messages were included in the output of configlist (and perhaps
other commands) and caused a "Failed to get annex.uuid configuration"
error.
This does not seem to have been a reversion.
I saw this with configlist, but it seems possible for other commands to be
effected, and it might not always happen only after a fresh clone. Eg, if a
foo/git-annex branch is pushed to the remote, the next git-annex-shell will
auto-merge it and display the message.
Decided to run all git-annex-shell commands with noMessages,
even ones that don't currently use stdout for structured communication.
Better to keep open the possibility for using stdout in the future.
This commit was supported by the NSF-funded DataLad project
diff --git a/CHANGELOG b/CHANGELOG
index 443adb6..281c59d 100644
--- a/CHANGELOG
+++ b/CHANGELOG
@@ -17,6 +17,10 @@ git-annex (6.20170301.2) UNRELEASED; urgency=medium
     directory, feed, and http-types.
   * Windows: Fix bug in shell script shebang lookup code that
     caused a "delayed read on closed handle" error.
+  * git-annex-shell: Fix bug when used with a recently cloned repository,
+    where "merging" messages were included in the output of configlist
+    (and perhaps other commands) and caused a "Failed to get annex.uuid
+    configuration" error.
 
  -- Joey Hess <id@joeyh.name>  Thu, 02 Mar 2017 12:51:40 -0400
 
diff --git a/CmdLine/GitAnnexShell.hs b/CmdLine/GitAnnexShell.hs
index 70c86ec..154bfeb 100644
--- a/CmdLine/GitAnnexShell.hs
+++ b/CmdLine/GitAnnexShell.hs
@@ -48,7 +48,7 @@ cmds_notreadonly =
 	]
 
 cmds :: [Command]
-cmds = map adddirparam $ cmds_readonly ++ cmds_notreadonly
+cmds = map (adddirparam . noMessages) (cmds_readonly ++ cmds_notreadonly)
   where
 	adddirparam c = c { cmdparamdesc = "DIRECTORY " ++ cmdparamdesc c }
 
diff --git a/doc/bugs/sync_with_clone_protocol_error.mdwn b/doc/bugs/sync_with_clone_protocol_error.mdwn
index 47b6148..2ae0cab 100644
--- a/doc/bugs/sync_with_clone_protocol_error.mdwn
+++ b/doc/bugs/sync_with_clone_protocol_error.mdwn
@@ -11,3 +11,5 @@ Next git-annex sync clam worked ok and got the UUID.
 
 clam has git-annex 6.20170101 installed.
 --[[Joey]]
+
+> [[fixed|done]] --[[Joey]]

fixing ben
diff --git a/doc/users/datalad.mdwn b/doc/users/datalad.mdwn
index d857163..7726af0 100644
--- a/doc/users/datalad.mdwn
+++ b/doc/users/datalad.mdwn
@@ -2,22 +2,22 @@ TODOs for DataLad
 =================
 
 [[!inline pages="todo/* and !todo/done and !link(todo/done) and
-(author(yoh) or author(mih) or author(beh))" sort=mtime feeds=no actions=yes archive=yes show=0]]
+(author(yoh) or author(mih) or author(ben))" sort=mtime feeds=no actions=yes archive=yes show=0]]
 
 Done
 ----
 
 [[!inline pages="todo/* and !todo/done and link(todo/done) and
-(author(yoh) or author(mih) or author(beh))" feeds=no actions=yes archive=yes show=0]]
+(author(yoh) or author(mih) or author(ben))" feeds=no actions=yes archive=yes show=0]]
 
 My bugs
 =======
 
 [[!inline pages="bugs/* and !bugs/done and !link(bugs/done) and
-(author(yoh) or author(mih) or author(beh))" sort=mtime feeds=no actions=yes archive=yes show=0  template=buglist]]
+(author(yoh) or author(mih) or author(ben))" sort=mtime feeds=no actions=yes archive=yes show=0  template=buglist]]
 
 Fixed
 -----
 
 [[!inline pages="bugs/* and !bugs/done and link(bugs/done) and
-(author(yoh) or author(mih) or author(beh))" feeds=no actions=yes archive=yes show=0  template=buglist]]
+(author(yoh) or author(mih) or author(ben))" feeds=no actions=yes archive=yes show=0  template=buglist]]

added Ben
diff --git a/doc/users/datalad.mdwn b/doc/users/datalad.mdwn
index 1aad07c..d857163 100644
--- a/doc/users/datalad.mdwn
+++ b/doc/users/datalad.mdwn
@@ -2,22 +2,22 @@ TODOs for DataLad
 =================
 
 [[!inline pages="todo/* and !todo/done and !link(todo/done) and
-(author(yoh) or author(mih))" sort=mtime feeds=no actions=yes archive=yes show=0]]
+(author(yoh) or author(mih) or author(beh))" sort=mtime feeds=no actions=yes archive=yes show=0]]
 
 Done
 ----
 
 [[!inline pages="todo/* and !todo/done and link(todo/done) and
-(author(yoh) or author(mih))" feeds=no actions=yes archive=yes show=0]]
+(author(yoh) or author(mih) or author(beh))" feeds=no actions=yes archive=yes show=0]]
 
 My bugs
 =======
 
 [[!inline pages="bugs/* and !bugs/done and !link(bugs/done) and
-(author(yoh) or author(mih))" sort=mtime feeds=no actions=yes archive=yes show=0  template=buglist]]
+(author(yoh) or author(mih) or author(beh))" sort=mtime feeds=no actions=yes archive=yes show=0  template=buglist]]
 
 Fixed
 -----
 
 [[!inline pages="bugs/* and !bugs/done and link(bugs/done) and
-(author(yoh) or author(mih))" feeds=no actions=yes archive=yes show=0  template=buglist]]
+(author(yoh) or author(mih) or author(beh))" feeds=no actions=yes archive=yes show=0  template=buglist]]

bug report
diff --git a/doc/bugs/sync_with_clone_protocol_error.mdwn b/doc/bugs/sync_with_clone_protocol_error.mdwn
new file mode 100644
index 0000000..47b6148
--- /dev/null
+++ b/doc/bugs/sync_with_clone_protocol_error.mdwn
@@ -0,0 +1,13 @@
+	Failed to get annex.uuid configuration of repository clam
+
+	Instead, got: "(merging origin/git-annex origin/synced/git-annex into git-annex...)\n(recording state in git...)\nannex.uuid=$obscured\ncore.gcrypt-id=\n"
+
+Seen after cloning the repository to clam, not running git-annex init
+in it, adding clam as a remote, and git annex sync clam.
+Apparently git-annex-shell outputs some merging messages in this 
+case, which breaks the protocol. 
+
+Next git-annex sync clam worked ok and got the UUID.
+
+clam has git-annex 6.20170101 installed.
+--[[Joey]]

diff --git a/doc/bugs/cannot___40__or_how__63____41___to_pass_socket_path_with_a_space_in_its_path_via_annex-ssh-options.mdwn b/doc/bugs/cannot___40__or_how__63____41___to_pass_socket_path_with_a_space_in_its_path_via_annex-ssh-options.mdwn
new file mode 100644
index 0000000..cc0eed8
--- /dev/null
+++ b/doc/bugs/cannot___40__or_how__63____41___to_pass_socket_path_with_a_space_in_its_path_via_annex-ssh-options.mdwn
@@ -0,0 +1,31 @@
+### Please describe the problem.
+
+git annex specifies its own socket path via -S.  To overload with our socket path (to be reused by annex and other ssh invocations) we need to provide the path via annex-ssh-options option.  And we cannot pass it as an overload -o ControlPath since -S specification provided by annex "overrides" it.
+The difficulty comes in possibly not quite common but still possible case when path to the socket contains a space.  I have tried all kinds of possible specifications but failed to find one which works... 
+
+Could you give me a hint!? ;)
+
+### What version of git-annex are you using? On what operating system?
+
+6.20170307+gitg24ade8a25-1~ndall+1
+
+### Please provide any additional information below.
+
+[[!format sh """
+# so -- ssh works
+$> ssh -O check -oControlMaster=auto -S"/tmp/te st/socket" 'yohtest@smaug'
+Master running (pid=20336)
+# but can't get annex to use it:
+
+$> git annex init -c 'remote.origin.annex-ssh-options=-oControlMaster=auto -S"/tmp/te st/socket"' 
+init  ssh: Could not resolve hostname st/socket": Name or service not known   
+yohtest@smaug's password: 
+
+$> git annex init -c 'remote.origin.annex-ssh-options=-oControlMaster=auto "-S\"/tmp/te st/socket\""' 
+init  ssh: Could not resolve hostname "-s\\"/tmp/te: Name or service not known
+yohtest@smaug's password: 
+
+# etc
+"""]]
+
+[[!meta author=yoh]]

Added a comment: v6 default behavior
diff --git a/doc/upgrades/comment_1_85fb435417aea2763f9e6631680bd5fa._comment b/doc/upgrades/comment_1_85fb435417aea2763f9e6631680bd5fa._comment
new file mode 100644
index 0000000..c58f63e
--- /dev/null
+++ b/doc/upgrades/comment_1_85fb435417aea2763f9e6631680bd5fa._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="rok"
+ avatar="http://cdn.libravatar.org/avatar/a80e31241cb35a3cf9bf8de34e05fc2d"
+ subject="v6 default behavior"
+ date="2017-03-16T09:24:50Z"
+ content="""
+I'm curious about the choice to change the behavior of critical git commands (such as add) in such a drastic way in V6, i.e. why does \"git add\" no longer add files to the git repo? The default of annex should be exclusive rather than inclusive, I shouldn't need to specify which files to *exclude* from annex, rather the other way around. This is an especially confusing default for code. What is the logic here? 
+"""]]

Added a comment
diff --git a/doc/bugs/Excessively_long_temp_names_preventing___34__get__34___on_Windows/comment_2_7d691fe40bb134d0f270ed3a9cfbf659._comment b/doc/bugs/Excessively_long_temp_names_preventing___34__get__34___on_Windows/comment_2_7d691fe40bb134d0f270ed3a9cfbf659._comment
new file mode 100644
index 0000000..7ba0734
--- /dev/null
+++ b/doc/bugs/Excessively_long_temp_names_preventing___34__get__34___on_Windows/comment_2_7d691fe40bb134d0f270ed3a9cfbf659._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="kubaello@d561f15ff5c07a78b706b096375cd89d6d706066"
+ nickname="kubaello"
+ avatar="http://cdn.libravatar.org/avatar/df2d1d9871b92552b99c3bacf442d739"
+ subject="comment 2"
+ date="2017-03-16T01:22:44Z"
+ content="""
+I came across the same problem today and I think I've found a workaround: [long paths on windows 10 - workaround](https://git-annex.branchable.com/forum/long_paths_on_windows_10_-_workaround/). It turns out Windows 10 allows enabling support for long paths with a single registry modification - unfortunately it is a system level setting, so it can potentially break some other programs.
+"""]]

diff --git a/doc/forum/long_paths_on_windows_10_-_workaround.mdwn b/doc/forum/long_paths_on_windows_10_-_workaround.mdwn
new file mode 100644
index 0000000..b51bcac
--- /dev/null
+++ b/doc/forum/long_paths_on_windows_10_-_workaround.mdwn
@@ -0,0 +1,9 @@
+It seems git-annex has some serious problems with long paths on windows systems. I would like to suggest a possible solution and a simple workaround.
+
+## Possible solution:
+Although by default winapi functions work only with paths up to MAX_PATH, their unicode versions can work with much longer paths, provided that the paths are prefixed with "\\\\?\\". Functions defined in System.Win32.File module (e.g. moveFileEx) call the unicode versions. Solving the length limitation problem might not be as simple as prefixing all arguments with "\\\\?\\", as it does not work with relative paths. I also do not know the git-annex internals so I have no idea how easy would it be to implement, but maybe it could be an easier way than trying to limit the paths' lengths to fit in the archaic MAX_PATH limit. The MSDN page linked below has some more information.
+
+## Workaround:
+It turns out that Windows 10 supports long paths without the "\\\\?\\" prefix, but this setting is by default turned off. According to [this MSDN page](https://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85\).aspx#maxpath) one can enable it by setting HKLM\SYSTEM\CurrentControlSet\Control\FileSystem\LongPathsEnabled to 1 or by using the group policy editor (Computer Configuration > Administrative Templates > System > Filesystem > Enable NTFS long paths). With default settings I was unable to "git annex get" some files in nested directories (it failed with a MoveFileEx error when moving a file from annex\tmp to annex\objects), but after I enabled the long paths option it worked!
+
+This is more of a workaround than a real solution because it requires modifying a global setting which can affect other applications. I also do not know if it solves all path problems with git-annex, but it worked for me so far. I hope this workaround will help others having similar problems.

tuned up rushed report
diff --git a/doc/bugs/get_-J_cannot_be_used_with_password-based_authentication.mdwn b/doc/bugs/get_-J_cannot_be_used_with_password-based_authentication.mdwn
index 323afe2..852a604 100644
--- a/doc/bugs/get_-J_cannot_be_used_with_password-based_authentication.mdwn
+++ b/doc/bugs/get_-J_cannot_be_used_with_password-based_authentication.mdwn
@@ -1,11 +1,16 @@
 ### Please describe the problem.
 
+can't fetch in parallel from a host over ssh if authentication is password-based
 
 ### What steps will reproduce the problem?
 
+try to  get -J4  from a host which has ssh authentication password-only (no key)
+
 
 ### What version of git-annex are you using? On what operating system?
 
+6.20170101+gitg93d69b1-1~ndall+1
+with newer version (6.20170220+gitg75a15e1ad-1~ndall+1) looks slightly different but to the same "effect"
 
 ### Please provide any additional information below.
 
@@ -28,7 +33,7 @@ yohtest@rolando.cns's password: yohtest@rolando.cns's password: yohtest@rolando.
 
 """]]
 
-I have entered password just once -- didn't try to enter it multiple times into the void ;)  but I guess it would be neat if annex could handle this situation gracefully and demand password once
+I have entered password just once -- didn't try to enter it multiple times into the void ;)  but I guess it would be neat if annex could handle this situation gracefully (e.g. initiate central ssh controller first before spawning parallel getters) and demand password once
 
 
 [[!meta author=yoh]]

diff --git a/doc/bugs/get_-J_cannot_be_used_with_password-based_authentication.mdwn b/doc/bugs/get_-J_cannot_be_used_with_password-based_authentication.mdwn
new file mode 100644
index 0000000..323afe2
--- /dev/null
+++ b/doc/bugs/get_-J_cannot_be_used_with_password-based_authentication.mdwn
@@ -0,0 +1,34 @@
+### Please describe the problem.
+
+
+### What steps will reproduce the problem?
+
+
+### What version of git-annex are you using? On what operating system?
+
+
+### Please provide any additional information below.
+
+[[!format sh """
+$> git annex get -J4
+get sourcedata/sub-sid000004/ses-siemens0/anat/sub-sid000004_ses-siemens0_acq-MPRAGE_run-01_T1w.dicom.tgz get sourcedata/sub-sid000004/ses-siemens0/fmap/sub-sid000004_ses-siemens0_acq-3mm_run-01_phasediff.dicom.tgz get sourcedata/sub-sid000005/ses-siemens1/func/sub-sid000005_ses-siemens1_task-life_acq-2mm692_run-04_bold.dicom.tgz get sourcedata/sub-sid000005/ses-siemens1/func/sub-sid000005_ses-siemens1_task-life_acq-2mm748_run-03_bold.dicom.tgz (transfer already in progress, or unable to take transfer lock) 
+  Unable to access these remotes: origin
+(from origin...) (from origin...) 
+  Try making some of these repositories available:
+
+
+  	2e44be07-8f1a-4c11-a7cb-464802b87b26 -- mvdoc@smaug:/mnt/btrfs/dbic/inbox/dbic-ds-3mm/dbic/pulse_sequences
+   	b2ff2964-c31b-4784-b094-2bebb336da91 -- mvdoc@smaug:/mnt/btrfs/dbic/inbox/dbic-ds/dbic/pulse_sequences
+   	d486ea11-98dc-42d3-9640-e5713acfb675 -- yoh@rolando:/inbox/BIDS/dbic/1000-dbic-dataset [origin]
+failed
+get sourcedata/sub-sid000005/ses-siemens1/func/sub-sid000005_ses-siemens1_task-life_acq-2mm754_run-05_bold.dicom.tgz (from origin...) 
+(from origin...) 
+...
+yohtest@rolando.cns's password: yohtest@rolando.cns's password: yohtest@rolando.cns's password: yohtest@rolando.cns's password
+
+"""]]
+
+I have entered password just once -- didn't try to enter it multiple times into the void ;)  but I guess it would be neat if annex could handle this situation gracefully and demand password once
+
+
+[[!meta author=yoh]]

comment
diff --git a/doc/tips/recover_data_from_lost+found/comment_5_e887b2d2ecbce3de22c517afd500e783._comment b/doc/tips/recover_data_from_lost+found/comment_5_e887b2d2ecbce3de22c517afd500e783._comment
new file mode 100644
index 0000000..125b470
--- /dev/null
+++ b/doc/tips/recover_data_from_lost+found/comment_5_e887b2d2ecbce3de22c517afd500e783._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2017-03-14T23:40:45Z"
+ content="""
+If you're worried about lost+found containing non-annexed content, you can
+copy (`cp`) the files, rather than moving them (`mv`). After adding the
+files, `git annex unused` will find any non-annexed ones that were added,
+and they can then be removed.
+
+This tip was written before `git annex reinject --known` existed, but that
+is also a good way to do it.
+"""]]

Added a comment: Isn't this procedure assuming that lost+found contains only uncorrupted previously annexed files?
diff --git a/doc/tips/recover_data_from_lost+found/comment_4_960fcfe8c5c7bcb7350f61ecfb84f36c._comment b/doc/tips/recover_data_from_lost+found/comment_4_960fcfe8c5c7bcb7350f61ecfb84f36c._comment
new file mode 100644
index 0000000..3c2105e
--- /dev/null
+++ b/doc/tips/recover_data_from_lost+found/comment_4_960fcfe8c5c7bcb7350f61ecfb84f36c._comment
@@ -0,0 +1,27 @@
+[[!comment format=mdwn
+ username="https://launchpad.net/~stephane-gourichon-lpad"
+ nickname="stephane-gourichon-lpad"
+ avatar="http://cdn.libravatar.org/avatar/02d4a0af59175f9123720b4481d55a769ba954e20f6dd9b2792217d9fa0c6089"
+ subject="Isn't this procedure assuming that lost+found contains only uncorrupted previously annexed files?"
+ date="2017-03-14T19:15:40Z"
+ content="""
+    git annex add recovered-content
+
+lost+found does not contain only annexed file, right? It may contain any kind of file not originally annexed.
+
+Examples:
+
+* a file that was imported in the regular git part of the git annex repository
+* a corrupted variant of an annexed file
+* a git pack, a git index or any git administrative file
+* a file totally unrelated that happened to be on the same filesystem.
+
+In all these cases, this command will result in new additions to the annex.
+
+This is not what a recovery should do, is it?
+
+Shouldn't that become rather something like:
+
+    git annex reinject --known 
+
+"""]]

Added a comment
diff --git a/doc/forum/Debugging_of_transfer_considerations/comment_2_f7cd207b08fe365d0a6248316c91ed78._comment b/doc/forum/Debugging_of_transfer_considerations/comment_2_f7cd207b08fe365d0a6248316c91ed78._comment
new file mode 100644
index 0000000..d95274e
--- /dev/null
+++ b/doc/forum/Debugging_of_transfer_considerations/comment_2_f7cd207b08fe365d0a6248316c91ed78._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Horus"
+ avatar="http://cdn.libravatar.org/avatar/8f0ee08b98ea5bba76c3fe112c08851c"
+ subject="comment 2"
+ date="2017-03-14T08:58:54Z"
+ content="""
+Maybe it's the problem that the client group requires a file in archive/ to reach a archive repo, not a backup repo. To combine the behavior of both, I have set the group to archive and wanted to anything.
+"""]]

diff --git a/doc/forum/git_annex_uninit_creates_broken_symlinks.mdwn b/doc/forum/git_annex_uninit_creates_broken_symlinks.mdwn
new file mode 100644
index 0000000..5ba1365
--- /dev/null
+++ b/doc/forum/git_annex_uninit_creates_broken_symlinks.mdwn
@@ -0,0 +1,7 @@
+Hi, I'm attempting to uninit my giant git annex repo for my home folder. I've upgraded this to the latest repo version that uses smudge files instead of direct mode.
+
+However, when I try to uninit it, I end up with many broken symlinks, similar to that described [here](https://git-annex.branchable.com/forum/Broken_symlinks_remain_after_drop/).
+
+Any suggestions on how I can best restore these files to my home directory and migrate to using annex for an annex folder for stuff I need to transfer?
+
+Thanks!

close; not a bug in git-annex
diff --git a/doc/bugs/git_annex_testremote_fails_on_OSX_because_native___39__mktemp_-d__39___doesn__39__t_work.mdwn b/doc/bugs/git_annex_testremote_fails_on_OSX_because_native___39__mktemp_-d__39___doesn__39__t_work.mdwn
index 539cdc5..5a5bf61 100644
--- a/doc/bugs/git_annex_testremote_fails_on_OSX_because_native___39__mktemp_-d__39___doesn__39__t_work.mdwn
+++ b/doc/bugs/git_annex_testremote_fails_on_OSX_because_native___39__mktemp_-d__39___doesn__39__t_work.mdwn
@@ -85,3 +85,5 @@ FAIL
 ### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
 
 Just starting but have high hopes :-)
+
+> [[done]] per my comment --[[Joey]]
diff --git a/doc/bugs/git_annex_testremote_fails_on_OSX_because_native___39__mktemp_-d__39___doesn__39__t_work/comment_1_66f4f2e9e674b02b2a7dee77690d26fd._comment b/doc/bugs/git_annex_testremote_fails_on_OSX_because_native___39__mktemp_-d__39___doesn__39__t_work/comment_1_66f4f2e9e674b02b2a7dee77690d26fd._comment
new file mode 100644
index 0000000..67c339b
--- /dev/null
+++ b/doc/bugs/git_annex_testremote_fails_on_OSX_because_native___39__mktemp_-d__39___doesn__39__t_work/comment_1_66f4f2e9e674b02b2a7dee77690d26fd._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2017-03-13T20:29:21Z"
+ content="""
+git-annex does not contain any calls to the "mktemp" command.
+
+So, it must be your external special remote that uses that command.
+It's up to the authors of external special remotes to make them run
+portably on whatever OS's they want to support. Probably if you mention
+this to the author of whatever external special remote you're using (you
+neglected to say what one it is in your bug report!), they will easily be
+able to fix it.
+
+git-annex is not going to get in the business of bundling a bunch of stuff
+that it does not depend on, sorry.
+"""]]

Windows: Fix bug in shell script shebang lookup code that caused a "delayed read on closed handle" error.
The bug was that withFile closes the handle afterwards, but the content
of the file was not read due to laziness. Using readFile avoids it.
This commit was sponsored by Nick Daly on Patreon.
diff --git a/CHANGELOG b/CHANGELOG
index a8dd882..443adb6 100644
--- a/CHANGELOG
+++ b/CHANGELOG
@@ -15,6 +15,8 @@ git-annex (6.20170301.2) UNRELEASED; urgency=medium
     program, searching for the program in the PATH.
   * Drop support for building with old versions of dns, http-conduit,
     directory, feed, and http-types.
+  * Windows: Fix bug in shell script shebang lookup code that
+    caused a "delayed read on closed handle" error.
 
  -- Joey Hess <id@joeyh.name>  Thu, 02 Mar 2017 12:51:40 -0400
 
diff --git a/Utility/Shell.hs b/Utility/Shell.hs
index 116ab61..b8a9491 100644
--- a/Utility/Shell.hs
+++ b/Utility/Shell.hs
@@ -49,8 +49,7 @@ findShellCommand f = do
 #ifndef mingw32_HOST_OS
 	defcmd
 #else
-	l <- catchDefaultIO Nothing $ withFile f ReadMode $
-		headMaybe . lines <$$> hGetContents
+	l <- catchDefaultIO Nothing $ headMaybe . lines <$> readFile f
 	case l of
 		Just ('#':'!':rest) -> case words rest of
 			[] -> defcmd
diff --git a/doc/bugs/external_remote_hGetContents_handle_error.mdwn b/doc/bugs/external_remote_hGetContents_handle_error.mdwn
index 33914f9..a341478 100644
--- a/doc/bugs/external_remote_hGetContents_handle_error.mdwn
+++ b/doc/bugs/external_remote_hGetContents_handle_error.mdwn
@@ -40,3 +40,5 @@ Same as before, windows, git-bash
 ### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
 
 Thanks for the quick response earlier. I hope this is helpful information. Keep up the great work! :)
+
+> Reproduced this bug, and I've committed a fix. [[done]] --[[Joey]]

Added a comment: windows password
diff --git a/doc/forum/recover_deleted_files___63__/comment_6_b6614dddceba94c94179572a8f59ee80._comment b/doc/forum/recover_deleted_files___63__/comment_6_b6614dddceba94c94179572a8f59ee80._comment
new file mode 100644
index 0000000..0806fc4
--- /dev/null
+++ b/doc/forum/recover_deleted_files___63__/comment_6_b6614dddceba94c94179572a8f59ee80._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="hobbie123"
+ avatar="http://cdn.libravatar.org/avatar/757597b9cb81748641d047835128e96c"
+ subject="windows password "
+ date="2017-03-13T06:28:14Z"
+ content="""
+<a href=\"http://www.passwordmanagers.net/resources/Necessary-Softwares-for-Work-and-Life-6.html\">Password Manager</a>
+is a free manager for XP and windows password issues and it works as good as can be expected. In addition,the main thing is to stop using the external hard disk until you use this tool, and avoid writing any files to it.
+"""]]

initial post
diff --git a/doc/forum/Trouble_setting_up_public_repo_cloneable_from_a_web_site.mdwn b/doc/forum/Trouble_setting_up_public_repo_cloneable_from_a_web_site.mdwn
new file mode 100644
index 0000000..3c81f6e
--- /dev/null
+++ b/doc/forum/Trouble_setting_up_public_repo_cloneable_from_a_web_site.mdwn
@@ -0,0 +1,35 @@
+I'm trying to set up a public repository that is cloneable from my web site,
+similar to what is mentioned at
+https://git-annex.branchable.com/tips/setup_a_public_repository_on_a_web_site/
+
+I've got a repo from my laptop that I can push to my web server, and I can list
+the contents of the `.git` directory:
+
+    $ curl https://example.com/annex/.git/
+    <html>
+    <head><title>Index of /annex/.git/</title></head>
+    <body bgcolor="white">
+    <h1>Index of /annex/.git/</h1><hr><pre><a href="../">../</a>
+    <a href="annex/">annex/</a>                 12-Mar-2017 17:42                   -
+    <a href="branches/">branches/</a>           12-Mar-2017 17:38                   -
+    <a href="hooks/">hooks/</a>                 12-Mar-2017 17:38                   -
+    <a href="info/">info/</a>                   12-Mar-2017 17:38                   -
+    <a href="logs/">logs/</a>                   12-Mar-2017 17:38                   -
+    <a href="objects/">objects/</a>             12-Mar-2017 17:40                   -
+    <a href="refs/">refs/</a>                   12-Mar-2017 17:38                   -
+    <a href="HEAD">HEAD</a>                     12-Mar-2017 17:39                  23
+    <a href="config">config</a>                 12-Mar-2017 17:40                 269
+    <a href="description">description</a>       12-Mar-2017 17:38                  73
+    <a href="index">index</a>                   12-Mar-2017 17:41                1200
+    </pre><hr></body>
+    </html>
+
+However, when I try to clone it to simulate what I expect people to do, I get:
+
+    $ git clone https://exmaple.com/annex/.git
+    Cloning into 'annex...
+    fatal: repository 'https://example.com/annex/.git/' not found
+
+I've configured with `git config core.sharedrepository world` and `git config
+receive.denyCurrentBranch updateInstead`, but it doesn't seem to be working as I
+can't clone the repository over https.

Added a comment: Solution
diff --git a/doc/bugs/Empty_files_make_git_status_slow/comment_3_17b400bc03eb176f63009b9e01a862f4._comment b/doc/bugs/Empty_files_make_git_status_slow/comment_3_17b400bc03eb176f63009b9e01a862f4._comment
new file mode 100644
index 0000000..892eb6b
--- /dev/null
+++ b/doc/bugs/Empty_files_make_git_status_slow/comment_3_17b400bc03eb176f63009b9e01a862f4._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="Michel"
+ avatar="http://cdn.libravatar.org/avatar/cf9fdab9aa34af56f769bf584c8e7011"
+ subject="Solution"
+ date="2017-03-11T00:44:18Z"
+ content="""
+I found a relatively simple solution by setting the following in .gitattributes:
+
+```
+* annex.largefiles=(largerthan=0kb)
+```
+
+"""]]

Added a comment
diff --git a/doc/forum/Blacklisting_files___40__so_that_they_get_removed_any_time_a_copy_is_found__41__/comment_4_d95647d91a33d1164a87344939cb769a._comment b/doc/forum/Blacklisting_files___40__so_that_they_get_removed_any_time_a_copy_is_found__41__/comment_4_d95647d91a33d1164a87344939cb769a._comment
new file mode 100644
index 0000000..64282fb
--- /dev/null
+++ b/doc/forum/Blacklisting_files___40__so_that_they_get_removed_any_time_a_copy_is_found__41__/comment_4_d95647d91a33d1164a87344939cb769a._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="CandyAngel"
+ avatar="http://cdn.libravatar.org/avatar/15c0aade8bec5bf004f939dd73cf9ed8"
+ subject="comment 4"
+ date="2017-03-10T08:11:13Z"
+ content="""
+I use git-annex-metadata to tag files I don't want, then drop the content with that tag[1]. Then it doesn't matter if the content reappears, it'll get pruned at some point. Also easy to find any symlinks pointing at the unwanted content using git-annex-find :)
+
+[1] I actually move it to another remote on a 3TB drive which only has such unwanted content, and then delete it on there when I need more space on it. Doesn't matter if that drive fails, but allows a bit of a window for an \"actually, I do need that\" recovery.
+"""]]

Added a comment: Issue still present
diff --git a/doc/bugs/cannot_add_a_files_with_an_accent_in_it/comment_3_7c34ada3c7b413f2b622149b60757f6e._comment b/doc/bugs/cannot_add_a_files_with_an_accent_in_it/comment_3_7c34ada3c7b413f2b622149b60757f6e._comment
new file mode 100644
index 0000000..a30e225
--- /dev/null
+++ b/doc/bugs/cannot_add_a_files_with_an_accent_in_it/comment_3_7c34ada3c7b413f2b622149b60757f6e._comment
@@ -0,0 +1,37 @@
+[[!comment format=mdwn
+ username="Alan"
+ avatar="http://cdn.libravatar.org/avatar/9cbc26346f1c693d7df198e662a5fdae"
+ subject="Issue still present"
+ date="2017-03-10T07:32:16Z"
+ content="""
+I'm still having this issue, now with a folder. I added several files:
+
+    % git annex add Théâtre\ Augustin\ 2016/*                                           
+    add Théâtre Augustin 2016/Juin 2016 - Les Ptits du Madrigal - Bizarre, Bizarre.webm ok
+    add Théâtre Augustin 2016/Juin 2016 - Les Ptits du Madrigal - Conte A Rebours.webm ok
+    add Théâtre Augustin 2016/Juin 2016 - Les Ptits du Madrigal - Coup De Theatre.webm ok
+    add Théâtre Augustin 2016/Juin 2016 - Les Ptits du Madrigal - Inspecteur Toutou.webm ok
+    add Théâtre Augustin 2016/Juin 2016 - Les Ptits du Madrigal - La Princesse Qui Disait Toujours Non.webm ok
+    add Théâtre Augustin 2016/Juin 2016 - Les Ptits du Madrigal - Le Magicien Qui Aimait Les Bonbons.webm ok
+    (recording state in git...)
+
+and they show as both added and untracked
+
+    % git annex status                                                                 
+    A Théâtre Augustin 2016/Juin 2016 - Les Ptits du Madrigal - Bizarre, Bizarre.webm
+    A Théâtre Augustin 2016/Juin 2016 - Les Ptits du Madrigal - Conte A Rebours.webm
+    A Théâtre Augustin 2016/Juin 2016 - Les Ptits du Madrigal - Coup De Theatre.webm
+    A Théâtre Augustin 2016/Juin 2016 - Les Ptits du Madrigal - Inspecteur Toutou.webm
+    A Théâtre Augustin 2016/Juin 2016 - Les Ptits du Madrigal - La Princesse Qui Disait Toujours Non.webm
+    A Théâtre Augustin 2016/Juin 2016 - Les Ptits du Madrigal - Le Magicien Qui Aimait Les Bonbons.webm
+    ? Théâtre Augustin 2016/Juin 2016 - Les Ptits du Madrigal - Bizarre, Bizarre.webm
+    ? Théâtre Augustin 2016/Juin 2016 - Les Ptits du Madrigal - Conte A Rebours.webm
+    ? Théâtre Augustin 2016/Juin 2016 - Les Ptits du Madrigal - Coup De Theatre.webm
+    ? Théâtre Augustin 2016/Juin 2016 - Les Ptits du Madrigal - Inspecteur Toutou.webm
+    ? Théâtre Augustin 2016/Juin 2016 - Les Ptits du Madrigal - La Princesse Qui Disait Toujours Non.webm
+    ? Théâtre Augustin 2016/Juin 2016 - Les Ptits du Madrigal - Le Magicien Qui Aimait Les Bonbons.webm
+
+It seems to be related to this: https://stackoverflow.com/questions/11968183/how-to-handle-accented-characters-in-file-names-in-git-on-mac-os-x-converted-to
+
+I “solved“ the issue by doing a git add of the repository, but I'm wondering what options I need to use with git to avoid such issues in the future.
+"""]]

diff --git a/doc/bugs/git_annex_testremote_fails_on_OSX_because_native___39__mktemp_-d__39___doesn__39__t_work.mdwn b/doc/bugs/git_annex_testremote_fails_on_OSX_because_native___39__mktemp_-d__39___doesn__39__t_work.mdwn
new file mode 100644
index 0000000..539cdc5
--- /dev/null
+++ b/doc/bugs/git_annex_testremote_fails_on_OSX_because_native___39__mktemp_-d__39___doesn__39__t_work.mdwn
@@ -0,0 +1,87 @@
+### Please describe the problem.
+
+Created a special remote using one drive.
+ran git annex testremote <that remote>
+got errors, apparently starting with:
+
+    retrieveKeyFile:                 usage: mktemp [-d] [-q] [-t prefix] [-u] template ...
+    mktemp [-d] [-q] [-u] -t prefix 
+    FAIL (0.01s
+
+### What steps will reproduce the problem?
+
+As above.
+
+### What version of git-annex are you using? On what operating system?
+OSX 10.10.5 https://downloads.kitenet.net/git-annex/OSX/current/10.10_Yosemite/git-annex.dmg 
+
+### Please provide any additional information below.
+
+Verified that using gnu coreutils mktemp fixes the problem.
+Suggestion: Bundle that with the distribution.
+Along those lines, consider also including rclone and the script git-annex-remote-rclone,
+
+[[!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
+testremote alanr-onedrive (generating test keys...) Remote Tests
+  unavailable remote
+    removeKey:                         Cannot run git-annex-remote-!dne! -- Make sure it's in your PATH and is executable.
+OK
+    storeKey:                          Cannot run git-annex-remote-!dne! -- Make sure it's in your PATH and is executable.
+OK (0.43s)
+    checkPresent:                    OK
+    retrieveKeyFile:                 OK
+    retrieveKeyFileCheap:            OK
+  key size Just 1048576; NoChunks; encryption none
+    removeKey when not present:      2017/03/09 21:48:42 Waiting for deletions to finish 2017/03/09 21:48:42 directory not found
+OK (3.80s)
+    present False:                   2017/03/09 21:48:44 directory not found
+OK (1.89s)
+    storeKey:                        2017/03/09 21:48:46 One drive root 'git-annex-test/70c/e24': Waiting for checks to finish
+2017/03/09 21:48:46 One drive root 'git-annex-test/70c/e24': Waiting for transfers to finish
+2017/03/09 21:48:49 
+Transferred:     1 MBytes (206.541 kBytes/s)
+Errors:                 0
+Checks:                 0
+Transferred:            1
+Elapsed time:        4.9s
+OK (4.97s)
+    present True:                    Total objects: 1 Total size: 1 MBytes (1048576 Bytes)
+OK (2.40s)
+    storeKey when already present:   2017/03/09 21:48:53 One drive root 'git-annex-test/70c/e24': Waiting for checks to finish
+2017/03/09 21:48:53 One drive root 'git-annex-test/70c/e24': Waiting for transfers to finish
+2017/03/09 21:48:53 
+Transferred:      0 Bytes (0 Bytes/s)
+Errors:                 0
+Checks:                 1
+Transferred:            0
+Elapsed time:        1.1s
+OK (1.12s)
+    present True:                    Total objects: 1 Total size: 1 MBytes (1048576 Bytes)
+OK (2.06s)
+    retrieveKeyFile:                 mktemp -d
+usage: mktemp [-d] [-q] [-t prefix] [-u] template ...
+       mktemp [-d] [-q] [-u] -t prefix 
+FAIL (0.01s)
+      failed
+    fsck downloaded object:          OK
+    retrieveKeyFile resume from 33%: FAIL
+      Exception: .git/annex/objects/Kv/9j/SHA256E-s1048576--22c73497372ed998c1e84743a67601e2c9522dc9ce78f180f90a3896313c0f61.this-is-a-test-key/SHA256E-s1048576--22c73497372ed998c1e84743a67601e2c9522dc9ce78f180f90a3896313c0f61.this-is-a-test-key: openBinaryFile: does not exist (No such file or directory)
+    fsck downloaded object:          OK
+    retrieveKeyFile resume from 0:   FAIL
+      Exception: failed to lock content: .git/annex/objects/Kv/9j/SHA256E-s1048576--22c73497372ed998c1e84743a67601e2c9522dc9ce78f180f90a3896313c0f61.this-is-a-test-key/SHA256E-s1048576--22c73497372ed998c1e84743a67601e2c9522dc9ce78f180f90a3896313c0f61.this-is-a-test-key: getFileStatus: does not exist (No such file or directory)
+    fsck downloaded object:          OK
+    retrieveKeyFile resume from end: cp: .git/annex/objects/Kv/9j/SHA256E-s1048576--22c73497372ed998c1e84743a67601e2c9522dc9ce78f180f90a3896313c0f61.this-is-a-test-key/SHA256E-s1048576--22c73497372ed998c1e84743a67601e2c9522dc9ce78f180f90a3896313c0f61.this-is-a-test-key: No such file or directory
+FAIL
+      Exception: failed to lock content: .git/annex/objects/Kv/9j/SHA256E-s1048576--22c73497372ed998c1e84743a67601e2c9522dc9ce78f180f90a3896313c0f61.this-is-a-test-key/SHA256E-s1048576--22c73497372ed998c1e84743a67601e2c9522dc9ce78f180f90a3896313c0f61.this-is-a-test-key: getFileStatus: does not exist (No such file or directory)
+    fsck downloaded object:          OK
+    removeKey when present:          OK (2.78s)
+    present False:                   ^C
+
+# End of transcript or log.
+"""]]
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+Just starting but have high hopes :-)

Added a comment: Work-in-progress, yet already usable, solution
diff --git a/doc/forum/Blacklisting_files___40__so_that_they_get_removed_any_time_a_copy_is_found__41__/comment_3_a2cac051ef2d36e1ffb550c4a788c111._comment b/doc/forum/Blacklisting_files___40__so_that_they_get_removed_any_time_a_copy_is_found__41__/comment_3_a2cac051ef2d36e1ffb550c4a788c111._comment
new file mode 100644
index 0000000..c540d55
--- /dev/null
+++ b/doc/forum/Blacklisting_files___40__so_that_they_get_removed_any_time_a_copy_is_found__41__/comment_3_a2cac051ef2d36e1ffb550c4a788c111._comment
@@ -0,0 +1,101 @@
+[[!comment format=mdwn
+ username="https://launchpad.net/~stephane-gourichon-lpad"
+ nickname="stephane-gourichon-lpad"
+ avatar="http://cdn.libravatar.org/avatar/02d4a0af59175f9123720b4481d55a769ba954e20f6dd9b2792217d9fa0c6089"
+ subject="Work-in-progress, yet already usable, solution"
+ date="2017-03-09T12:19:49Z"
+ content="""
+TL;DR:  Thanks for clarifying the possibilities.  I chose to maintain an explicit blacklist of files that are definitely uninteresting, because it is safer and more convenient at several level (protect against mistakes, makes reviewing easier, fewer assumptions).  I share the proof-of-concept here in case anyone is interested in the future.  I might share some scripts on a public repo, especially if anyone shows interest.
+
+## Discussion
+
+> You don't need to filter old commits out of branches to use git annex unused; it only looks at the most recent commit in each branch, so once a file has been deleted from all branches it will be identified as unused.
+
+Okay, this is important to know (perhaps something to add to the documentation there).
+
+> (...) depends on how quickly you need to get rid of the files, and whether you want git-annex to generally keep the content of deleted and old versions of modified files or not.
+>
+> If you only want git-annex to keep the content of files that are present in the current branches and tags (...)
+
+In a perfect world, that would be enough.
+
+> If you want to keep the full history in general, but drop the content of specific files, (...)
+
+I realize that I need to keep the full history in general, because (it already happened) although I almost always make small independent commits and review changes before commit, large changes are relatively common.   For example renaming a directory that has many sub-directories full of files.  If some files are removed by mistake since the last commit, the information is drowned in a big change.  As git does not always track renames, it sometimes shows many additions/removal.  Also, changes are sometimes committed by a `git annex sync` (which I avoid for this reason).
+
+So, a file reported by `git unused` is not a proof that it should be deleted.
+
+So all in all, yes I \"want to keep the full history in general, but drop the content of specific files\".
+
+> then you need to use git-annex to drop the content before you delete the file.
+
+Okay, this works locally.  Yet I have started to work another way, see below.
+
+> You can use git annex whereis $file to see everywhere that the content has gotten to, and then git annex drop $file --from each location (and from the local repository).
+>
+> If you need to immediately get rid of the content of some file, you can use the same procedure to check where it is and drop it from those locations.
+
+This somehow assumes connectivity to other repositories at cleanup time, which is not practical.
+
+I might make a number of commits including some that locally prune hundreds of files, several times, before having access to any other repository.
+
+This does not leave a clear state of \"globally blacklisted\" file.
+
+
+
+**It seems to me that the situation needs maintain some state allowing to defer the removal to the time when repositories are available.**
+
+
+## Work-in-progress solution
+
+This evolved to working another way:
+
+* maintain (grow) a list of blacklisted keys that's stored somewhere in the repository and synced like any other (regular git) file.
+* have some script that can be run at any time from any repo and locally delete any file that's blacklisted.
+* variant: before locally dropping the file, check if, as far as this repo knows, it's really unused anywhere.
+
+### Proof-of-concept implementation
+
+#### Script `git_annex_drop_all_files_in_blacklist.sh`
+
+Good for a small blacklist when `git annex unused` is slow.
+
+    #!/bin/bash
+
+    set -eu # Safety, abort on error.
+
+    while read KEY REASON
+    do
+            echo Will drop blacklisted \"$KEY\"
+            git annex dropkey --force \"$KEY\"
+    done <blacklist
+
+
+#### Script to show all unused files
+
+This presents all unused files in a directory.
+They can be presented ordered by date or EXIF date for review.
+
+    #!/bin/bash
+
+    mkdir -p review_unused ; cd review_unused ; time git annex unused | while read NUMBER KEY ; do ln -s $( git annex contentlocation $KEY ) $KEY ; done ; xdg-open . &
+
+Files can then be interactively moved to other directories for further processing: reuse with `git add`, blacklist, etc.
+
+#### Other
+
+I have also written another experimental script that processes the output of `git annex unused`, automatically blacklists them in some specific cases and assists in reviewing or `git annex drop`ing them.
+
+## Additional benefit
+
+Storing state in a blacklist has the advantage of being very explicit and global.
+
+This has the advantage that the blacklist can potentially apply to content outside of any repository.
+For example, I find one of my memory cards for digital camera, that I've not used for a long time.  It has old copies of some photos.  The blacklist allows to delete immediately uninteresting files, then git-annex can tell if the remaining files are known and can be also deleted.  Then, either the card becomes empty, or only the (fewer) remaining files can be manually reviewed.  Quick and safe.
+
+<!--  LocalWords:  whereis dropkey EXIF mkdir ln contentlocation xdg
+ -->
+<!--  LocalWords:  ing
+ -->
+
+"""]]

diff --git a/doc/bugs/external_remote_hGetContents_handle_error.mdwn b/doc/bugs/external_remote_hGetContents_handle_error.mdwn
new file mode 100644
index 0000000..33914f9
--- /dev/null
+++ b/doc/bugs/external_remote_hGetContents_handle_error.mdwn
@@ -0,0 +1,42 @@
+### Please describe the problem.
+
+A follow on from https://git-annex.branchable.com/bugs/Failing_to_execute_bash_remotes_windows/
+
+After noticing your note about it still being possible to run external scripts locally (don't know why I didn't try this!), I tried it. I guess this is related to the reading of the shebang?
+This may be fixed already, so I'm sorry if I'm rehashing things!
+
+
+### What steps will reproduce the problem?
+
+[[!format sh """
+$ git init
+$ git annex init
+$ cp `which git-annex-remote-rclone` .
+$ git annex initremote test type=external externaltype=rclone encryption=none
+
+initremote test
+git-annex: git-annex-remote-rclone: hGetContents: illegal operation (delayed read on closed handle)
+failed
+git-annex: initremote: 1 failed
+"""]]
+
+
+
+### What version of git-annex are you using? On what operating system?
+
+Same as before, windows, git-bash
+
+    git-annex version: 6.20170214-g2233a50
+    build flags: Assistant Webapp Pairing Testsuite S3(multipartupload)(storageclasses) WebDAV ConcurrentOutput TorrentParser 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 p2p S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external
+    local repository version: 5
+    supported repository versions: 3 5 6
+    upgrade supported from repository versions: 2 3 4 5
+    operating system: mingw32 i386
+
+
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+Thanks for the quick response earlier. I hope this is helpful information. Keep up the great work! :)

Added a comment: Thanks
diff --git a/doc/bugs/Empty_files_make_git_status_slow/comment_2_39876be38934e9056e9aa2a9fcdeaedf._comment b/doc/bugs/Empty_files_make_git_status_slow/comment_2_39876be38934e9056e9aa2a9fcdeaedf._comment
new file mode 100644
index 0000000..777f26a
--- /dev/null
+++ b/doc/bugs/Empty_files_make_git_status_slow/comment_2_39876be38934e9056e9aa2a9fcdeaedf._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Michel"
+ avatar="http://cdn.libravatar.org/avatar/cf9fdab9aa34af56f769bf584c8e7011"
+ subject="Thanks"
+ date="2017-03-09T07:34:25Z"
+ content="""
+Thanks for the looking into it. I guess it will have to be sorted out at the git end then or I will need to fill my empty files with a single character. I must say I love the v6 repo tho and hope it will become the default soon.
+"""]]

Added a comment
diff --git a/doc/forum/make___34__git_annex_fsck__34___only_display__44___not_move/comment_3_369daddf95ab43f2c3d6b81c35810c19._comment b/doc/forum/make___34__git_annex_fsck__34___only_display__44___not_move/comment_3_369daddf95ab43f2c3d6b81c35810c19._comment
new file mode 100644
index 0000000..6ee28f5
--- /dev/null
+++ b/doc/forum/make___34__git_annex_fsck__34___only_display__44___not_move/comment_3_369daddf95ab43f2c3d6b81c35810c19._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="archimedes"
+ avatar="http://cdn.libravatar.org/avatar/5b2ed40aabedcb1b8c2c0ce69f55a1e1"
+ subject="comment 3"
+ date="2017-03-08T22:36:14Z"
+ content="""
+Apologies for editing, forgot it was markdown.
+"""]]

Added a comment
diff --git a/doc/forum/make___34__git_annex_fsck__34___only_display__44___not_move/comment_2_fdfd1d1ded3fb98a83f2593605250a87._comment b/doc/forum/make___34__git_annex_fsck__34___only_display__44___not_move/comment_2_fdfd1d1ded3fb98a83f2593605250a87._comment
new file mode 100644
index 0000000..d920d06
--- /dev/null
+++ b/doc/forum/make___34__git_annex_fsck__34___only_display__44___not_move/comment_2_fdfd1d1ded3fb98a83f2593605250a87._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="archimedes"
+ avatar="http://cdn.libravatar.org/avatar/5b2ed40aabedcb1b8c2c0ce69f55a1e1"
+ subject="comment 2"
+ date="2017-03-08T22:34:59Z"
+ content="""
+Do you mean \"made\"==\"updated\" or made==\"already exists\"?
+
+Maybe I have an old version (installed via brew)...
+
+I get: 
+
+~/s/a/annex8 git:master ❯❯❯ git annex fsck -q
+  Bad file size (1 B smaller); moved to .git/annex/bad/<long_hash>
+git-annex: fsck: 1 failed
+
+unless there are no other copies, in which case the original filename it is printed on a new line with the \"No known copies\" warning. 
+
+My use-case is for images - a small amount of corruption to some old images might not be visually perceptible, and hence tolerable, especially if I'm short-sighted enough to only have 1 copy. 
+I mean its possible for the user to navigate to /bad, visually inspect that they're ok with a corrupted image, parse the git log --stat message and restore it. 
+But it seems beneficial to have something like a rsync-like \"--dryrun\" option for fsck.
+"""]]

Added a comment: re: comment 3
diff --git a/doc/bugs/Failing_to_execute_bash_remotes_windows/comment_4_d05069125823e7602a3441306e12db48._comment b/doc/bugs/Failing_to_execute_bash_remotes_windows/comment_4_d05069125823e7602a3441306e12db48._comment
new file mode 100644
index 0000000..38b449f
--- /dev/null
+++ b/doc/bugs/Failing_to_execute_bash_remotes_windows/comment_4_d05069125823e7602a3441306e12db48._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="jason.dixon.email@aa0e536a2ec2877d6f666108dbbc6e39bbe87ac0"
+ nickname="jason.dixon.email"
+ avatar="http://cdn.libravatar.org/avatar/fbe9050fc83bbd536d307d87ea14d4bc"
+ subject="re: comment 3"
+ date="2017-03-08T21:58:14Z"
+ content="""
+Awesome, thanks Joey. Yeah that sounds plausible. I'll check it out whenever the next version comes by. Thanks. Keep up the amazing work! :)
+"""]]

Windows: Improve handling of shebang in external special remote program, searching for the program in the PATH.
findShellCommand needs a full path to a file in order to check it for a
shebang on Windows. It was being run with only the base name of the external
special remote program, which would only work when it was in the current
directory.
This is why users in
https://github.com/DanielDent/git-annex-remote-rclone/pull/10 and elsewhere
were complaining that the previous improvements to git-annex didn't make
git-remote-rclone work on Windows.
Also, reworked checkearlytermination, which while it worked, seemed
to rely on a race condition. And, improved its error messages.
This commit was sponsored by Shane-o on Patreon.
diff --git a/CHANGELOG b/CHANGELOG
index b5f2021..580faff 100644
--- a/CHANGELOG
+++ b/CHANGELOG
@@ -11,6 +11,8 @@ git-annex (6.20170301.2) UNRELEASED; urgency=medium
     jobs than remotes.
   * fsck -q: When a file has bad content, include the name of the file
     in the warning message.
+  * Windows: Improve handling of shebang in external special remote
+    program, searching for the program in the PATH.
 
  -- Joey Hess <id@joeyh.name>  Thu, 02 Mar 2017 12:51:40 -0400
 
diff --git a/Remote/External.hs b/Remote/External.hs
index b66e102..0ac381b 100644
--- a/Remote/External.hs
+++ b/Remote/External.hs
@@ -375,7 +375,8 @@ startExternal external = do
 	return st
   where
 	start errrelayer g = liftIO $ do
-		(cmd, ps) <- findShellCommand basecmd
+		cmdpath <- searchPath basecmd
+		(cmd, ps) <- maybe (pure (basecmd, [])) findShellCommand cmdpath
 		let basep = (proc cmd (toCommand ps))
 			{ std_in = CreatePipe
 			, std_out = CreatePipe
@@ -383,9 +384,8 @@ startExternal external = do
 			}
 		p <- propgit g basep
 		(Just hin, Just hout, Just herr, ph) <- 
-			createProcess p `catchIO` runerr
+			createProcess p `catchIO` runerr cmdpath
 		stderrelay <- async $ errrelayer herr
-		checkearlytermination =<< getProcessExitCode ph
 		cv <- newTVarIO $ externalDefaultConfig external
 		pv <- newTVarIO Unprepared
 		pid <- atomically $ do
@@ -409,15 +409,11 @@ startExternal external = do
 		environ <- propGitEnv g
 		return $ p { env = Just environ }
 
-	runerr _ = giveup ("Cannot run " ++ basecmd ++ " -- Make sure it's in your PATH and is executable.")
-
-	checkearlytermination Nothing = noop
-	checkearlytermination (Just exitcode) = ifM (inPath basecmd)
-		( giveup $ unwords [ "failed to run", basecmd, "(" ++ show exitcode ++ ")" ]
-		, do
-			path <- intercalate ":" <$> getSearchPath
-			giveup $ basecmd ++ " is not installed in PATH (" ++ path ++ ")"
-		)
+	runerr (Just cmd) _ =
+		giveup $ "Cannot run " ++ cmd ++ " -- Make sure it's executable and that its dependencies are installed."
+	runerr Nothing _ = do
+		path <- intercalate ":" <$> getSearchPath
+		giveup $ "Cannot run " ++ basecmd ++ " -- It is not installed in PATH (" ++ path ++ ")"
 
 stopExternal :: External -> Annex ()
 stopExternal external = liftIO $ do
diff --git a/Utility/Path.hs b/Utility/Path.hs
index 3ee5ff3..cd9dc38 100644
--- a/Utility/Path.hs
+++ b/Utility/Path.hs
@@ -227,6 +227,8 @@ inPath command = isJust <$> searchPath command
  -
  - The command may be fully qualified already, in which case it will
  - be returned if it exists.
+ -
+ - Note that this will find commands in PATH that are not executable.
  -}
 searchPath :: String -> IO (Maybe FilePath)
 searchPath command
diff --git a/doc/bugs/Failing_to_execute_bash_remotes_windows.mdwn b/doc/bugs/Failing_to_execute_bash_remotes_windows.mdwn
index 6e24147..15ecbf4 100644
--- a/doc/bugs/Failing_to_execute_bash_remotes_windows.mdwn
+++ b/doc/bugs/Failing_to_execute_bash_remotes_windows.mdwn
@@ -54,3 +54,5 @@ VERSION 1
 ### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
 
 Oh yeah! This software is awesome. After getting used to having "dummy" shortcuts to content I don't currently have, with the simple ability to get/drop that content, I can't believe I haven't seen this anywhere before. If there is anything more impressive than this software, it's the support it has had from Joey over all this time. I'd have pulled my hair out long ago. :P
+
+> [[fixed|done]] although untested --[[Joey]]
diff --git a/doc/bugs/Failing_to_execute_bash_remotes_windows/comment_3_691fe409f869c46e3716924e958f431a._comment b/doc/bugs/Failing_to_execute_bash_remotes_windows/comment_3_691fe409f869c46e3716924e958f431a._comment
new file mode 100644
index 0000000..0d27c86
--- /dev/null
+++ b/doc/bugs/Failing_to_execute_bash_remotes_windows/comment_3_691fe409f869c46e3716924e958f431a._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2017-03-08T19:36:57Z"
+ content="""
+Looking into it a bit more, the problem seems to be that findShellCommand 
+expects a path to a file to examine, but when it's used for an external
+special remote, it's only given the name of the command.
+
+So, I fixed it by searching for the command in the PATH.
+
+I have still not tested if this works on Windows, but probably, I think.
+As long as PATH is set on Windows at least.
+"""]]

comment
diff --git a/doc/bugs/Failing_to_execute_bash_remotes_windows/comment_2_7b8d82a32d6b82f1d50a54455aa4f643._comment b/doc/bugs/Failing_to_execute_bash_remotes_windows/comment_2_7b8d82a32d6b82f1d50a54455aa4f643._comment
new file mode 100644
index 0000000..1ebf64a
--- /dev/null
+++ b/doc/bugs/Failing_to_execute_bash_remotes_windows/comment_2_7b8d82a32d6b82f1d50a54455aa4f643._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2017-03-08T19:20:21Z"
+ content="""
+git-annex on Windows already checks if external special remotes start
+with #! and tries to handle the shebang, since Windows does not do that
+natively. That was added in version 6.20160907.
+([[todo/refactor_shebang_handling_code_for_wider_use]])
+
+`git-annex proxy` does not do that, and I feel it's out of scope for it to
+do so. So the proxy stuff you tried is a red herring.
+
+It might be useful to use --debug to see what command git-annex tries to
+execute when running the external special remote program.
+"""]]

comment
diff --git a/doc/forum/make___34__git_annex_fsck__34___only_display__44___not_move/comment_1_018cb2fd618a448088d9e91e4872333d._comment b/doc/forum/make___34__git_annex_fsck__34___only_display__44___not_move/comment_1_018cb2fd618a448088d9e91e4872333d._comment
new file mode 100644
index 0000000..7220c49
--- /dev/null
+++ b/doc/forum/make___34__git_annex_fsck__34___only_display__44___not_move/comment_1_018cb2fd618a448088d9e91e4872333d._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2017-03-08T18:58:19Z"
+ content="""
+I've made fsck -q include the name of the file in that warning message.
+
+Note that, given any file in `.git/annex/bad`, you can find the files
+in the git repository that linked to it, by running 
+`git log --stat -S$filename`
+"""]]

document get -J's behavior of spreading load amoung same-cost remotes
I implemented this last fall, but forgot to document it anywhere.
diff --git a/doc/git-annex-get.mdwn b/doc/git-annex-get.mdwn
index f30ee49..b7f2f74 100644
--- a/doc/git-annex-get.mdwn
+++ b/doc/git-annex-get.mdwn
@@ -23,7 +23,7 @@ or transferring them from some kind of key-value store.
 * `--from=remote`
 
   Normally git-annex will choose which remotes to get the content
-  from, preferring less expensive remotes. Use this option to specify
+  from, preferring remotes with lower costs. Use this option to specify
   which remote to use. 
   
   Any files that are not available on the remote will be silently skipped.
@@ -33,6 +33,13 @@ or transferring them from some kind of key-value store.
   Enables parallel download with up to the specified number of jobs
   running at once. For example: `-J10`
 
+  When files can be downloaded from multiple remotes, enabling parallel
+  downloads will split the load between the remotes. For example, if
+  the files are available on remotes A and B, then one file will be
+  downloaded from A, and another file will be downloaded from B in
+  parallel. (Remotes with lower costs are still preferred over higher cost
+  remotes.)
+
 * file matching options
  
   The [[git-annex-matching-options]](1)

Added a comment: Perhaps relevant
diff --git a/doc/bugs/Failing_to_execute_bash_remotes_windows/comment_1_f3d4899a90757132c79659b2c85f3e48._comment b/doc/bugs/Failing_to_execute_bash_remotes_windows/comment_1_f3d4899a90757132c79659b2c85f3e48._comment
new file mode 100644
index 0000000..7b231b8
--- /dev/null
+++ b/doc/bugs/Failing_to_execute_bash_remotes_windows/comment_1_f3d4899a90757132c79659b2c85f3e48._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="jason.dixon.email@aa0e536a2ec2877d6f666108dbbc6e39bbe87ac0"
+ nickname="jason.dixon.email"
+ avatar="http://cdn.libravatar.org/avatar/fbe9050fc83bbd536d307d87ea14d4bc"
+ subject="Perhaps relevant"
+ date="2017-03-08T17:31:30Z"
+ content="""
+Not sure if this is helpful or relevant, but it may be?
+
+https://github.com/jgm/pandoc/issues/3247#issuecomment-262036875
+"""]]

diff --git a/doc/forum/make___34__git_annex_fsck__34___only_display__44___not_move.mdwn b/doc/forum/make___34__git_annex_fsck__34___only_display__44___not_move.mdwn
new file mode 100644
index 0000000..a8e78b7
--- /dev/null
+++ b/doc/forum/make___34__git_annex_fsck__34___only_display__44___not_move.mdwn
@@ -0,0 +1,3 @@
+Is there a way to make fsck only display corrupted files instead of move them to the internal /bad folder? 
+
+Especially since the -q option (to only print corrupted files) doesn't even print the filename, only that *a* file has been moved...it seems a bit aggressive to compulsorily move a file to some obfuscated name AND not indicate its original location anywhere...

diff --git a/doc/bugs/Failing_to_execute_bash_remotes_windows.mdwn b/doc/bugs/Failing_to_execute_bash_remotes_windows.mdwn
new file mode 100644
index 0000000..6e24147
--- /dev/null
+++ b/doc/bugs/Failing_to_execute_bash_remotes_windows.mdwn
@@ -0,0 +1,56 @@
+### Please describe the problem.
+
+Trying to execute an external remote shell script on windows fails. 
+
+
+### What steps will reproduce the problem?
+
+    $git annex initremote test type=external externaltype=rclone encryption=none
+    initremote test git-annex: Cannot run git-annex-remote-rclone -- Make sure it's in your PATH and is executable.
+
+
+### What version of git-annex are you using? On what operating system?
+
+windows, using git-bash
+
+    git-annex version: 6.20170214-g2233a50
+    build flags: Assistant Webapp Pairing Testsuite S3(multipartupload)(storageclasses) WebDAV ConcurrentOutput TorrentParser 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 p2p S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external
+    local repository version: 5
+    supported repository versions: 3 5 6
+    upgrade supported from repository versions: 2 3 4 5
+    operating system: mingw32 i386
+
+
+
+### Please provide any additional information below.
+
+I've also tried fooling around with the proxy, which may help with pinpointing the issue?
+
+[[!format sh """
+$ git-annex-remote-rclone
+VERSION 1
+
+$ git annex proxy -- git-annex-remote-rclone
+git-annex: git-annex-remote-rclone: createProcess: does not exist (No such file or directory)
+failed
+git-annex: proxy: 1 failed
+
+$ git annex proxy -- which git-annex-remote-rclone
+/d/bin/git-annex-remote-rclone
+
+$ git annex proxy -- /d/bin/git-annex-remote-rclone
+git-annex: D:/bin/git-annex-remote-rclone: createProcess: invalid argument (Exec format error)
+failed
+git-annex: proxy: 1 failed
+
+$ git annex proxy -- sh /d/bin/git-annex-remote-rclone
+VERSION 1
+
+# End of transcript or log.
+"""]]
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+Oh yeah! This software is awesome. After getting used to having "dummy" shortcuts to content I don't currently have, with the simple ability to get/drop that content, I can't believe I haven't seen this anywhere before. If there is anything more impressive than this software, it's the support it has had from Joey over all this time. I'd have pulled my hair out long ago. :P

Added a comment: Oh and to be slightly helpful
diff --git a/doc/todo/Amazon_Cloud_Drive/comment_4_7e66da169c3decb5771226cd3d4a905b._comment b/doc/todo/Amazon_Cloud_Drive/comment_4_7e66da169c3decb5771226cd3d4a905b._comment
new file mode 100644
index 0000000..f66db89
--- /dev/null
+++ b/doc/todo/Amazon_Cloud_Drive/comment_4_7e66da169c3decb5771226cd3d4a905b._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="jason.dixon.email@aa0e536a2ec2877d6f666108dbbc6e39bbe87ac0"
+ nickname="jason.dixon.email"
+ avatar="http://cdn.libravatar.org/avatar/fbe9050fc83bbd536d307d87ea14d4bc"
+ subject="Oh and to be slightly helpful"
+ date="2017-03-08T08:57:08Z"
+ content="""
+This is with version 6.20170302. So as of this writing, the current version I believe.
+"""]]

Added a comment: Same issue with rclone on windows.
diff --git a/doc/todo/Amazon_Cloud_Drive/comment_3_6a4833f0c52d3726cd95d0818e0a89bf._comment b/doc/todo/Amazon_Cloud_Drive/comment_3_6a4833f0c52d3726cd95d0818e0a89bf._comment
new file mode 100644
index 0000000..c1fd609
--- /dev/null
+++ b/doc/todo/Amazon_Cloud_Drive/comment_3_6a4833f0c52d3726cd95d0818e0a89bf._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="jason.dixon.email@aa0e536a2ec2877d6f666108dbbc6e39bbe87ac0"
+ nickname="jason.dixon.email"
+ avatar="http://cdn.libravatar.org/avatar/fbe9050fc83bbd536d307d87ea14d4bc"
+ subject="Same issue with rclone on windows."
+ date="2017-03-08T08:55:48Z"
+ content="""
+Using linux it works perfectly. Really great. But on windows no such luck. Trying many things to get it to function and no success.
+
+Given the thinness of the bash wrapper that binds rclone to annex, and rclones inherent cross platform nature. It would be awesome to have this remote as a first class citizen. Similar to amazon glacier requiring glacier-cli. Simply requiring rclone to open up so many backends is a very light dependency. :)
+"""]]

Added a comment: Still seems useful
diff --git a/doc/todo/Specify_maximum_usable_space_per_remote/comment_5_c5069ffed5e8c4e1d001aedb971aca75._comment b/doc/todo/Specify_maximum_usable_space_per_remote/comment_5_c5069ffed5e8c4e1d001aedb971aca75._comment
new file mode 100644
index 0000000..f9c2465
--- /dev/null
+++ b/doc/todo/Specify_maximum_usable_space_per_remote/comment_5_c5069ffed5e8c4e1d001aedb971aca75._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="jason.dixon.email@aa0e536a2ec2877d6f666108dbbc6e39bbe87ac0"
+ nickname="jason.dixon.email"
+ avatar="http://cdn.libravatar.org/avatar/fbe9050fc83bbd536d307d87ea14d4bc"
+ subject="Still seems useful"
+ date="2017-03-07T10:19:41Z"
+ content="""
+I dunno. I get your point. However I can also see this being a really useful feature. I can imagine it being implemented simply with a warning / note mentioning disconnected repos might overflow the limit (and perhaps a buffer should be left ie: limit = 15gb, allocate = 13gb). It would be up to the user to figure out what is right for them.
+
+I'm sure plenty of people either using the remote alone, in a small team, or with linked up repos (github/gitlab/whatever) would appreciate this option. I know I came to this page looking to see if it was possible already. :)
+
+Thanks too for the hard work! Amazing software!
+"""]]

Added a comment: I hope the option to show missing files remains.
diff --git a/doc/todo/hide_missing_files/comment_1_9851558a528119279a901e97de285d39._comment b/doc/todo/hide_missing_files/comment_1_9851558a528119279a901e97de285d39._comment
new file mode 100644
index 0000000..555fbef
--- /dev/null
+++ b/doc/todo/hide_missing_files/comment_1_9851558a528119279a901e97de285d39._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="jason.dixon.email@aa0e536a2ec2877d6f666108dbbc6e39bbe87ac0"
+ nickname="jason.dixon.email"
+ avatar="http://cdn.libravatar.org/avatar/fbe9050fc83bbd536d307d87ea14d4bc"
+ subject="I hope the option to show missing files remains."
+ date="2017-03-07T06:30:37Z"
+ content="""
+I can certainly understand the issue when people are looking to git annex like a syncthing / dropbox / bittorrent sync alternative and expecting to only see files they have. But, at least for me personally, the feature of listing files I don't have, but *can get* is HUGE. I love being able to see what I have at a glance. Being able to rename and shuffle around files that are not present on my system. This to me is one of the biggest advantages of annex over the competition.
+
+This is both in context of personal file bookkeeping (ie photo library / music etc etc) and in projects (many maya files that are not currently being referenced, but at a glance can be seen).
+
+I suppose, a compromise for usability could be to add custom icons to missing files (yeah I know... cross platform!) such as other sync programs do for incomplete-syncing files, or gui's such as tortoiseGit/SVN do for tracked files.
+"""]]

comment
diff --git a/doc/bugs/S3_remote___8212___un-embedding_creds__63__/comment_3_07fb8558238285883d11d8805884bdae._comment b/doc/bugs/S3_remote___8212___un-embedding_creds__63__/comment_3_07fb8558238285883d11d8805884bdae._comment
new file mode 100644
index 0000000..fb97783
--- /dev/null
+++ b/doc/bugs/S3_remote___8212___un-embedding_creds__63__/comment_3_07fb8558238285883d11d8805884bdae._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2017-03-06T17:34:29Z"
+ content="""
+If `git annex info` had said that the creds were not embedded after
+you tried `embedcreds=no`, then wouldn't you have belived it, and so not
+revoked the creds on AWS?
+"""]]

assistant: Add 1/200th second delay between checking each file in the full transfer scan, to avoid using too much CPU.
The slowdown is not going to be large in typical small-ish repos.
And it does not seem to matter if the assistant reacts a little bit slower
in situations involving the expensive scan, since:
a) Those situations typically involve getting back in sync after something
has changed on a remote, often after a disconnect of some duration.
So taking a few seconds more is not noticable.
b) If the scan finds things that it needs to do, it will start
blocking anyway after 10 transfers are queued (due to use of
queueTransferWhenSmall). So, only the speed of finding the first 10
transfers will be impacted by this change.
This commit was sponsored by Jochen Bartl on Patreon.
diff --git a/Assistant/Threads/TransferScanner.hs b/Assistant/Threads/TransferScanner.hs
index a55a349..2128ce9 100644
--- a/Assistant/Threads/TransferScanner.hs
+++ b/Assistant/Threads/TransferScanner.hs
@@ -25,6 +25,7 @@ import qualified Types.Remote as Remote
 import Utility.ThreadScheduler
 import Utility.NotificationBroadcaster
 import Utility.Batch
+import Utility.ThreadScheduler
 import qualified Git.LsFiles as LsFiles
 import Annex.WorkTree
 import Annex.Content
@@ -32,6 +33,7 @@ import Annex.Wanted
 import CmdLine.Action
 
 import qualified Data.Set as S
+import Control.Concurrent
 
 {- This thread waits until a remote needs to be scanned, to find transfers
  - that need to be made, to keep data in sync.
@@ -145,6 +147,10 @@ expensiveScan urlrenderer rs = batch <~> do
 			(findtransfers f unwanted)
 				=<< liftAnnex (lookupFile f)
 		mapM_ (enqueue f) ts
+
+		{- Delay for a short time to avoid using too much CPU. -}
+		liftIO $ threadDelay $ fromIntegral $ oneSecond `div` 200
+
 		scan unwanted' fs
 
 	enqueue f (r, t) =
diff --git a/CHANGELOG b/CHANGELOG
index 524ad53..d6297bb 100644
--- a/CHANGELOG
+++ b/CHANGELOG
@@ -5,6 +5,8 @@ git-annex (6.20170301.2) UNRELEASED; urgency=medium
   * status: Propigate nonzero exit code from git status.
   * Linux standalone builds put the bundled ssh last in PATH,
     so any system ssh will be preferred over it.
+  * assistant: Add 1/200th second delay between checking each file
+    in the full transfer scan, to avoid using too much CPU.
 
  -- Joey Hess <id@joeyh.name>  Thu, 02 Mar 2017 12:51:40 -0400
 
diff --git a/doc/forum/__34__Scanning_for_files_to_transfer__34__/comment_1_4fa6d0d5264707886e1e9b5184090386._comment b/doc/forum/__34__Scanning_for_files_to_transfer__34__/comment_1_4fa6d0d5264707886e1e9b5184090386._comment
new file mode 100644
index 0000000..cab618d
--- /dev/null
+++ b/doc/forum/__34__Scanning_for_files_to_transfer__34__/comment_1_4fa6d0d5264707886e1e9b5184090386._comment
@@ -0,0 +1,36 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2017-03-06T17:03:12Z"
+ content="""
+The scan that is skipped is one of the files on disk in order to find
+changes that were made while the assistant was not running.
+
+What you are seeing is the full transfer scan. While annex.startupscan
+could be made to also skip that scan, a full transfer scan is not only run
+at startup, but after merging git-annex branch changes from a remote. So
+disabling it only at startup does not seem very useful.
+
+There could be an option to disable the full transfer scan ever running.
+However, this would make the assistant not notice certian transfers/drops
+that you would normally want it to do. For example, if a remote got a bunch
+of files in an archive/ directory from somewhere else, and the local
+repository contains those files, the full transfer scan is needed to notice
+that the archived files can now be removed from the local repository.
+In other situations, the local repository would not get files that it
+ought to contain.
+
+So, I think it might be better to make the expensive transfer scan run a
+little bit slower so it doesn't peg your CPU. I've added a 1/200th second
+delay after each file it checks. 
+
+That will make it use something like 
+5-10% of the CPU, instead of 100%. At the same time it doesn't slow down the
+total scan very much. In a repository with 5k files, it makes the scan 25
+seconds slower, which makes the assistant react that much slower -- but
+the expensive scan is only needed to make sure things turn out consistent,
+so its overall speed is not super important.
+
+Check it out, let me know if it's still using too much CPU. We could always
+make that 1/200th second tunable, or find a better value for it.
+"""]]

comment
diff --git a/doc/bugs/git_annex_import_is_dangerous_if_you_have_unused_objects/comment_5_1e737b740bc7d95f3329e3481d55fd35._comment b/doc/bugs/git_annex_import_is_dangerous_if_you_have_unused_objects/comment_5_1e737b740bc7d95f3329e3481d55fd35._comment
new file mode 100644
index 0000000..89b088f
--- /dev/null
+++ b/doc/bugs/git_annex_import_is_dangerous_if_you_have_unused_objects/comment_5_1e737b740bc7d95f3329e3481d55fd35._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2017-03-06T16:25:53Z"
+ content="""
+The difficulty with checking if the content to be imported is referred to
+somewhere in the working tree is that there's no inexpensive way to
+determine that. It would have to run `git log -n1 -S$KEY` for each file.
+That can take quite a long time in repositories with a lot of history.
+I clocked it at 12 seconds per file on an SSD; will be quite a
+lot slower on a disc.
+
+I suppose that check could be added with a --fast to skip the check.
+
+PS, mbroadhead's is a good approach. Note though that the dropunused content
+will be considered a duplicate by import since git-annex
+version 6.20170214. Still, --deduplicate and --clean-duplicates won't
+delete the files from the import location in this case, since there
+are no copies of the content in the annex.
+"""]]

response
This commit was sponsored by Thom May on Patreon.
diff --git a/doc/forum/Debugging_of_transfer_considerations/comment_1_e68ab187c15b3b6f9384a990da07f358._comment b/doc/forum/Debugging_of_transfer_considerations/comment_1_e68ab187c15b3b6f9384a990da07f358._comment
new file mode 100644
index 0000000..ba943b8
--- /dev/null
+++ b/doc/forum/Debugging_of_transfer_considerations/comment_1_e68ab187c15b3b6f9384a990da07f358._comment
@@ -0,0 +1,39 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2017-03-06T16:08:55Z"
+ content="""
+Currently the best way to debug this kind of thing is to use git annex find
+with options to find files that match the preferred content expression.
+Once you have gotten git annex find to list the same files that are being
+transferred, you can then modify/cut down the options to narrow down
+what's going on.
+
+The preferred content expression for a client repository is:
+
+	(include=* and ((exclude=*/archive/* and exclude=archive/*) or (not (copies=archive:1 or copies=smallarchive:1)))) or approxlackingcopies=1
+
+Translating this to command-line options:
+
+	git annex find '-(' '--include=*' --and '-(' '-(' '--exclude=*/archive/*' --and '--exclude=archive/*' '-)' --or '-(' --not '-(' --copies=archive:1 --or --copies=smallarchive:1 '-)' '-)' '-)' '-)' --or --approxlackingcopies=1
+
+You'll want to run that when the files are not located in the archive/
+directory, and run it from the top of the repository.
+
+Assuming that lists the files that are getting transferred, then you can
+split it into two commands, each of which checks one of the two parts
+of the expression that are ORed together:
+
+	git annex find '-(' '--include=*' --and '-(' '-(' '--exclude=*/archive/*' --and '--exclude=archive/*' '-)' --or '-(' --not '-(' --copies=archive:1 --or --copies=smallarchive:1 '-)' '-)' '-)' '-)'
+	git annex find --approxlackingcopies=1
+
+Assuming the first of those lists the files and not the second, you can
+then split it further. The include=* part must be matching then, so
+checking two parts ORed within the second part:
+	
+	git annex find '-(' '--exclude=*/archive/*' --and '--exclude=archive/*' '-)'
+	git annex find '-(' --not '-(' --copies=archive:1 --or --copies=smallarchive:1 '-)' '-)'
+
+Probably one of those will list the files and the other won't.
+Which will point fairly strongly at what's happening.
+"""]]

Added a comment
diff --git a/doc/bugs/git_annex_status_fails_with_submodule_in_direct_mode/comment_7_4e4d2ae552e2394197c2688b0dd04f48._comment b/doc/bugs/git_annex_status_fails_with_submodule_in_direct_mode/comment_7_4e4d2ae552e2394197c2688b0dd04f48._comment
new file mode 100644
index 0000000..85573f3
--- /dev/null
+++ b/doc/bugs/git_annex_status_fails_with_submodule_in_direct_mode/comment_7_4e4d2ae552e2394197c2688b0dd04f48._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="benjamin.poldrack@d09ccff6d42dd20277610b59867cf7462927b8e3"
+ nickname="benjamin.poldrack"
+ avatar="http://cdn.libravatar.org/avatar/5c1a901caa7c2cfeeb7e17e786c5230d"
+ subject="comment 7"
+ date="2017-03-06T09:03:56Z"
+ content="""
+Thank you!
+
+[[ben]]
+"""]]

diff --git a/doc/forum/Debugging_of_transfer_considerations.mdwn b/doc/forum/Debugging_of_transfer_considerations.mdwn
new file mode 100644
index 0000000..eb75e39
--- /dev/null
+++ b/doc/forum/Debugging_of_transfer_considerations.mdwn
@@ -0,0 +1,6 @@
+I have a client repository with an archive/ directory. If I let the assistant sync the repos or initiate a manual `git annex sync --content` the contents of the archive directory is filled up.
+
+I can't see why this happens. The repo is a client repo with the standard preferred contents and no required contents onfig.
+One of the files that is wanted has 2 copies in backup repositories (one is trusted and one is reachable and semitrusted). `git annex numcopies` is 2 for one of these files. The repos were checked by `git annex fsck` and synced.
+
+I'm not sure what to look for or how to debug this kind of situation. Any ideas? 

comment
diff --git a/doc/tips/using_signed_git_commits/comment_2_5fb568fcd3aa376d2ee36c660a4a02a2._comment b/doc/tips/using_signed_git_commits/comment_2_5fb568fcd3aa376d2ee36c660a4a02a2._comment
new file mode 100644
index 0000000..2d321bb
--- /dev/null
+++ b/doc/tips/using_signed_git_commits/comment_2_5fb568fcd3aa376d2ee36c660a4a02a2._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2017-03-03T17:58:40Z"
+ content="""
+To clarify, this only prevents SHA1 collision attacks from causing problems
+with annexed files. Files checked into the git repository itself are still
+vulnerable to collision attacks.
+"""]]

Added a comment
diff --git a/doc/bugs/git_annex_import_is_dangerous_if_you_have_unused_objects/comment_4_09b860a14bb8bd49f2067e8ddb0aacfc._comment b/doc/bugs/git_annex_import_is_dangerous_if_you_have_unused_objects/comment_4_09b860a14bb8bd49f2067e8ddb0aacfc._comment
new file mode 100644
index 0000000..877c0ff
--- /dev/null
+++ b/doc/bugs/git_annex_import_is_dangerous_if_you_have_unused_objects/comment_4_09b860a14bb8bd49f2067e8ddb0aacfc._comment
@@ -0,0 +1,39 @@
+[[!comment format=mdwn
+ username="mbroadhead"
+ avatar="http://cdn.libravatar.org/avatar/f3d801c0c943caab1152c4ebe8c99d51"
+ subject="comment 4"
+ date="2017-03-03T16:59:52Z"
+ content="""
+> I think there are situations where I want to completely abort a commit and
+> not have to worry about it biting me down the road.
+
+If you don't want to have to worry about a `git reset --hard` biting you down
+the road the way that it works now, just make sure you clean up after yourself.
+Example:
+
+```
+cd ~/annex
+cp /tmp/foo .
+git annex add foo
+
+# Oh, I decided I don't want \"foo\" in my annex right now, so I do a reset.
+# This will leave the data associated with \"foo\" in a git object in the git
+# store.  When running 'git annex import' sometime in the future, this will
+# make any files that contain the same data as \"foo\" to be considered
+# duplicate.  This will cause \"foo\" to be considered a duplicate by git annex
+# import, which we don't want in this scenario.
+git reset --hard
+
+# In order to avoid \"foo\" being a duplicate, find the dangling git object:
+git annex unused
+
+# And drop it:
+git annex dropunused N
+
+# Now \"foo\" won't be marked as a duplicate if you run any of the following
+# commands:
+git annex import /tmp/backup/foo --skip-duplicates
+git annex import /tmp/backup/foo --clean-duplicates
+git annex import /tmp/backup/foo --deduplicate
+```
+"""]]

Added a comment: Does this not work counter to locking / unlocking files?
diff --git a/doc/todo/utilising_the_mklink_command_on_windows_to_utilise_symlinks_and_therefore_indirect_mode_on_windows/comment_2_575d96ffa2a8f2cb1ba3d0e5c4ba4e6f._comment b/doc/todo/utilising_the_mklink_command_on_windows_to_utilise_symlinks_and_therefore_indirect_mode_on_windows/comment_2_575d96ffa2a8f2cb1ba3d0e5c4ba4e6f._comment
new file mode 100644
index 0000000..ad37ac8
--- /dev/null
+++ b/doc/todo/utilising_the_mklink_command_on_windows_to_utilise_symlinks_and_therefore_indirect_mode_on_windows/comment_2_575d96ffa2a8f2cb1ba3d0e5c4ba4e6f._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="jason.dixon.email@aa0e536a2ec2877d6f666108dbbc6e39bbe87ac0"
+ nickname="jason.dixon.email"
+ avatar="http://cdn.libravatar.org/avatar/fbe9050fc83bbd536d307d87ea14d4bc"
+ subject="Does this not work counter to locking / unlocking files?"
+ date="2017-03-03T13:40:06Z"
+ content="""
+Perhaps I understand this wrong. But if you're in a position to be viewing symlinks, then the file is in effect, locked right? So in the situation that a windows user is trying to edit a file that is currently symlinked, they shouldn't be allowed to save at all. They should have unlocked the file first, thus replacing the link with the actual file. A simple fix would be to have the symlink read-only just as the file tucked away in .git/annex/objects is.
+
+As I said, I'm probably looking at this in entirely the wrong way.
+"""]]

removed
diff --git a/doc/tips/using_signed_git_commits/comment_2_0dc5119944132808299da2092b01b25f._comment b/doc/tips/using_signed_git_commits/comment_2_0dc5119944132808299da2092b01b25f._comment
deleted file mode 100644
index 3678bba..0000000
--- a/doc/tips/using_signed_git_commits/comment_2_0dc5119944132808299da2092b01b25f._comment
+++ /dev/null
@@ -1,10 +0,0 @@
-[[!comment format=mdwn
- username="xloem"
- avatar="http://cdn.libravatar.org/avatar/b8c087f7c5e6a9358748f0727c077f3b"
- subject="Non-conforming blobs"
- date="2017-03-03T12:30:34Z"
- content="""
-It seems git-annex needs some way to verify that all blobs match its expected format for this security to be strong.  My histories have tons of huge binary blobs in them from when I tried upgrading to v6 before it was stable and got a lot of data committed raw.  I guess I need to rewrite my history to contain only verified blobs?
-
-It's really too bad git hasn't upgraded to a newer hashing function by now.  They should make a plan to do that at least once a decade.
-"""]]

Added a comment: Non-conforming blobs
diff --git a/doc/tips/using_signed_git_commits/comment_2_0dc5119944132808299da2092b01b25f._comment b/doc/tips/using_signed_git_commits/comment_2_0dc5119944132808299da2092b01b25f._comment
new file mode 100644
index 0000000..3678bba
--- /dev/null
+++ b/doc/tips/using_signed_git_commits/comment_2_0dc5119944132808299da2092b01b25f._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="xloem"
+ avatar="http://cdn.libravatar.org/avatar/b8c087f7c5e6a9358748f0727c077f3b"
+ subject="Non-conforming blobs"
+ date="2017-03-03T12:30:34Z"
+ content="""
+It seems git-annex needs some way to verify that all blobs match its expected format for this security to be strong.  My histories have tons of huge binary blobs in them from when I tried upgrading to v6 before it was stable and got a lot of data committed raw.  I guess I need to rewrite my history to contain only verified blobs?
+
+It's really too bad git hasn't upgraded to a newer hashing function by now.  They should make a plan to do that at least once a decade.
+"""]]

Added a comment: Non-conforming blobs
diff --git a/doc/tips/using_signed_git_commits/comment_1_82241dc5666e1b573a24b3e84f3991ae._comment b/doc/tips/using_signed_git_commits/comment_1_82241dc5666e1b573a24b3e84f3991ae._comment
new file mode 100644
index 0000000..b8f9c78
--- /dev/null
+++ b/doc/tips/using_signed_git_commits/comment_1_82241dc5666e1b573a24b3e84f3991ae._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="xloem"
+ avatar="http://cdn.libravatar.org/avatar/b8c087f7c5e6a9358748f0727c077f3b"
+ subject="Non-conforming blobs"
+ date="2017-03-03T12:29:51Z"
+ content="""
+It seems git-annex needs some way to verify that all blobs match its expected format for this security to be strong.  My histories have tons of huge binary blobs in them from when I tried upgrading to v6 before it was stable and got a lot of data committed raw.  I guess I need to rewrite my history to contain only verified blobs?
+
+It's really too bad git hasn't upgraded to a newer hashing function by now.  They should make a plan to do that at least once a decade.
+"""]]

Added a comment
diff --git a/doc/bugs/git_annex_import_is_dangerous_if_you_have_unused_objects/comment_3_d980c1e2d788324049475e468a0d6fab._comment b/doc/bugs/git_annex_import_is_dangerous_if_you_have_unused_objects/comment_3_d980c1e2d788324049475e468a0d6fab._comment
new file mode 100644
index 0000000..e86ff13
--- /dev/null
+++ b/doc/bugs/git_annex_import_is_dangerous_if_you_have_unused_objects/comment_3_d980c1e2d788324049475e468a0d6fab._comment
@@ -0,0 +1,23 @@
+[[!comment format=mdwn
+ username="mbroadhead"
+ avatar="http://cdn.libravatar.org/avatar/f3d801c0c943caab1152c4ebe8c99d51"
+ subject="comment 3"
+ date="2017-03-02T22:48:08Z"
+ content="""
+Thanks for the insight.
+
+The `git stash` solution works assuming you are either:
+
+ a. Going to keep it in your stash forever
+ b. You are going to commit your stash eventually
+
+I think there are situations where I want to completely abort a commit and not have to worry about it biting me down the road.
+
+IMO from a end user perspective I think the best solution would be to have data only count as duplicate if it has a reachable file in your annex for options `--deduplicate`, `--clean-duplicates` and `--skip-duplicates` of `git annex import`.
+
+What would be the downside to this?
+
+Worst case scenario this re-wires up some symlinks to once dangling git objects. They still aren't duplicates, there will only be one symlink per formerly dangling git object. This seems better than data loss.
+
+Thoughts?
+"""]]

Linux standalone builds put the bundled ssh last in PATH, so any system ssh will be preferred over it.
This commit was sponsored by Denis Dzyubenko on Patreon.
diff --git a/Build/BundledPrograms.hs b/Build/BundledPrograms.hs
index a9a29b6..271e1dd 100644
--- a/Build/BundledPrograms.hs
+++ b/Build/BundledPrograms.hs
@@ -32,6 +32,16 @@ extraBundledPrograms = catMaybes
 #else
 	[
 #endif
+#ifndef darwin_HOST_OS
+#ifndef mingw32_HOST_OS
+	-- OS X has ssh installed by default.
+	-- On Windows, git provides ssh.
+	-- Linux probably has ssh installed system wide,
+	-- and if so the user probably wants to use that one.
+	, Just "ssh"
+	, Just "ssh-keygen"
+#endif
+#endif
 	]
 
 {- Programs that should be preferred for use from the bundle, over
@@ -57,15 +67,6 @@ preferredBundledPrograms = catMaybes
 	, Just "xargs"
 #endif
 	, Just "rsync"
-#ifndef darwin_HOST_OS
-#ifndef mingw32_HOST_OS
-	-- OS X has ssh installed by default.
-	-- Linux probably has ssh, but not guaranteed.
-	-- On Windows, git provides ssh.
-	, Just "ssh"
-	, Just "ssh-keygen"
-#endif
-#endif
 #ifndef mingw32_HOST_OS
 	, Just "sh"
 #endif
diff --git a/CHANGELOG b/CHANGELOG
index 3939762..524ad53 100644
--- a/CHANGELOG
+++ b/CHANGELOG
@@ -3,6 +3,8 @@ git-annex (6.20170301.2) UNRELEASED; urgency=medium
   * Bugfix: Passing a command a filename that does not exist sometimes
     did not display an error, when a path to a directory was also passed.
   * status: Propigate nonzero exit code from git status.
+  * Linux standalone builds put the bundled ssh last in PATH,
+    so any system ssh will be preferred over it.
 
  -- Joey Hess <id@joeyh.name>  Thu, 02 Mar 2017 12:51:40 -0400
 
diff --git a/doc/bugs/configuration_options_for_system_ssh_and_bundled_ssh_are_incompatible.mdwn b/doc/bugs/configuration_options_for_system_ssh_and_bundled_ssh_are_incompatible.mdwn
index 13f09d9..a61caca 100644
--- a/doc/bugs/configuration_options_for_system_ssh_and_bundled_ssh_are_incompatible.mdwn
+++ b/doc/bugs/configuration_options_for_system_ssh_and_bundled_ssh_are_incompatible.mdwn
@@ -51,3 +51,4 @@ git-annex: sync: 2 failed
 ### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
 
 
+> [[done]]; moved ssh to extra directory. --[[Joey]]
diff --git a/doc/bugs/configuration_options_for_system_ssh_and_bundled_ssh_are_incompatible/comment_1_abdd5622dc1733a8b59dc11885083799._comment b/doc/bugs/configuration_options_for_system_ssh_and_bundled_ssh_are_incompatible/comment_1_abdd5622dc1733a8b59dc11885083799._comment
new file mode 100644
index 0000000..2024b29
--- /dev/null
+++ b/doc/bugs/configuration_options_for_system_ssh_and_bundled_ssh_are_incompatible/comment_1_abdd5622dc1733a8b59dc11885083799._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2017-03-02T21:30:55Z"
+ content="""
+One way to deal with this would be to put the bundled ssh in the
+git-annex.linux/extra/ directory. Programs in that directory are added to the
+end of the path, so that system versions will be preferred when available.
+
+That was earlier done for gpg and didn't cause any problems.
+
+There is the potential for some sort of versioning problem. Currently the
+only thing git-annex probes about the bundled ssh is if it supports
+connection caching. That's quite an old feature by now, so a system ssh not
+supporting it would either be super out of date and insecure openssh, or
+perhaps some other ssh implementation.
+
+Seems worth moving the bundled ssh to the extra directory, and see what
+breaks..
+"""]]

diff --git a/doc/forum/__34__Scanning_for_files_to_transfer__34__.mdwn b/doc/forum/__34__Scanning_for_files_to_transfer__34__.mdwn
new file mode 100644
index 0000000..e08be0b
--- /dev/null
+++ b/doc/forum/__34__Scanning_for_files_to_transfer__34__.mdwn
@@ -0,0 +1,9 @@
+I have a Git Annex repository on my laptop with currently 141094 files.
+
+I used "git config annex.startupscan false" to disable the startup scan.
+
+Yet the assistant still runs at high CPU consumption for extended periods of time after starting.
+
+In the webapp, the startup scan is shown as completed, but under "Transfers" it says "Scanning for files to transfer".
+
+What is the difference between "Performing startup scan" and "Scanning for files to transfer"?

comment
diff --git a/doc/bugs/git_annex_import_is_dangerous_if_you_have_unused_objects/comment_2_f64891ff6fe0cd0be6a356ab8fe42817._comment b/doc/bugs/git_annex_import_is_dangerous_if_you_have_unused_objects/comment_2_f64891ff6fe0cd0be6a356ab8fe42817._comment
new file mode 100644
index 0000000..0b45952
--- /dev/null
+++ b/doc/bugs/git_annex_import_is_dangerous_if_you_have_unused_objects/comment_2_f64891ff6fe0cd0be6a356ab8fe42817._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2017-03-02T21:26:57Z"
+ content="""
+One way to fix this would be to make `git reset --hard` first make a commit
+of the current state of the index, and store that commit in the reflog. 
+
+Of course, that's quite similar to `git stash` and probably most of us have
+just gotten in the habit of running `git stash` instead.
+"""]]