diff --git a/doc/forum/How_to_deal_with_spotlight_and_macOS/comment_1_3d76fbb8f13bd66d729819a4d037ab4f._comment b/doc/forum/How_to_deal_with_spotlight_and_macOS/comment_1_3d76fbb8f13bd66d729819a4d037ab4f._comment
new file mode 100644
index 000000000..f0105608f
--- /dev/null
+++ b/doc/forum/How_to_deal_with_spotlight_and_macOS/comment_1_3d76fbb8f13bd66d729819a4d037ab4f._comment
@@ -0,0 +1,26 @@
+[[!comment format=mdwn
+ username="andrew"
+ avatar="http://cdn.libravatar.org/avatar/acc0ece1eedf07dd9631e7d7d343c435"
+ subject="spotlight and macOS"
+ date="2020-03-29T15:27:40Z"
+ content="""
+I also struggle with these issues on macOS.
+
+One workaround would be to always use [unlocked files](https://git-annex.branchable.com/tips/unlocked_files/), 
+
+    git config annex.addunlocked true
+
+The main disadvantage here is that you use double the disk space for every file. After switching to unlocked files you could then also switch to `thin` mode:
+
+    git config annex.thin true
+    git annex fix
+
+Which would only keep 1 copy of every file (using hardlinks), so you are back down to a normal amount of disk space, but you give up some of the protections of git-annex since you could easily delete the only copy of your files.
+
+I have verified that using unlocked files and using unlocked-thin both fix file names in Preview and mail attachments. I'm not sure if both these methods allow files to be indexed by Spotlight.
+
+I have also been hoping to integrate many of these features into [git-annex-turtle](https://github.com/andrewringler/git-annex-turtle) using the [Search and Spotlight](https://developer.apple.com/design/human-interface-guidelines/macos/system-capabilities/search-and-spotlight/) developer APIs. Namely [Core Spotlight](https://developer.apple.com/documentation/corespotlight) could be used to index all `git-annex` locked/unlocked/present/not-present files and [Quick Look](https://developer.apple.com/design/human-interface-guidelines/macos/system-capabilities/quick-look/) APIs could be used to allow previewing of not present files using cached thumbnails.
+
+—Andrew
+
+"""]]

diff --git a/doc/forum/Repair_in_steps__63__.mdwn b/doc/forum/Repair_in_steps__63__.mdwn
index e7f41aa63..b8b40142c 100644
--- a/doc/forum/Repair_in_steps__63__.mdwn
+++ b/doc/forum/Repair_in_steps__63__.mdwn
@@ -1,5 +1,5 @@
 If I understand correctly, 'git annex repair' first runs 'git fsck' and then tries to repair the repository by connecting to available remotes.
 
-It can take a long when 'git annex repair' runs 'git fsck' (at least 14 hours in my case). For me, it is not very convenient to have the remotes available during this entire time. It would be nice if I could connect to them only when necessary. This makes me wonder if it is possible to separate the running of git fsck from the operation of connecting to the remotes to repair the local repository. Or similarly, it would be nice to be able to run 'git annex repair' again quickly if it had just ran.
+It can take a long time when 'git annex repair' runs 'git fsck' (at least 14 hours in my case). For me, it is not very convenient to have the remotes available during this entire time. It would be nice if I could connect to them only when necessary. This makes me wonder if it is possible to separate the running of git fsck from the operation of connecting to the remotes to repair the local repository. Or similarly, it would be nice to be able to run 'git annex repair' again quickly if it had just ran.
 
 Thanks for any help on this

diff --git a/doc/forum/Repair_in_steps__63__.mdwn b/doc/forum/Repair_in_steps__63__.mdwn
new file mode 100644
index 000000000..e7f41aa63
--- /dev/null
+++ b/doc/forum/Repair_in_steps__63__.mdwn
@@ -0,0 +1,5 @@
+If I understand correctly, 'git annex repair' first runs 'git fsck' and then tries to repair the repository by connecting to available remotes.
+
+It can take a long when 'git annex repair' runs 'git fsck' (at least 14 hours in my case). For me, it is not very convenient to have the remotes available during this entire time. It would be nice if I could connect to them only when necessary. This makes me wonder if it is possible to separate the running of git fsck from the operation of connecting to the remotes to repair the local repository. Or similarly, it would be nice to be able to run 'git annex repair' again quickly if it had just ran.
+
+Thanks for any help on this

diff --git a/doc/design/encryption.mdwn b/doc/design/encryption.mdwn
index e2e4bbf15..f506bf9c2 100644
--- a/doc/design/encryption.mdwn
+++ b/doc/design/encryption.mdwn
@@ -29,7 +29,7 @@ There does not seem to be much benefit to using the same cipher for
 two different encrypted remotes.
 
 So, the encrypted cipher is just stored with the rest of a remote's
-configuration in `remotes.log` (see [[internals]]). When `git
+configuration in `remote.log` (see [[internals]]). When `git
 annex intiremote` makes a remote, it generates a random symmetric
 cipher, and encrypt it with the specified gpg key. To allow another gpg
 public key access, update the encrypted cipher to be encrypted to both gpg
@@ -90,7 +90,7 @@ remotes.
 The symmetric cipher can be used to encrypt other content than the content
 sent to the remote. In particular, it may make sense to encrypt whatever
 access keys are used by the special remote with the cipher, and store that
-in remotes.log. This way anyone whose gpg key has been given access to 
+in `remote.log`. This way anyone whose gpg key has been given access to 
 the cipher can get access to whatever other credentials are needed to
 use the special remote.
 

diff --git a/doc/tips/publishing_your_files_to_the_public.mdwn b/doc/tips/publishing_your_files_to_the_public.mdwn
index fcc21f705..5716e1582 100644
--- a/doc/tips/publishing_your_files_to_the_public.mdwn
+++ b/doc/tips/publishing_your_files_to_the_public.mdwn
@@ -17,7 +17,7 @@ remote for the first time.
 
 Set up your special [[S3 remote|special_remotes/S3]] with (at least) these options:
 
-	git annex initremote public-s3 type=s3 encryption=none bucket=$BUCKET exporttree=yes public=yes encryption=none
+	git annex initremote public-s3 type=s3 encryption=none bucket=$BUCKET exporttree=yes public=yes
 
 Be sure to replace $BUCKET with something like 
 "public-bucket-joey" when you follow along in your shell.

diff --git a/doc/bugs/all_files_are_annexed_by_default/comment_5_a7d0f94e7df2d838d1f8042866081915._comment b/doc/bugs/all_files_are_annexed_by_default/comment_5_a7d0f94e7df2d838d1f8042866081915._comment
new file mode 100644
index 000000000..6814d42ad
--- /dev/null
+++ b/doc/bugs/all_files_are_annexed_by_default/comment_5_a7d0f94e7df2d838d1f8042866081915._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="vinicius.vin@6d4d58c59c394cd744d469c9d7c41e264331dfcd"
+ nickname="vinicius.vin"
+ avatar="http://cdn.libravatar.org/avatar/b332bfc1d3f49c196e1bff84b53d0f8b"
+ subject="comment 5"
+ date="2020-03-27T23:04:34Z"
+ content="""
+Both suggestions solve my issue.
+Thank you for the quick reply!
+"""]]

diff --git a/doc/bugs/all_files_are_annexed_by_default/comment_4_da7a858e0be1ff45dea0b6e8d05da89f._comment b/doc/bugs/all_files_are_annexed_by_default/comment_4_da7a858e0be1ff45dea0b6e8d05da89f._comment
new file mode 100644
index 000000000..ae24942a0
--- /dev/null
+++ b/doc/bugs/all_files_are_annexed_by_default/comment_4_da7a858e0be1ff45dea0b6e8d05da89f._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="comment 4"
+ date="2020-03-27T21:12:18Z"
+ content="""
+I meant, unless `annex.gitaddtoannex=false`.
+"""]]

diff --git a/doc/bugs/all_files_are_annexed_by_default/comment_3_b7fee790993867ff83af440f0b37aec4._comment b/doc/bugs/all_files_are_annexed_by_default/comment_3_b7fee790993867ff83af440f0b37aec4._comment
new file mode 100644
index 000000000..4b25eec8e
--- /dev/null
+++ b/doc/bugs/all_files_are_annexed_by_default/comment_3_b7fee790993867ff83af440f0b37aec4._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="comment 3"
+ date="2020-03-27T21:11:13Z"
+ content="""
+My \"upgrade to most recent version\" advice should have mentioned that the most recent version is 8.*, which will auto-upgrade your repositories to version 8.   If for whatever reason you don't want to do the upgrade right now, 7.* versions from 7.20191024 restore old behavior, as Kyle suggested.  Note  that if you have `annex.largefiles` configured, `git add` will add matching files to the annex, unless `annex.gitaddtoannex`. 
+"""]]

diff --git a/doc/bugs/all_files_are_annexed_by_default/comment_2_8ff76c57cfddc3ed745ca16a4100d5a6._comment b/doc/bugs/all_files_are_annexed_by_default/comment_2_8ff76c57cfddc3ed745ca16a4100d5a6._comment
new file mode 100644
index 000000000..c52ea7a42
--- /dev/null
+++ b/doc/bugs/all_files_are_annexed_by_default/comment_2_8ff76c57cfddc3ed745ca16a4100d5a6._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="kyle"
+ avatar="http://cdn.libravatar.org/avatar/7d6e85cde1422ad60607c87fa87c63f3"
+ subject="comment: resolved by 7.20191024"
+ date="2020-03-27T20:49:44Z"
+ content="""
+> git annex 7.20190912-1
+
+The `git add` behavior that you describe changed in 7.20191024.  The
+CHANGELOG entries under that release provide a good description of the
+current behavior.
+"""]]

diff --git a/doc/bugs/all_files_are_annexed_by_default/comment_1_7a15de0d33751507dcd6292230c940a0._comment b/doc/bugs/all_files_are_annexed_by_default/comment_1_7a15de0d33751507dcd6292230c940a0._comment
new file mode 100644
index 000000000..4d7debe8b
--- /dev/null
+++ b/doc/bugs/all_files_are_annexed_by_default/comment_1_7a15de0d33751507dcd6292230c940a0._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="git add behavior"
+ date="2020-03-27T20:49:19Z"
+ content="""
+It's a change in default behavior, but the old default was restored in the more recent versions.   (Detailed discussion [[here|forum/lets_discuss_git_add_behavior]]).  Can you upgrade to the most recent version?  [[install/conda]] lets you install one without being root.  You might also want to set `annex.gitaddtoannex` to `false`.
+"""]]

diff --git a/doc/bugs/all_files_are_annexed_by_default.mdwn b/doc/bugs/all_files_are_annexed_by_default.mdwn
index 5d5236fd3..11eafa81f 100644
--- a/doc/bugs/all_files_are_annexed_by_default.mdwn
+++ b/doc/bugs/all_files_are_annexed_by_default.mdwn
@@ -11,9 +11,9 @@ Any idea about how to solve it?
 
 Thank you
 
-git version 2.20.1
-
-git annex version 7.20190912-1
 
+Versions:
+git  2.20.1 /
+git annex  7.20190912-1 /
 ubuntu 19.10
 

diff --git a/doc/bugs/all_files_are_annexed_by_default.mdwn b/doc/bugs/all_files_are_annexed_by_default.mdwn
new file mode 100644
index 000000000..5d5236fd3
--- /dev/null
+++ b/doc/bugs/all_files_are_annexed_by_default.mdwn
@@ -0,0 +1,19 @@
+Hello,
+
+I am using git annex for three years with no issues :-), but now I am facing a problem I’ve never seen before.
+
+I have a repository with several annexed files since 2017. Usually, I add big files with ``git annex add`` while for regular  small files, I always use a simple ``git add``.
+My problem is, now, all files added with ``git annex add`` are always considered as annexed files, which is undesirable. If I clone a new copy of the repository, ``git add`` works as expected, but from the moment I run a simple ``git annex get somefile``, all ``git add`` is executed as if it were a ``git annex add``.
+
+I don't know if this is a bug or just a change in the default behavior.
+
+Any idea about how to solve it?
+
+Thank you
+
+git version 2.20.1
+
+git annex version 7.20190912-1
+
+ubuntu 19.10
+

diff --git a/doc/forum/How_to_deal_with_spotlight_and_macOS.mdwn b/doc/forum/How_to_deal_with_spotlight_and_macOS.mdwn
new file mode 100644
index 000000000..9dbdefaa9
--- /dev/null
+++ b/doc/forum/How_to_deal_with_spotlight_and_macOS.mdwn
@@ -0,0 +1,21 @@
+I have been using git annex for a while. I use it completely manually (i.e."git annex add .; git annex sync; git annex copy . --to=desktop") as a DIY Dropbox replacement. 
+
+I have some issues inherent with git annex but they will be reserved to another post.
+
+What I want to ask about now is how to integrate my git annex workflow with macOS?
+
+Specifically:
+
+1) If I search for something in spotlight, it apparently does not search the 'names' of symlinks, and so it is impossible to have spotlight index the git annex archive?
+2) Opening files in git annex, in particular, PDF files with Preview.app, the names of the files are the targets of the symlinks, not their names, so that you end up seeing "SHA256E-s146178--a7e80c95ffe943ceca774d7931651ab4c16574c6f4059ade342a3cdbda3a5ef9.pdf" as the title of the Preview.app window of the PDF you're looking at. This is especially heinous when you have many many open files and you're trying to find one of them and the titles just give you zero information.
+3) Trying to attach some of these files into mail attachments, again, the filename the recipient gets is "SHA256E-s146178--a7e80c95ffe943ceca774d7931651ab4c16574c6f4059ade342a3cdbda3a5ef9.pdf" which is quite useless for them, or even harmful because it can be very confusing if there are 10 attachments from git annex and they all have these crazy names.
+
+Is there anything that can be done about this? This seems to be a conflict between macOS insisting on referring to the target of symlinks as the true names for the files whereas git annex is happy with the names of the symlinks.
+
+I have used several things to work around this, e.g., instead of spotlight I can run 
+find . -iname "*something*" 
+in the terminal to search my archive (I have one archive with all my files).
+
+However it would be nice to integrate this into spotlight.
+
+The bigger problem are the file names. Is it possible to fix this by using hard links instead? Or somehow fool macOS into reading the names of the symlinks instead of the names of the targets of the symlinks?

diff --git a/doc/bugs/Sync_of_adjusted_branch_does_not_propagate_changed_submodule_commit/comment_3_9e1cc48bb2125cc8fd375e3ff2f3310f._comment b/doc/bugs/Sync_of_adjusted_branch_does_not_propagate_changed_submodule_commit/comment_3_9e1cc48bb2125cc8fd375e3ff2f3310f._comment
new file mode 100644
index 000000000..53d3ceeac
--- /dev/null
+++ b/doc/bugs/Sync_of_adjusted_branch_does_not_propagate_changed_submodule_commit/comment_3_9e1cc48bb2125cc8fd375e3ff2f3310f._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="kyle"
+ avatar="http://cdn.libravatar.org/avatar/7d6e85cde1422ad60607c87fa87c63f3"
+ subject="comment 3"
+ date="2020-03-26T23:32:56Z"
+ content="""
+Thanks for taking the time to review this patch and the `add --force-small` ones.  Very much appreciated!
+"""]]

diff --git a/doc/todo/create_debug_logs_but_erase_them_on_success/comment_2_8809f216aac308962917053ea24b9022._comment b/doc/todo/create_debug_logs_but_erase_them_on_success/comment_2_8809f216aac308962917053ea24b9022._comment
new file mode 100644
index 000000000..e28490bc0
--- /dev/null
+++ b/doc/todo/create_debug_logs_but_erase_them_on_success/comment_2_8809f216aac308962917053ea24b9022._comment
@@ -0,0 +1,36 @@
+[[!comment format=mdwn
+ username="lykos@d125a37d89b1cfac20829f12911656c40cb70018"
+ nickname="lykos"
+ avatar="http://cdn.libravatar.org/avatar/085df7b04d3408ba23c19f9c49be9ea2"
+ subject="comment 2"
+ date="2020-03-26T20:36:28Z"
+ content="""
+When testing a new version of git-annex-remote-googledrive, I often use a wrapper script like this:
+
+```
+# .zshrc.local
+
+f_git_annex () {
+        log_file=$(mktemp \"$(git rev-parse --git-dir 2>/dev/null)/annex/debug.XXX.log\" 2>/dev/null)
+        if [ $? -ne 0 ]; then
+                echo \"Error creating log file. Proceeding without logging.\"
+                git annex $@
+                return $?
+        fi
+
+        git annex $@ --debug 2> $log_file
+        if [ $? -ne 0 ]; then
+                echo \"Errors occurred. Debug log in $log_file\"
+                return $?
+        else
+                rm $log_file
+        fi
+      }
+alias ga='f_git_annex'
+```
+It's good enough for me in those cases. Changing the first line of the function to something like this
+```
+log_file=$(umask 077; mktemp /tmp/annex.debug.XXX.log\" 2>/dev/null)
+```
+would help against accumulating logs.
+"""]]

diff --git a/CHANGELOG b/CHANGELOG
index 2597424c0..cc1195c4c 100644
--- a/CHANGELOG
+++ b/CHANGELOG
@@ -8,9 +8,12 @@ git-annex (8.20200310) UNRELEASED; urgency=medium
     multiple times to git.
   * add --force-small: Fix a bug that, when adding a symbolic link,
     checked in the content of the file the symlink pointed to.
-    Thanks, Kyle Meyer for noticing and for the patch.
+    Thanks, Kyle Meyer for the patch.
   * add --force-small: Fix failure when passed a modified submodule.
-    Thanks, Kyle Meyer for noticing and for the patch.
+    Thanks, Kyle Meyer for the patch.
+  * When syncing changes back from an adjusted branch to the basis branch,
+    include changes to submodules.
+    Thanks, Kyle Meyer for the patch.
 
  -- Joey Hess <id@joeyh.name>  Mon, 16 Mar 2020 12:43:33 -0400
 
diff --git a/doc/bugs/Sync_of_adjusted_branch_does_not_propagate_changed_submodule_commit.mdwn b/doc/bugs/Sync_of_adjusted_branch_does_not_propagate_changed_submodule_commit.mdwn
index 3a1aae1fc..625d4c64d 100644
--- a/doc/bugs/Sync_of_adjusted_branch_does_not_propagate_changed_submodule_commit.mdwn
+++ b/doc/bugs/Sync_of_adjusted_branch_does_not_propagate_changed_submodule_commit.mdwn
@@ -91,3 +91,4 @@ index da05a3fa5..9627ae969 100644
 [[!meta author=kyle]]
 [[!tag projects/datalad]]
 
+> [[applied|done]], thanks! --[[Joey]]
diff --git a/doc/bugs/Sync_of_adjusted_branch_does_not_propagate_changed_submodule_commit/comment_2_e37aaf6d440b6c2a7567b3df1c344ff7._comment b/doc/bugs/Sync_of_adjusted_branch_does_not_propagate_changed_submodule_commit/comment_2_e37aaf6d440b6c2a7567b3df1c344ff7._comment
new file mode 100644
index 000000000..f17dd818f
--- /dev/null
+++ b/doc/bugs/Sync_of_adjusted_branch_does_not_propagate_changed_submodule_commit/comment_2_e37aaf6d440b6c2a7567b3df1c344ff7._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2020-03-26T18:53:05Z"
+ content="""
+Ok, figured it out.. reverseAdjustedTree uses a `propchanges`
+function that looks at the diff from adjusted branch to basis,
+and substitutes the new sha for the old one. So that's
+how the sha get changed.
+
+My analysis was otherwise correct, I think. And your patch is fine, now
+that I understand that. Applying it as-is.
+"""]]

diff --git a/doc/bugs/Sync_of_adjusted_branch_does_not_propagate_changed_submodule_commit/comment_1_5b56b989145a8ef6a6203e4df38e2288._comment b/doc/bugs/Sync_of_adjusted_branch_does_not_propagate_changed_submodule_commit/comment_1_5b56b989145a8ef6a6203e4df38e2288._comment
index 10ae6cd68..eddad0042 100644
--- a/doc/bugs/Sync_of_adjusted_branch_does_not_propagate_changed_submodule_commit/comment_1_5b56b989145a8ef6a6203e4df38e2288._comment
+++ b/doc/bugs/Sync_of_adjusted_branch_does_not_propagate_changed_submodule_commit/comment_1_5b56b989145a8ef6a6203e4df38e2288._comment
@@ -44,8 +44,7 @@ construct a TreeCommit from those. As far as I can see, that TreeCommit
 must be identical to the one it constructed before this patch.
 
 Hmm, so I added a debug print and it's not the same, the sha
-is different. Even weirder, the sha in `commit` never get stored
-in the git repo.
+is different.
 
 What am I missing?
 """]]

diff --git a/doc/bugs/Sync_of_adjusted_branch_does_not_propagate_changed_submodule_commit/comment_1_5b56b989145a8ef6a6203e4df38e2288._comment b/doc/bugs/Sync_of_adjusted_branch_does_not_propagate_changed_submodule_commit/comment_1_5b56b989145a8ef6a6203e4df38e2288._comment
new file mode 100644
index 000000000..10ae6cd68
--- /dev/null
+++ b/doc/bugs/Sync_of_adjusted_branch_does_not_propagate_changed_submodule_commit/comment_1_5b56b989145a8ef6a6203e4df38e2288._comment
@@ -0,0 +1,51 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2020-03-26T18:15:57Z"
+ content="""
+Little bit of a scary change, because calls to adjustTree could be not
+handling the case of a submodule correctly in their adjusttreeitem
+function.
+
+So I checked them all..
+
+Command.Export uses adjustTree with an adjusttreeitem
+function that runs catKey on the sha from the TreeItem.
+I think that would be ok, because catKey will see it's not 
+a key, and in that case it passes back the TreeItem unchanged.
+
+Each different adjusted branch has its
+own function. Most of those check if the TreeItem
+is a symlink, with a submodule is not, and they'll return
+it unchanged.
+
+The PresenceAdjustment instead
+uses catKey, and again looks ok, because it falls back to returning the
+TreeItem unchanged.
+
+The LockAdjustment, when the TreeItem is not a symlink, also uses catKey,
+which will see it's not a key, and also falls back to returning the
+TreeItem unchanged.
+
+
+Think that's everything, so this seems a safe change to make.
+
+----
+
+But.. I don't actually understand how your change fixes the problem!
+
+(Of course, I tried your patch, and it does work...)
+
+I've been staring at it for 30 minutes and it seems to me that
+the TreeItem you have it construct gets passed to adjusttreeitem,
+which always returns it unchanged (per analysis above). Then you
+deconstruct the TreeItem, extracting the file mode and sha, and
+construct a TreeCommit from those. As far as I can see, that TreeCommit
+must be identical to the one it constructed before this patch.
+
+Hmm, so I added a debug print and it's not the same, the sha
+is different. Even weirder, the sha in `commit` never get stored
+in the git repo.
+
+What am I missing?
+"""]]

diff --git a/CHANGELOG b/CHANGELOG
index 556be5380..2597424c0 100644
--- a/CHANGELOG
+++ b/CHANGELOG
@@ -9,6 +9,8 @@ git-annex (8.20200310) UNRELEASED; urgency=medium
   * add --force-small: Fix a bug that, when adding a symbolic link,
     checked in the content of the file the symlink pointed to.
     Thanks, Kyle Meyer for noticing and for the patch.
+  * add --force-small: Fix failure when passed a modified submodule.
+    Thanks, Kyle Meyer for noticing and for the patch.
 
  -- Joey Hess <id@joeyh.name>  Mon, 16 Mar 2020 12:43:33 -0400
 
diff --git a/doc/bugs/add_--force-small_fails_on_modified_submodules.mdwn b/doc/bugs/add_--force-small_fails_on_modified_submodules.mdwn
index 95184491f..57d13efef 100644
--- a/doc/bugs/add_--force-small_fails_on_modified_submodules.mdwn
+++ b/doc/bugs/add_--force-small_fails_on_modified_submodules.mdwn
@@ -125,3 +125,4 @@ index 56e6fb236..72aae5f3c 100644
 [[!meta author=kyle]]
 [[!tag projects/datalad]]
 
+> [[applied|done]] --[[Joey]]
diff --git a/doc/bugs/add_--force-small_fails_on_modified_submodules/comment_1_95e4a43684338e28a74b6df8d2e5281a._comment b/doc/bugs/add_--force-small_fails_on_modified_submodules/comment_1_95e4a43684338e28a74b6df8d2e5281a._comment
new file mode 100644
index 000000000..eb7d18656
--- /dev/null
+++ b/doc/bugs/add_--force-small_fails_on_modified_submodules/comment_1_95e4a43684338e28a74b6df8d2e5281a._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2020-03-26T17:15:02Z"
+ content="""
+Really well done, thank you. Applied both.
+
+About the only thing I have to add is, I wonder if it would be better for 
+--force-small to just temporarily disable the clean filter and always
+use git add. Seems that might be less likely to run into this kind of
+breakage. OTOH, it looks like you've found all the possible bugs in it
+already... So I suppose I'll wait until the next bug is found in it to
+think about doing that. ;-)
+"""]]

diff --git a/Test.hs b/Test.hs
index 7b784d661..29f891dc4 100644
--- a/Test.hs
+++ b/Test.hs
@@ -1574,10 +1574,13 @@ test_crypto = do
   where
 	gpgcmd = Utility.Gpg.mkGpgCmd Nothing
 	testscheme scheme = do
-		gpgtmp <- (</> "gpgtest") <$> absPath tmpdir
+		abstmp <- absPath tmpdir
+		testscheme' scheme abstmp
+	testscheme' scheme abstmp = intmpclonerepo $ whenM (Utility.Path.inPath (Utility.Gpg.unGpgCmd gpgcmd)) $ do
+		-- Use a relative path to avoid too long path to gpg's
+		-- agent socket.
+		gpgtmp <- (</> "gpgtmp") <$> relPathCwdToFile abstmp
 		createDirectoryIfMissing False gpgtmp
-		testscheme' scheme gpgtmp
-	testscheme' scheme gpgtmp = intmpclonerepo $ whenM (Utility.Path.inPath (Utility.Gpg.unGpgCmd gpgcmd)) $ do
 		Utility.Gpg.testTestHarness gpgtmp gpgcmd 
 			@? "test harness self-test failed"
 		Utility.Gpg.testHarness gpgtmp gpgcmd $ do
diff --git a/doc/bugs/tests_fail___40__gpg-agent_related__63____41___when_running_build_inside_singularity_container/comment_2_c61b14b76cf06c0b10257c1a84d9478a._comment b/doc/bugs/tests_fail___40__gpg-agent_related__63____41___when_running_build_inside_singularity_container/comment_2_c61b14b76cf06c0b10257c1a84d9478a._comment
new file mode 100644
index 000000000..1e96fe5d5
--- /dev/null
+++ b/doc/bugs/tests_fail___40__gpg-agent_related__63____41___when_running_build_inside_singularity_container/comment_2_c61b14b76cf06c0b10257c1a84d9478a._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2020-03-26T16:55:30Z"
+ content="""
+Tried to reproduce it here running in a directory with the same lenth, but
+no failures. It could have to do with the old version of gpg-agent.
+
+(I don't see how gpg inside the container could talk to gpg-agent outside
+the container at all, unless the container shares a filesystem, and even
+then, gpg inside the container is being run with a nonstandard home
+directory, so it will not try to talk to a gpg-agent socket in the usual
+home directory.)
+
+I have a patch that makes the path to the socket file relative, but can't
+verify if it will fix the problem. I've applied it anyway.
+"""]]

diff --git a/doc/bugs/tests_fail___40__gpg-agent_related__63____41___when_running_build_inside_singularity_container/comment_1_d36c27dca4d266d1e6639e3435198016._comment b/doc/bugs/tests_fail___40__gpg-agent_related__63____41___when_running_build_inside_singularity_container/comment_1_d36c27dca4d266d1e6639e3435198016._comment
new file mode 100644
index 000000000..584be21d7
--- /dev/null
+++ b/doc/bugs/tests_fail___40__gpg-agent_related__63____41___when_running_build_inside_singularity_container/comment_1_d36c27dca4d266d1e6639e3435198016._comment
@@ -0,0 +1,35 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2020-03-26T16:19:02Z"
+ content="""
+After wasting 20 minutes on github's atrocious mess of an interface, I
+managed to download some raw logs that I can look at in something that does
+not freeze the javascript interpreter constantly while searching for "FAIL". 
+(This is quite a mess to inflict on yourself all in the name of proprietary
+monoculture, just saying.)
+
+Full relevant except:
+
+	2020-03-24T23:41:28.7154004Z     crypto:                                               [adjusted/master(unlocked) f647310] empty
+	2020-03-24T23:41:28.7485238Z adjust ok
+	2020-03-24T23:41:34.7685883Z gpg: can't connect to the agent: File name too long
+	2020-03-24T23:41:34.7687691Z gpg: error getting the KEK: No agent running
+	2020-03-24T23:41:34.7689073Z gpg: error reading '[stdin]': No agent running
+	2020-03-24T23:41:34.7690106Z gpg: import from '[stdin]' failed: No agent running
+	2020-03-24T23:41:34.7693591Z FAIL
+	2020-03-24T23:41:34.7695318Z       Exception: user error (gpg ["--batch","--no-tty","--use-agent","--quiet","--trust-model","always","--import","-q"] exited 2)
+
+Very odd that it omits any mention of what subtest failed. I have a feeling
+this log only contains stdout and not stderr, or something other weird is
+happening. Probably if that were not missing it would say "test harness
+self-test failed".
+
+gpg communicates with the agent over a unix socket. On linux, the path 
+to a socket is limited to 109 bytes. The test is being run in 
+"/home/runner/work/datalad-extensions/datalad-extensions/build/git-annex-8.20200309+git101-ga51a94f61"
+which is 100 bytes. Add ".t/gpgtest/" and the name of the socket, and it's too
+long.
+
+Quick fix is to cd to /tmp or something before running the test suite.
+""]]

diff --git a/doc/forum/WrongRequestBodyStreamSize_exporting_large_file_to_S3/comment_2_c9eff9a83ea5ee71cbe87022be9d0875._comment b/doc/forum/WrongRequestBodyStreamSize_exporting_large_file_to_S3/comment_2_c9eff9a83ea5ee71cbe87022be9d0875._comment
new file mode 100644
index 000000000..4c8ac4323
--- /dev/null
+++ b/doc/forum/WrongRequestBodyStreamSize_exporting_large_file_to_S3/comment_2_c9eff9a83ea5ee71cbe87022be9d0875._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="cbaines"
+ avatar="http://cdn.libravatar.org/avatar/1b15be83ec9e779dce940ce88cac603a"
+ subject="comment 2"
+ date="2020-03-25T22:40:12Z"
+ content="""
+Hi Joey,
+
+Sorry, missed your reply.
+
+I believe this is the size in bytes of the file I was trying to upload: 7850992066, and I'm not exactly sure what the partsize was, but I think it was 100MB.
+
+Thanks for looking in to this,
+
+Chris
+"""]]

diff --git a/doc/devblog/day_620__emergency_mode.mdwn b/doc/devblog/day_620__emergency_mode.mdwn
new file mode 100644
index 000000000..711ec5b76
--- /dev/null
+++ b/doc/devblog/day_620__emergency_mode.mdwn
@@ -0,0 +1,20 @@
+I'm only working on git-annex a day or two a week at present. Like
+everyone, dealing with the covid-19 crisis taking up a lot of my time.
+Some days I can't concentrate, some days I am dealing with basic needs,
+and other days I am rushing to develop other software targeted at this crisis.
+(See my [personal blog](https://joeyh.name/blog/).)
+
+I remotely attended the
+[MONII](https://www.mcgill.ca/neuro/channels/event/virtual-web-based-making-open-neuroscience-infrastructures-interoperable-30-303671)
+conference a week ago, with lots of researchers doing things with software
+related to git-annex, some in the health field, and something that struck
+me was a mention that it's important that scientists continue their work,
+even if it's not directly related to the crisis. All kinds of fields are
+going to be important in the time ahead beyond saving lives.
+
+So I am prioritizing anything scientists need to use git-annex, and
+anything those working on the crisis might need. If that's you and you need
+something, you can use the new "priority" tag on bugs and todos, and it
+will go right to the top of the [[design/roadmap]]. Do bear in mind that I
+have limited time/resources/attention right now, so only use it when you
+really need something urgently.

diff --git a/doc/design/roadmap.mdwn b/doc/design/roadmap.mdwn
index adc01aeeb..7b432aafa 100644
--- a/doc/design/roadmap.mdwn
+++ b/doc/design/roadmap.mdwn
@@ -13,7 +13,7 @@ belonging to those projects will be prioritized so do not generally need to
 be listed here.
 
 [[!inline pages="(todo/* and link(todo/priority) and !link(todo/done)) or
-                 (bugs/* and link(bugs/priority) and !link (bugs/done))"
+                 (bugs/* and link(bugs/priority) and !link(bugs/done))"
 		 template=buglist]]
 
 # confirmed

diff --git a/doc/bugs.mdwn b/doc/bugs.mdwn
index d9ae224fe..4b0f743f4 100644
--- a/doc/bugs.mdwn
+++ b/doc/bugs.mdwn
@@ -4,7 +4,8 @@ To mark a bug as closed add \[\[done\]\] to the end of the original bug descript
 
 [[!inline pages="./bugs/* and !./bugs/*/* and !./bugs/done and !link(done) 
 and !./bugs/moreinfo and !./bugs/confirmed and !./bugs/forwarded and !./bugs/duplicate
-and !*/Discussion" actions=yes postform=yes postformtext="Report a new bug titled:" show=0 archive=yes
+and !./bugs/priority and !*/Discussion"
+actions=yes postform=yes postformtext="Report a new bug titled:" show=0 archive=yes
 feedlimit=10 template=buglist]]
 
 [[!edittemplate template=templates/bugtemplate match="bugs/*" silent=yes]]
diff --git a/doc/bugs/priority.mdwn b/doc/bugs/priority.mdwn
new file mode 100644
index 000000000..c83fc829a
--- /dev/null
+++ b/doc/bugs/priority.mdwn
@@ -0,0 +1,14 @@
+This tag is for high priority bug reports.
+
+During the current crisis, please only add things that are either needed
+by scientists using git-annex (for any reason), or by organizations working
+on the crisis, or bugs that utterly break git-annex badly enough that it
+would be reasonable to assume such people will be impacted.
+
+Note that several [[projects]] use git-annex for science and items tagged
+belonging to those projects will be prioritized so do not generally need to
+be listed here.
+
+[[!inline pages="bugs/* and !bugs/*/* and !bugs/done and !link(bugs/done) 
+and link(bugs/priority) and !*/Discussion" show=0 feedlimit=10
+archive=yes template=buglist]]
diff --git a/doc/design/roadmap.mdwn b/doc/design/roadmap.mdwn
index f13ee3ccc..adc01aeeb 100644
--- a/doc/design/roadmap.mdwn
+++ b/doc/design/roadmap.mdwn
@@ -1,5 +1,22 @@
-git-annex is in a mode of continual user-driven improvement, involving numerous
-small issues and often easily implemented ideas.
+git-annex is in a mode of continual user-driven improvement, involving
+numerous small issues and often easily implemented ideas.
+
+# priority
+
+Here are high priority bugs and todo items, tagged with 'priority'.
+In the current crisis, please only add things that are either needed by
+scientists using git-annex (for any reason), or by organizations working on
+the crisis.
+
+Note that several [[projects]] use git-annex for science and items tagged
+belonging to those projects will be prioritized so do not generally need to
+be listed here.
+
+[[!inline pages="(todo/* and link(todo/priority) and !link(todo/done)) or
+                 (bugs/* and link(bugs/priority) and !link (bugs/done))"
+		 template=buglist]]
+
+# confirmed
 
 Here are open todo items that have been confirmed as worth doing and
 seem to have a design ready:
diff --git a/doc/todo.mdwn b/doc/todo.mdwn
index 2046d39d3..eeefd93f0 100644
--- a/doc/todo.mdwn
+++ b/doc/todo.mdwn
@@ -3,5 +3,7 @@ or tags: [[todo/confirmed]] [[todo/moreinfo]] [[todo/needsthought]] [[todo/unlik
 
 [[!inline pages="./todo/* and !./todo/*/* and !./todo/done and !link(done) 
 and !*/Discussion and !./todo/moreinfo and !./todo/confirmed
-and !./todo/needsthought and !./todo/unlikely" actions=yes postform=yes postformtext="Add a new todo titled:"
+and !./todo/needsthought and !./todo/unlikely
+and !./todo/priority" 
+actions=yes postform=yes postformtext="Add a new todo titled:"
 show=0 feedlimit=10 archive=yes template=buglist]]
diff --git a/doc/todo/priority.mdwn b/doc/todo/priority.mdwn
new file mode 100644
index 000000000..aec1c2b61
--- /dev/null
+++ b/doc/todo/priority.mdwn
@@ -0,0 +1,13 @@
+This tag is for high priority todo items.
+
+During the current crisis, please only add things that are either needed
+by scientists using git-annex (for any reason), or by organizations working
+on the crisis.
+
+Note that several [[projects]] use git-annex for science and items tagged
+belonging to those projects will be prioritized so do not generally need to
+be listed here.
+
+[[!inline pages="todo/* and !todo/*/* and !todo/done and !link(todo/done) 
+and link(todo/priority) and !*/Discussion" show=0 feedlimit=10
+archive=yes template=buglist]]

diff --git a/doc/todo/git-annex_find_--batch_will_not_accept_absolute_paths/comment_2_fb15c2a1ae1c38ece951cc5e0d07f3db._comment b/doc/todo/git-annex_find_--batch_will_not_accept_absolute_paths/comment_2_fb15c2a1ae1c38ece951cc5e0d07f3db._comment
new file mode 100644
index 000000000..e3ec903ec
--- /dev/null
+++ b/doc/todo/git-annex_find_--batch_will_not_accept_absolute_paths/comment_2_fb15c2a1ae1c38ece951cc5e0d07f3db._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="spwhitton"
+ avatar="http://cdn.libravatar.org/avatar/9c3f08f80e67733fd506c353239569eb"
+ subject="comment 2"
+ date="2020-03-25T16:31:13Z"
+ content="""
+Hello Joey,
+
+I was passing `--unlocked` only.
+
+Version 8.20200226 installed from buster-backports.
+
+Thanks!
+"""]]

diff --git a/doc/bugs/tests_fail___40__gpg-agent_related__63____41___when_running_build_inside_singularity_container.mdwn b/doc/bugs/tests_fail___40__gpg-agent_related__63____41___when_running_build_inside_singularity_container.mdwn
new file mode 100644
index 000000000..1f735ab0b
--- /dev/null
+++ b/doc/bugs/tests_fail___40__gpg-agent_related__63____41___when_running_build_inside_singularity_container.mdwn
@@ -0,0 +1,43 @@
+### Please describe the problem.
+
+I am trying to setup a cron job on github actions to daily test datalad against bleeding edge git-annex. All the few commands I am using are all in the workflow file: https://github.com/datalad/datalad-extensions/pull/7/files#diff-8364c688b76bfaf5df947cfd4d74eef7R42
+
+To build git-annex I am using a singularity container (based on buster with all build-dependencies installed).
+While building a binary standalone package (from first prepared .dsc) 3 tests fail:
+
+`3 out of 260 tests failed (195.33s)`
+
+- [web view of the logs](https://github.com/datalad/datalad-extensions/pull/7/checks?check_run_id=532056262)
+- [and here they are all in raw form (probably would expire soon)](https://pipelines.actions.githubusercontent.com/2UPlDxaVvvbkeFX4btxWorCjpJvj40zvWY5ogH2yZibhOMcU7O/_apis/pipelines/1/runs/182/signedlogcontent/3?urlExpires=2020-03-24T23%3A51%3A03.1656651Z&urlSigningMethod=HMACV1&urlSignature=zmkF8NBdaLU3pAOT3WJ2C6R81sZjH4%2Bka2QiVynkEkU%3D) 
+
+outside the container system is some ubuntu -- inside debian stable (buster).  singularity bind mounts HOME, /tmp and passes all environment variables inside the container.
+
+if you search for `Z FAIL` you would find the hit
+[[!format sh """
+2020-03-24T23:41:28.7154039Z     crypto:                                               [adjusted/master(unlocked) f647310] empty
+2020-03-24T23:41:28.7485256Z adjust ok
+2020-03-24T23:41:34.7685919Z gpg: can't connect to the agent: File name too long
+2020-03-24T23:41:34.7687700Z gpg: error getting the KEK: No agent running
+2020-03-24T23:41:34.7689081Z gpg: error reading '[stdin]': No agent running
+2020-03-24T23:41:34.7690114Z gpg: import from '[stdin]' failed: No agent running
+2020-03-24T23:41:34.7693611Z FAIL
+"""]]
+
+I wonder if it relates to the discrepancy of gpg-agent running outside of the container and gpg inside the container, which I have detected when saw
+
+[[!format sh """
+2020-03-24T23:34:08.8873100Z gpg: WARNING: server 'gpg-agent' is older than us (2.2.4 < 2.2.12)
+2020-03-24T23:34:08.8873946Z gpg: Note: Outdated servers may lack important security fixes.
+2020-03-24T23:34:08.8875072Z gpg: Note: Use the command "gpgconf --kill all" to restart them.
+2020-03-24T23:34:08.9223394Z  signfile git-annex_8.20200309+git101-ga51a94f61-1~ndall+1_source.buildinfo
+"""]]
+
+in the beginning of the run, or may be just the fact that inside the container it shouldn't use `gpg-agent`...
+I wonder if there is an easy way to disable tests which would rely on having connection to gpg-agent?
+
+FWIW,
+- similarish and [then mitigated situation happened awhile back](https://git-annex.branchable.com/bugs/7.20181211+git29-gab4a1bed9_fails_tests_during_neurodebian_build/)
+- the same version package builds fine using our conventional neurodebian build setup using cowbuilder (no singularity)
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]

diff --git a/doc/bugs/add_--force-small_fails_on_modified_submodules.mdwn b/doc/bugs/add_--force-small_fails_on_modified_submodules.mdwn
new file mode 100644
index 000000000..95184491f
--- /dev/null
+++ b/doc/bugs/add_--force-small_fails_on_modified_submodules.mdwn
@@ -0,0 +1,127 @@
+Passing a modified submodule to `git annex --force-small` triggers a
+failure:
+
+[[!format sh """
+cd "$(mktemp -d --tmpdir gx-XXXXXXX)"
+git init
+git annex init
+git init sub
+git -C sub commit --allow-empty -m"c0"
+git submodule add ./sub
+
+git -C sub commit --allow-empty -m"c1"
+git commit -m'sub change'
+git annex add --force-small sub
+"""]]
+
+```
+[...]
+add sub (adding content to git repository) fatal: Unable to add (null) to database
+fatal: Unable to add (null) to database
+fatal: Unable to add (null) to database
+fatal: Unable to add (null) to database
+fatal: Unable to add (null) to database
+fatal: Unable to add (null) to database
+fatal: Unable to add (null) to database
+fatal: Unable to add (null) to database
+fatal: Unable to add (null) to database
+fatal: Unable to add (null) to database
+fatal: Unable to add (null) to database
+
+git-annex: fd:18: hGetLine: end of file
+failed
+git-annex: user error (git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","hash-object","-w","--stdin-paths","--no-filters"] exited 128)
+```
+
+The demo above passes a submodule to `annex add`, but the more
+realistic scenario would be passing a directory (most likely ".") that
+happens to include a modified submodule.
+
+The failure is happening when `addSmallOverridden` calls `hash-object`
+with the submodule path.  As far as I can see, `addSmallOverridden`
+will only receive a directory if the path in question is a submodule
+(based on ls-files not traversing into submodules).  So, perhaps an
+appropriate fix is to go through `addFile` rather
+`hash-object/update-index` when the file is a directory.  I've
+included a patch to do that below.  The first patch is for an issue in
+`addSmallOverridden` that I noticed when making the change.
+
+[[!format patch """
+From 58b5a1acf7dfe305b9284cf3423a58853c13451a Mon Sep 17 00:00:00 2001
+From: Kyle Meyer <kyle@kyleam.com>
+Date: Mon, 23 Mar 2020 15:45:15 -0400
+Subject: [PATCH 1/2] add --force-small: Don't dereference link when checking
+ file status
+
+addSmallOverridden calls getFileStatus and then checks the result with
+isSymbolicLink.  getFileStatus dereferences symbolic links, so
+isSymbolicLink will always return false (assuming the getFileStatus
+call doesn't fail on a broken link).  Use getSymbolicLinkStatus
+instead.
+---
+ Command/Add.hs | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/Command/Add.hs b/Command/Add.hs
+index e142aac0b..56e6fb236 100644
+--- a/Command/Add.hs
++++ b/Command/Add.hs
+@@ -107,7 +107,7 @@ addSmallOverridden :: RawFilePath -> Annex Bool
+ addSmallOverridden file = do
+ 	showNote "adding content to git repository"
+ 	let file' = fromRawFilePath file
+-	s <- liftIO $ getFileStatus file'
++	s <- liftIO $ getSymbolicLinkStatus file'
+ 	if isSymbolicLink s
+ 		then addFile file 
+ 		else do
+-- 
+2.25.1
+
+"""]]
+
+[[!format patch """
+From c823d69a7b477f770fe539a74b788b61df173a76 Mon Sep 17 00:00:00 2001
+From: Kyle Meyer <kyle@kyleam.com>
+Date: Mon, 23 Mar 2020 15:45:15 -0400
+Subject: [PATCH 2/2] add --force-small: Send all non-regular files through
+ addFile
+
+Running `git annex add --force-small` on a modified submodule fails
+when the submodule path is fed to hash-object.  This failure is
+unlikely to be triggered by a caller passing a submodule explicitly to
+`git annex add` because there's nothing useful that annex-add can do
+with a submodule.  A more likely scenario for hitting this failure is
+that the caller passes "." or a subdirectory to `annex-add` while a
+submodule underneath the specified path happens to be modified.
+
+addSmallOverridden already routes symbolic links through addFile
+rather than using the custom hash-object/update-index call.  The
+latter is valid only for regular files, so extend this condition so
+that everything that isn't a regular file goes through addFile.  Doing
+so avoids the above error because submodules come in as directories.
+---
+ Command/Add.hs | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/Command/Add.hs b/Command/Add.hs
+index 56e6fb236..72aae5f3c 100644
+--- a/Command/Add.hs
++++ b/Command/Add.hs
+@@ -108,7 +108,7 @@ addSmallOverridden file = do
+ 	showNote "adding content to git repository"
+ 	let file' = fromRawFilePath file
+ 	s <- liftIO $ getSymbolicLinkStatus file'
+-	if isSymbolicLink s
++	if not (isRegularFile s)
+ 		then addFile file 
+ 		else do
+ 			-- Can't use addFile because the clean filter will
+-- 
+2.25.1
+
+"""]]
+
+[[!meta author=kyle]]
+[[!tag projects/datalad]]
+

diff --git a/doc/forum/Git_annex_drop/comment_1_541399d5fff0db0627c786f5e056fabb._comment b/doc/forum/Git_annex_drop/comment_1_541399d5fff0db0627c786f5e056fabb._comment
new file mode 100644
index 000000000..329d004f7
--- /dev/null
+++ b/doc/forum/Git_annex_drop/comment_1_541399d5fff0db0627c786f5e056fabb._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="ps"
+ avatar="http://cdn.libravatar.org/avatar/d492f87525ce24bc22ff1348d0c60b0d"
+ subject="Solved"
+ date="2020-03-23T19:07:53Z"
+ content="""
+It had to do with dotfiles. The files I was trying to keep track of were in a dot directory, and hence git annex didn't include it in the annex (and hence couldn't drop them).
+"""]]

diff --git a/doc/forum/Git_annex_drop.mdwn b/doc/forum/Git_annex_drop.mdwn
index 2db8bc0e5..6f082770d 100644
--- a/doc/forum/Git_annex_drop.mdwn
+++ b/doc/forum/Git_annex_drop.mdwn
@@ -1,2 +1,4 @@
 Hi,
 I am trying to use git annex to store some of the files on my laptop on an external drive. However, after running `git annex sync --content` on both repositories and _then_ trying to run `git annex drop <file>` doesn't free up any space on the local laptop repository (in fact it doesn't give any terminal output). Can anyone point me in a direction to solve this?
+
+Edit. Wth? Even `git annex drop --force` doesn't work. Is there some obvious thing I'm missing?

diff --git a/doc/forum/Git_annex_drop.mdwn b/doc/forum/Git_annex_drop.mdwn
index 642dc7a04..2db8bc0e5 100644
--- a/doc/forum/Git_annex_drop.mdwn
+++ b/doc/forum/Git_annex_drop.mdwn
@@ -1,2 +1,2 @@
 Hi,
-I am trying to use git annex to store some of the files on my laptop on an external drive. However, after running `git annex sync --content` on both repositories and _then_ trying to run `git annex drop <file>` doesn't free up any space on the local laptop repository. Can anyone point me in a direction to solve this?
+I am trying to use git annex to store some of the files on my laptop on an external drive. However, after running `git annex sync --content` on both repositories and _then_ trying to run `git annex drop <file>` doesn't free up any space on the local laptop repository (in fact it doesn't give any terminal output). Can anyone point me in a direction to solve this?

diff --git a/doc/forum/Git_annex_drop.mdwn b/doc/forum/Git_annex_drop.mdwn
new file mode 100644
index 000000000..642dc7a04
--- /dev/null
+++ b/doc/forum/Git_annex_drop.mdwn
@@ -0,0 +1,2 @@
+Hi,
+I am trying to use git annex to store some of the files on my laptop on an external drive. However, after running `git annex sync --content` on both repositories and _then_ trying to run `git annex drop <file>` doesn't free up any space on the local laptop repository. Can anyone point me in a direction to solve this?

diff --git a/doc/forum/Git-annex_fsck_backend_warning/comment_3_300bbfdd90d18619e88310de5a128ef0._comment b/doc/forum/Git-annex_fsck_backend_warning/comment_3_300bbfdd90d18619e88310de5a128ef0._comment
new file mode 100644
index 000000000..d1e1d0b88
--- /dev/null
+++ b/doc/forum/Git-annex_fsck_backend_warning/comment_3_300bbfdd90d18619e88310de5a128ef0._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="kyle"
+ avatar="http://cdn.libravatar.org/avatar/7d6e85cde1422ad60607c87fa87c63f3"
+ subject="comment 3"
+ date="2020-03-20T17:34:03Z"
+ content="""
+Thanks for the quick fix!
+"""]]

diff --git a/Backend/Hash.hs b/Backend/Hash.hs
index 1da11240a..9ac00f8cd 100644
--- a/Backend/Hash.hs
+++ b/Backend/Hash.hs
@@ -157,7 +157,8 @@ keyHash = fst . splitKeyNameExtension
 validInExtension :: Word8 -> Bool
 validInExtension c
 	| isAlphaNum (chr (fromIntegral c)) = True
-	| c <= 127 = False -- other ascii, spaces, punctuation, control chars
+	| fromIntegral c == ord '.' = True
+	| c <= 127 = False -- other ascii: spaces, punctuation, control chars
 	| otherwise = True -- utf8 is allowed, also other encodings
 
 {- Upgrade keys that have the \ prefix on their hash due to a bug, or
diff --git a/CHANGELOG b/CHANGELOG
index e08a365d0..eee9244a7 100644
--- a/CHANGELOG
+++ b/CHANGELOG
@@ -2,6 +2,8 @@ git-annex (8.20200310) UNRELEASED; urgency=medium
 
   * webdav: Made exporttree remotes faster by caching connection to the
     server.
+  * fsck: Fix reversion in 8.20200226 that made it incorrectly warn
+    that hashed keys with an extension should be upgraded.
   * Fix a minor bug that caused options provided with -c to be passed
     multiple times to git.
 
diff --git a/doc/forum/Git-annex_fsck_backend_warning/comment_2_a5415299d07283f393319b37ba9335ff._comment b/doc/forum/Git-annex_fsck_backend_warning/comment_2_a5415299d07283f393319b37ba9335ff._comment
new file mode 100644
index 000000000..e290e7183
--- /dev/null
+++ b/doc/forum/Git-annex_fsck_backend_warning/comment_2_a5415299d07283f393319b37ba9335ff._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2020-03-20T16:55:44Z"
+ content="""
+Fixed in git just now.
+"""]]

diff --git a/Assistant/WebApp/Configurators/WebDAV.hs b/Assistant/WebApp/Configurators/WebDAV.hs
index 0dc778b86..d89ad8c02 100644
--- a/Assistant/WebApp/Configurators/WebDAV.hs
+++ b/Assistant/WebApp/Configurators/WebDAV.hs
@@ -15,7 +15,7 @@ import Creds
 import qualified Remote.WebDAV as WebDAV
 import Assistant.WebApp.MakeRemote
 import qualified Remote
-import Types.Remote (RemoteConfig)
+import Types.Remote (RemoteConfig, config)
 import Types.StandardGroups
 import Logs.Remote
 import Git.Types (RemoteName)
@@ -89,16 +89,16 @@ postEnableWebDAVR _ = giveup "WebDAV not supported by this build"
 
 #ifdef WITH_WEBDAV
 makeWebDavRemote :: SpecialRemoteMaker -> RemoteName -> CredPair -> RemoteConfig -> Handler ()
-makeWebDavRemote maker name creds config = 
+makeWebDavRemote maker name creds c = 
 	setupCloudRemote TransferGroup Nothing $
-		maker name WebDAV.remote (Just creds) config
+		maker name WebDAV.remote (Just creds) c
 
 {- Only returns creds previously used for the same hostname. -}
 previouslyUsedWebDAVCreds :: String -> Annex (Maybe CredPair)
 previouslyUsedWebDAVCreds hostname =
 	previouslyUsedCredPair WebDAV.davCreds WebDAV.remote samehost
   where
-	samehost url = case urlHost =<< WebDAV.configUrl url of
+	samehost r = case urlHost =<< WebDAV.configUrl (config r) of
 		Nothing -> False
 		Just h -> h == hostname
 #endif
diff --git a/CHANGELOG b/CHANGELOG
index de59f8972..e08a365d0 100644
--- a/CHANGELOG
+++ b/CHANGELOG
@@ -1,5 +1,7 @@
 git-annex (8.20200310) UNRELEASED; urgency=medium
 
+  * webdav: Made exporttree remotes faster by caching connection to the
+    server.
   * Fix a minor bug that caused options provided with -c to be passed
     multiple times to git.
 
diff --git a/Remote/WebDAV.hs b/Remote/WebDAV.hs
index 5cfb3558f..59b843d6f 100644
--- a/Remote/WebDAV.hs
+++ b/Remote/WebDAV.hs
@@ -22,6 +22,7 @@ import System.IO.Error
 import Control.Monad.Catch
 import Control.Monad.IO.Class (MonadIO)
 import System.Log.Logger (debugM)
+import Control.Concurrent.STM hiding (check)
 
 import Annex.Common
 import Types.Remote
@@ -64,15 +65,18 @@ davcredsField :: RemoteConfigField
 davcredsField = Accepted "davcreds"
 
 gen :: Git.Repo -> UUID -> RemoteConfig -> RemoteGitConfig -> RemoteStateHandle -> Annex (Maybe Remote)
-gen r u rc gc rs = new
-	<$> parsedRemoteConfig remote rc
-	<*> remoteCost gc expensiveRemoteCost
+gen r u rc gc rs = do
+	c <- parsedRemoteConfig remote rc
+	new
+		<$> pure c
+		<*> remoteCost gc expensiveRemoteCost
+		<*> mkDavHandleVar c gc u
   where
-	new c cst = Just $ specialRemote c
-		(prepareDAV this $ store chunkconfig)
-		(prepareDAV this $ retrieve chunkconfig)
-		(prepareDAV this $ remove)
-		(prepareDAV this $ checkKey this chunkconfig)
+	new c cst hdl = Just $ specialRemote c
+		(simplyPrepare $ store hdl chunkconfig)
+		(simplyPrepare $ retrieve hdl chunkconfig)
+		(simplyPrepare $ remove hdl)
+		(simplyPrepare $ checkKey hdl this chunkconfig)
 		this
 	  where
 		this = Remote
@@ -90,13 +94,13 @@ gen r u rc gc rs = new
 			, checkPresent = checkPresentDummy
 			, checkPresentCheap = False
 			, exportActions = ExportActions
-				{ storeExport = storeExportDav this
-				, retrieveExport = retrieveExportDav this
-				, checkPresentExport = checkPresentExportDav this
-				, removeExport = removeExportDav this
+				{ storeExport = storeExportDav hdl
+				, retrieveExport = retrieveExportDav hdl
+				, checkPresentExport = checkPresentExportDav hdl this
+				, removeExport = removeExportDav hdl
 				, removeExportDirectory = Just $
-					removeExportDirectoryDav this
-				, renameExport = renameExportDav this
+					removeExportDirectoryDav hdl
+				, renameExport = renameExportDav hdl
 				}
 			, importActions = importUnsupported
 			, whereisKey = Nothing
@@ -133,18 +137,20 @@ webdavSetup _ mu mcreds c gc = do
 	c'' <- setRemoteCredPair encsetup c' gc (davCreds u) creds
 	return (c'', u)
 
-prepareDAV :: Remote -> (Maybe DavHandle -> helper) -> Preparer helper
-prepareDAV = resourcePrepare . const . withDAVHandle
-
-store :: ChunkConfig -> Maybe DavHandle -> Storer
-store _ Nothing = byteStorer $ \_k _b _p -> return False
-store (LegacyChunks chunksize) (Just dav) = fileStorer $ \k f p -> liftIO $
-	withMeteredFile f p $ storeLegacyChunked chunksize k dav
-store _  (Just dav) = httpStorer $ \k reqbody -> liftIO $ goDAV dav $ do
-	let tmp = keyTmpLocation k
-	let dest = keyLocation k
-	storeHelper dav tmp dest reqbody
-	return True
+store :: DavHandleVar -> ChunkConfig -> Storer
+store hv (LegacyChunks chunksize) = fileStorer $ \k f p -> 
+	withDavHandle hv $ \case
+		Nothing -> return False
+		Just dav -> liftIO $
+			withMeteredFile f p $ storeLegacyChunked chunksize k dav
+store hv _ = httpStorer $ \k reqbody -> 
+	withDavHandle hv $ \case
+		Nothing -> return False
+		Just dav -> liftIO $ goDAV dav $ do
+			let tmp = keyTmpLocation k
+			let dest = keyLocation k
+			storeHelper dav tmp dest reqbody
+			return True
 
 storeHelper :: DavHandle -> DavLocation -> DavLocation -> RequestBody -> DAVT IO ()
 storeHelper dav tmp dest reqbody = do
@@ -164,11 +170,14 @@ finalizeStore dav tmp dest = do
 retrieveCheap :: Key -> AssociatedFile -> FilePath -> Annex Bool
 retrieveCheap _ _ _ = return False
 
-retrieve :: ChunkConfig -> Maybe DavHandle -> Retriever
-retrieve _ Nothing = giveup "unable to connect"
-retrieve (LegacyChunks _) (Just dav) = retrieveLegacyChunked dav
-retrieve _ (Just dav) = fileRetriever $ \d k p -> liftIO $
-	goDAV dav $ retrieveHelper (keyLocation k) d p
+retrieve :: DavHandleVar -> ChunkConfig -> Retriever
+retrieve hv cc = fileRetriever $ \d k p ->
+	withDavHandle hv $ \case
+		Nothing -> giveup "unable to connect"
+		Just dav -> case cc of
+			LegacyChunks _ -> retrieveLegacyChunked d k p dav
+			_ -> liftIO $
+				goDAV dav $ retrieveHelper (keyLocation k) d p
 
 retrieveHelper :: DavLocation -> FilePath -> MeterUpdate -> DAVT IO ()
 retrieveHelper loc d p = do
@@ -176,12 +185,13 @@ retrieveHelper loc d p = do
 	inLocation loc $
 		withContentM $ httpBodyRetriever d p
 
-remove :: Maybe DavHandle -> Remover
-remove Nothing _ = return False
-remove (Just dav) k = liftIO $ goDAV dav $
-	-- Delete the key's whole directory, including any
-	-- legacy chunked files, etc, in a single action.
-	removeHelper (keyDir k)
+remove :: DavHandleVar -> Remover
+remove hv k = withDavHandle hv $ \case
+	Nothing -> return False
+	Just dav -> liftIO $ goDAV dav $
+		-- Delete the key's whole directory, including any
+		-- legacy chunked files, etc, in a single action.
+		removeHelper (keyDir k)
 
 removeHelper :: DavLocation -> DAVT IO Bool
 removeHelper d = do
@@ -195,20 +205,21 @@ removeHelper d = do
 				Right False -> return True
 				_ -> return False
 
-checkKey :: Remote -> ChunkConfig -> Maybe DavHandle -> CheckPresent
-checkKey r _ Nothing _ = giveup $ name r ++ " not configured"
-checkKey r chunkconfig (Just dav) k = do
-	showChecking r
-	case chunkconfig of
-		LegacyChunks _ -> checkKeyLegacyChunked dav k
-		_ -> do
-			v <- liftIO $ goDAV dav $
-				existsDAV (keyLocation k)
-			either giveup return v
-
-storeExportDav :: Remote -> FilePath -> Key -> ExportLocation -> MeterUpdate -> Annex Bool
-storeExportDav r f k loc p = case exportLocation loc of
-	Right dest -> withDAVHandle r $ \mh -> runExport mh $ \dav -> do
+checkKey :: DavHandleVar -> Remote -> ChunkConfig -> CheckPresent
+checkKey hv r chunkconfig k = withDavHandle hv $ \case
+	Nothing -> giveup $ name r ++ " not configured"
+	Just dav -> do
+		showChecking r

(Diff truncated)

diff --git a/doc/forum/Git-annex_fsck_backend_warning/comment_1_a504439397db6661788d916cb7c96da1._comment b/doc/forum/Git-annex_fsck_backend_warning/comment_1_a504439397db6661788d916cb7c96da1._comment
new file mode 100644
index 000000000..3b2c56eb9
--- /dev/null
+++ b/doc/forum/Git-annex_fsck_backend_warning/comment_1_a504439397db6661788d916cb7c96da1._comment
@@ -0,0 +1,30 @@
+[[!comment format=mdwn
+ username="kyle"
+ avatar="http://cdn.libravatar.org/avatar/7d6e85cde1422ad60607c87fa87c63f3"
+ subject="comment: introduced by 09df58c4e"
+ date="2020-03-20T16:20:05Z"
+ content="""
+I see these false positive warnings too.  This is enough to trigger
+the issue on my end:
+
+[[!format sh \"\"\"
+cd \"$(mktemp -d --tmpdir gx-XXXXXXX)\"
+git init
+git annex init
+>foo.txt
+git annex add foo.txt
+git annex fsck foo.txt
+\"\"\"]]
+
+```
+[...]
+fsck foo.txt (checksum...) 
+  foo.txt: Can be upgraded to an improved key format. You can do so by running: git annex migrate --backend=SHA256E foo.txt
+ok
+```
+
+The presence of the warning bisects to 09df58c4e (handle keys with
+extensions consistently in all locales, 2020-02-20), which was a part
+of the 8.20200226 release.
+
+"""]]

diff --git a/doc/bugs/webdav_export_slow__44___does_not_reuse_connections.mdwn b/doc/bugs/webdav_export_slow__44___does_not_reuse_connections.mdwn
index 2212bcaae..fd2f152f7 100644
--- a/doc/bugs/webdav_export_slow__44___does_not_reuse_connections.mdwn
+++ b/doc/bugs/webdav_export_slow__44___does_not_reuse_connections.mdwn
@@ -9,3 +9,5 @@ Could http connections be reused?
 Could multiple files be uploaded in parallel?
 
 Apparently files are also upload to a temporary location and renamed after successful upload. This adds additional latency and thus parallel uploads could provide a speed up?
+
+[[!tag confirmed]]
diff --git a/doc/bugs/webdav_export_slow__44___does_not_reuse_connections/comment_1_878309c705dd9ff06c89b9559b54bd40._comment b/doc/bugs/webdav_export_slow__44___does_not_reuse_connections/comment_1_878309c705dd9ff06c89b9559b54bd40._comment
new file mode 100644
index 000000000..14cbeb90a
--- /dev/null
+++ b/doc/bugs/webdav_export_slow__44___does_not_reuse_connections/comment_1_878309c705dd9ff06c89b9559b54bd40._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2020-03-20T15:48:35Z"
+ content="""
+Indeed, regular webdav special remote uses prepareDav
+which sets up a single DAV context that is used for all stores,
+but export does not and so creates a new context each time.
+
+S3 gets around this using an MVar that contains the S3 handle.
+Webdav should be able to do the same.
+
+(The upload to a temp location is necessary, otherwise resuming an
+interrupted upload would not be able to check which files had been fully
+uploaded yet in some situations. Or something like that. I forget the exact
+circumstances, but it's documented in a comment where storeExport is defined
+in Types.Remote.)
+
+(Opened [[todo/support_concurrency_for_export]].)
+"""]]
diff --git a/doc/todo/support_concurrency_for_export.mdwn b/doc/todo/support_concurrency_for_export.mdwn
new file mode 100644
index 000000000..daac15485
--- /dev/null
+++ b/doc/todo/support_concurrency_for_export.mdwn
@@ -0,0 +1,2 @@
+Making git-annex export support -J should be doable and could speed up
+exports a lot with some remotes. --[[Joey]]

diff --git a/doc/forum/Git-annex_fsck_backend_warning.mdwn b/doc/forum/Git-annex_fsck_backend_warning.mdwn
new file mode 100644
index 000000000..ca17307f1
--- /dev/null
+++ b/doc/forum/Git-annex_fsck_backend_warning.mdwn
@@ -0,0 +1,42 @@
+Since a week or two, git-annex fsck gives a warning that my files (all of them) can be upgraded to an improved key format (SHA256E). However, I use the SHA256E key format as long as I remember and running the proposed command doesn't remove the warning for the next git-annex fsck:
+
+```
+% git-annex fsck documenten/foto_maarten.jpg                     
+fsck documenten/foto_maarten.jpg (checksum...) 
+  documenten/foto_maarten.jpg: Can be upgraded to an improved key format. You can do so by running: git annex migrate --backend=SHA256E documenten/foto_maarten.jpg
+ok
+(recording state in git...)
+
+% git-annex info documenten/foto_maarten.jpg
+file: documenten/foto_maarten.jpg
+size: 349.34 kilobytes
+key: SHA256E-s349336--c0535bad49d6c58c722b941ea020ea1f3ce2aae74c2570c14bfe920ea2171f36.jpg
+present: true
+
+% git annex migrate --backend=SHA256E documenten/foto_maarten.jpg
+migrate documenten/foto_maarten.jpg (checksum...) (checksum...) ok
+(recording state in git...)
+
+% git-annex fsck documenten/foto_maarten.jpg                     
+fsck documenten/foto_maarten.jpg (checksum...) 
+  documenten/foto_maarten.jpg: Can be upgraded to an improved key format. You can do so by running: git annex migrate --backend=SHA256E documenten/foto_maarten.jpg
+ok
+(recording state in git...)
+```
+
+I'm using git-annex as provided with Debian testing. Currently, that's
+
+```
+% git-annex version  
+git-annex version: 8.20200226
+build flags: Assistant Webapp Pairing S3 WebDAV Inotify DBus DesktopNotify TorrentParser MagicMime Feeds Testsuite
+dependency versions: aws-0.20 bloomfilter-2.0.1.0 cryptonite-0.25 DAV-1.3.3 feed-1.0.1.0 ghc-8.6.5 http-client-0.5.14 persistent-sqlite-2.9.3 torrent-10000.1.1 uuid-1.3.13 yesod-1.6.0
+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 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs hook external
+operating system: linux x86_64
+supported repository versions: 8
+upgrade supported from repository versions: 0 1 2 3 4 5 6 7
+local repository version: 8
+```
+
+Any idea what's going on here and how to solve it? I couldn't find anything so far.

diff --git a/doc/todo/more_efficient_resolution_of_trivial_export_conflicts/comment_1_5a2d7ea060f5e1be11c39521c0a5631d._comment b/doc/todo/more_efficient_resolution_of_trivial_export_conflicts/comment_1_5a2d7ea060f5e1be11c39521c0a5631d._comment
new file mode 100644
index 000000000..2db042e03
--- /dev/null
+++ b/doc/todo/more_efficient_resolution_of_trivial_export_conflicts/comment_1_5a2d7ea060f5e1be11c39521c0a5631d._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="thk"
+ avatar="http://cdn.libravatar.org/avatar/bfef10a428769701aeee1db978951461"
+ subject="sponsoring?"
+ date="2020-03-19T08:40:31Z"
+ content="""
+I am running into this problem right now. I exported a movie collection from laptop A and then a huge collection of photos from laptop B to an USB drive. Both exports ran many hours.
+Now when I want to export the next collection of files, I see:
+
+> git annex export master --to usb-sg2
+>
+>  Resolving export conflict..
+>
+> unexport usb-sg2 path/to/some/picture/file.jpg ok
+
+Do you already have a solution for this in mind? Could I speed up the implementation with sponsorship? This is a hard blocker now for me in my consolidation of our data with git-annex. I would rather not spend many nights to keep exporting and unexporting the same files over and over.
+
+Maybe I could hack this as a temporary workaround by manually changing the exported trees in the exports.log file? The \"conflicting\" exports are in two separate sub-trees.
+"""]]

diff --git a/doc/bugs/Sync_of_adjusted_branch_does_not_propagate_changed_submodule_commit.mdwn b/doc/bugs/Sync_of_adjusted_branch_does_not_propagate_changed_submodule_commit.mdwn
new file mode 100644
index 000000000..3a1aae1fc
--- /dev/null
+++ b/doc/bugs/Sync_of_adjusted_branch_does_not_propagate_changed_submodule_commit.mdwn
@@ -0,0 +1,93 @@
+When on an adjusted branch, `git annex sync` will sync the submodule
+commit for the initial addition of a submodule, but it doesn't seem to
+sync changes in the recorded commit.  Here's a demo of the issue based
+off of Michael's script at [DataLad's issue 4292][0].
+
+[[!format sh """
+cd "$(mktemp -d --tmpdir gx-sync-demo-XXXXXXX)"
+
+git init
+git annex init
+git commit --allow-empty -mc0
+git annex adjust --unlock
+
+git init sub
+git -C sub commit --allow-empty -mc0
+git submodule add ./sub
+git commit -m'add sub'
+# A new submodule is sync'd.
+git annex sync --no-commit --no-push --no-pull --no-content
+
+git -C sub commit --allow-empty -mc1
+git add sub
+git commit -m'sub update'
+
+# A change in the submodule ID is not.
+git annex sync --no-commit --no-push --no-pull --no-content
+git diff master..
+"""]]
+
+With a git-annex built from 8.20200309-62-gc8fec6ab0, the submodule
+remains modified between `master` and `adjusted/master(unlocked))`.
+
+```
+diff --git a/sub b/sub
+index ed67764..a27fd83 160000
+--- a/sub
++++ b/sub
+@@ -1 +1 @@
+-Subproject commit ed6776462d0842bf0a317d2e3ee1983572a217ff
++Subproject commit a27fd837958466ba4fb751a3de139c03548be1ad
+```
+
+I was able to resolve the issue (i.e. the above demo outputs an empty
+diff) with the patch below, though that might of course be the
+completely wrong way to fix this.
+
+Thanks in advance for looking into this issue.
+
+[[!format patch """
+From fa3a4be5497300b9b39e121008b474e9dd405fd3 Mon Sep 17 00:00:00 2001
+From: Kyle Meyer <kyle@kyleam.com>
+Date: Tue, 17 Mar 2020 22:16:06 -0400
+Subject: [PATCH] adjust: Propagate submodule changes back to original branch
+
+When the recorded submodule commit changes on an adjusted branch, the
+change is carried in the function that reverseAdjustedCommit passes
+for adjustTree's adjusttreeitem parameter.  Update the CommitObject
+handling in adjustTree to consider adjusttreeitem so that a submodule
+change is synced back.
+---
+ Git/Tree.hs | 8 ++++++--
+ 1 file changed, 6 insertions(+), 2 deletions(-)
+
+diff --git a/Git/Tree.hs b/Git/Tree.hs
+index da05a3fa5..9627ae969 100644
+--- a/Git/Tree.hs
++++ b/Git/Tree.hs
+@@ -237,8 +237,12 @@ adjustTree adjusttreeitem addtreeitems resolveaddconflict removefiles r repo =
+ 				let !modified' = modified || slmodified || wasmodified
+ 				go h modified' (subtree : c) depth intree is'
+ 			Just CommitObject -> do
+-				let ti = TreeCommit (LsTree.file i) (LsTree.mode i) (LsTree.sha i)
+-				go h wasmodified (ti:c) depth intree is
++				let ti = TreeItem (LsTree.file i) (LsTree.mode i) (LsTree.sha i)
++				v <- adjusttreeitem ti
++				let commit = tc $ fromMaybe ti v
++				go h wasmodified (commit:c) depth intree is
++				where
++					tc (TreeItem f m s) = TreeCommit f m s
+ 			_ -> error ("unexpected object type \"" ++ decodeBS (LsTree.typeobj i) ++ "\"")
+ 		| otherwise = return (c, wasmodified, i:is)
+ 
+-- 
+2.25.1
+
+"""]]
+
+
+[0]: https://github.com/datalad/datalad/issues/4292
+
+[[!meta author=kyle]]
+[[!tag projects/datalad]]
+

diff --git a/doc/bugs/webdav_export_slow__44___does_not_reuse_connections.mdwn b/doc/bugs/webdav_export_slow__44___does_not_reuse_connections.mdwn
new file mode 100644
index 000000000..2212bcaae
--- /dev/null
+++ b/doc/bugs/webdav_export_slow__44___does_not_reuse_connections.mdwn
@@ -0,0 +1,11 @@
+### Please describe the problem.
+
+I am running an initial export to my NAS over WebDAV. The repo contains many small files and it already runs for a day. Even the smallest file takes around a second to upload.
+
+Looking at strace and the code, it seems that for each file, git annex not only establishes a complete new TCP connection, it even also reads the credentials from .git/annex/creds for each file.
+
+Are there ways to make WebDAV faster?
+Could http connections be reused?
+Could multiple files be uploaded in parallel?
+
+Apparently files are also upload to a temporary location and renamed after successful upload. This adds additional latency and thus parallel uploads could provide a speed up?

diff --git a/doc/forum/Disconnected_Archive_and_Backups/comment_5_93bed4629304725297f88cfa3d494720._comment b/doc/forum/Disconnected_Archive_and_Backups/comment_5_93bed4629304725297f88cfa3d494720._comment
new file mode 100644
index 000000000..1b039fce3
--- /dev/null
+++ b/doc/forum/Disconnected_Archive_and_Backups/comment_5_93bed4629304725297f88cfa3d494720._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="kyle"
+ avatar="http://cdn.libravatar.org/avatar/7d6e85cde1422ad60607c87fa87c63f3"
+ subject="comment 5"
+ date="2020-03-17T02:38:16Z"
+ content="""
+Oh, I should have refreshed the page.  It seems you came up with
+essentially the same expression :>  Sorry for the noise.
+"""]]

diff --git a/doc/forum/Disconnected_Archive_and_Backups/comment_4_b3d39d1b85489ce4059a72b9a912624c._comment b/doc/forum/Disconnected_Archive_and_Backups/comment_4_b3d39d1b85489ce4059a72b9a912624c._comment
new file mode 100644
index 000000000..bec682f62
--- /dev/null
+++ b/doc/forum/Disconnected_Archive_and_Backups/comment_4_b3d39d1b85489ce4059a72b9a912624c._comment
@@ -0,0 +1,36 @@
+[[!comment format=mdwn
+ username="kyle"
+ avatar="http://cdn.libravatar.org/avatar/7d6e85cde1422ad60607c87fa87c63f3"
+ subject="comment 4"
+ date="2020-03-17T02:35:49Z"
+ content="""
+Sorry, it should have occurred to me that \"archive\", \"client\", and
+\"backup\" in your initial post were referring to git-annex's standard
+groups.  Indeed then, as you say, the desktop won't get the content
+from the archive because, as a client, it uses this content
+expression:
+
+```
+(include=* and ((exclude=*/archive/* and exclude=archive/*) or (not (copies=archive:1 or copies=smallarchive:1)))) or approxlackingcopies=1
+```
+
+> Perhaps I can make a rule set myself that does what I want
+
+I think that, for the desktop repo, extending the expression above
+with something like
+
+```
+(not (copies=backup:1 or copies=incrementalbackup:1))
+```
+
+would do what you're after.  That should make the desktop grab the
+file from the usb if it hasn't reached the NAS.
+
+Here's the complete configuration that I think should be needed:
+
+```
+git annex wanted . groupwanted
+git annex groupwanted client '(include=* and ((exclude=*/archive/* and exclude=archive/*) or (not (copies=archive:1 or copies=smallarchive:1)) or (not (copies=backup:1 or copies=incrementalbackup:1)))) or approxlackingcopies=1'
+```
+
+"""]]

diff --git a/doc/forum/Disconnected_Archive_and_Backups/comment_3_fae320f7453cf8c7147a109f19be22ba._comment b/doc/forum/Disconnected_Archive_and_Backups/comment_3_fae320f7453cf8c7147a109f19be22ba._comment
new file mode 100644
index 000000000..93014d013
--- /dev/null
+++ b/doc/forum/Disconnected_Archive_and_Backups/comment_3_fae320f7453cf8c7147a109f19be22ba._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="lasitus"
+ avatar="http://cdn.libravatar.org/avatar/dfe778f28027aeb75876172022aa5de3"
+ subject="comment 3"
+ date="2020-03-17T02:15:13Z"
+ content="""
+Wow! Such an amazing feature to make your own groups. This is so powerful.
+
+I did this, if anyone else is wanting to do this type setup:
+
+```
+groupwanted mainclient = (include=* and ((exclude=*/archive/* and exclude=archive/*) or (not copies=backup:1) or (not (copies=archive:1 or copies=smallarchive:1)))) or approxlackingcopies=1
+```
+
+I basically added (not copies=backup:1) to the main client so that it will pull stuff off the archive and deliver it to the NAS before not needing it itself. It did exactly that; in the same sync, it grabbed content from the external ssd, transferred it to the nas, then dropped it.
+"""]]

diff --git a/doc/forum/Disconnected_Archive_and_Backups/comment_2_63b934b773b5f7a3c128dd9685f671ab._comment b/doc/forum/Disconnected_Archive_and_Backups/comment_2_63b934b773b5f7a3c128dd9685f671ab._comment
new file mode 100644
index 000000000..80c2ab5f5
--- /dev/null
+++ b/doc/forum/Disconnected_Archive_and_Backups/comment_2_63b934b773b5f7a3c128dd9685f671ab._comment
@@ -0,0 +1,23 @@
+[[!comment format=mdwn
+ username="lasitus"
+ avatar="http://cdn.libravatar.org/avatar/dfe778f28027aeb75876172022aa5de3"
+ subject="comment 2"
+ date="2020-03-16T22:29:31Z"
+ content="""
+Not sure why I didn't just try this rather than asking... but now that I've tried it, it doesn't make it to the nas.
+
+```
+whereis archive/testOnLaptop3.img (2 copies)
+        19955c70-90fc-4aa4-9531-ff7fb9fd3a9e -- [usbssd]
+        fe861a5c-818b-4b66-8f2c-0717ba5ed081 -- laptop
+```
+
+I would normally be running git annex assistant, but for this test, I ran
+
+```
+git annex sync --content
+```
+on my laptop and then on my desktop without my laptop connected to the network.
+
+When run on my laptop, I had a thumb drive and the external SSD plugged in. The external SSD is an archive. It archived it off the usb thumb drive, because this is a client and left it on my laptop. I plugged in the external ssd to my desktop and ran sync --content, and it never copied it over, because it is archived (as expected) even though the NAS hadn't backed it up yet. I assume this is because the NAS never is directly connected to the usb ssd nor is the ssd ever connected directly to the nas, so the desktop doesn't shuttle it between the two. I suppose I could fix this particular layout by making the nas the archive, but having the ability to have a large data dump when offsite for a long time and have it automatically archive to an ssd seems nice. Perhaps I can make a rule set myself that does what I want, or change the layout with existing groups.
+"""]]

diff --git a/doc/bugs/very_slow_export_to_directory_special_remote___40__on_USB_drive__41__.mdwn b/doc/bugs/very_slow_export_to_directory_special_remote___40__on_USB_drive__41__.mdwn
index 4a30fb0d1..a7d87953a 100644
--- a/doc/bugs/very_slow_export_to_directory_special_remote___40__on_USB_drive__41__.mdwn
+++ b/doc/bugs/very_slow_export_to_directory_special_remote___40__on_USB_drive__41__.mdwn
@@ -71,3 +71,5 @@ Some questions:
 - The object store files in the remote were stored in format AAA/BBB/$HASH with three character directory names. While in .git/annex/objects the folders have two characters. What are those characters? I believe the 3 characters format is for remotes that potentially do not distinguish letter case?
 - Is there a command to get the full path of a file in the object store (two or three letters) from the hash?
 - Maybe there is still a bug. Is there a possibility that git-annex could forget that a remote is configured with exporttree=yes? Especially if I export to the same directory on the same usb drive from two synced repos?
+
+[[done]]

diff --git a/doc/bugs/very_slow_export_to_directory_special_remote___40__on_USB_drive__41__/comment_2_a485eecc4e2541d1f56f90ec3ea9296b._comment b/doc/bugs/very_slow_export_to_directory_special_remote___40__on_USB_drive__41__/comment_2_a485eecc4e2541d1f56f90ec3ea9296b._comment
new file mode 100644
index 000000000..94f0f9d31
--- /dev/null
+++ b/doc/bugs/very_slow_export_to_directory_special_remote___40__on_USB_drive__41__/comment_2_a485eecc4e2541d1f56f90ec3ea9296b._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="thk"
+ avatar="http://cdn.libravatar.org/avatar/bfef10a428769701aeee1db978951461"
+ subject="Please close"
+ date="2020-03-16T20:46:26Z"
+ content="""
+Yes. all issues are solved now. Please close this, I don't know how to close bugs here.
+"""]]

diff --git a/doc/bugs/git-annex_has_no_useful_debug_logging/comment_2_c969e21ef3b85e96e9f8dd19c82f2afd._comment b/doc/bugs/git-annex_has_no_useful_debug_logging/comment_2_c969e21ef3b85e96e9f8dd19c82f2afd._comment
new file mode 100644
index 000000000..6cee5055d
--- /dev/null
+++ b/doc/bugs/git-annex_has_no_useful_debug_logging/comment_2_c969e21ef3b85e96e9f8dd19c82f2afd._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="thk"
+ avatar="http://cdn.libravatar.org/avatar/bfef10a428769701aeee1db978951461"
+ subject="comment 2"
+ date="2020-03-16T20:42:55Z"
+ content="""
+Now I learned how to add debug messages into git-annex. And I learned that there actually already is logging infrastructure in the code.
+
+How does one close bugs here in the wiki?
+
+Actually I would like to assign the bug to myself with the task of finding the right place here in the wiki (or code) to document how to add debug statements. I only discovered accidentally somewhere the debugM method.
+
+
+"""]]

diff --git a/doc/bugs/enableremote_stuck_with_a_recentish_git-annex/comment_16_8768afda308d5afeee2002f53f5cbf2c._comment b/doc/bugs/enableremote_stuck_with_a_recentish_git-annex/comment_16_8768afda308d5afeee2002f53f5cbf2c._comment
new file mode 100644
index 000000000..80f64e1bd
--- /dev/null
+++ b/doc/bugs/enableremote_stuck_with_a_recentish_git-annex/comment_16_8768afda308d5afeee2002f53f5cbf2c._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 16"
+ date="2020-03-16T19:54:42Z"
+ content="""
+overall - yes. It still might be just our \"Runner\" issue.  I am not 100% sure in that since a reimplementation (WitlessRunner, used now in many places of the master version) which shouldn't have similar drawbacks, and should not stall -- it did stall as well and we didn't dig yet deeper.  Another \"anecdotal\" observation was that I saw the \"python -m nose\" which runs our tests to not exit cleanly, waiting for some process to be done, or until I Ctrl-C it... didn't analyze that situation either.
+I will try to find some time to dig into this deeper and/or bisect (isn't easy/fun since didn't manage to reproduce locally yet).  Thank you for the details and comments about sockets -- I am yet to fully analyze that situation as well.  I just know that I do have some hanging around and they might have been initiated by a git-annex process which we start pointing to some not-yet initiated socket.
+"""]]

diff --git a/doc/forum/Disconnected_Archive_and_Backups/comment_1_c56f2d3328c0d127efc21067dc52df15._comment b/doc/forum/Disconnected_Archive_and_Backups/comment_1_c56f2d3328c0d127efc21067dc52df15._comment
new file mode 100644
index 000000000..99aa9729e
--- /dev/null
+++ b/doc/forum/Disconnected_Archive_and_Backups/comment_1_c56f2d3328c0d127efc21067dc52df15._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="kyle"
+ avatar="http://cdn.libravatar.org/avatar/7d6e85cde1422ad60607c87fa87c63f3"
+ subject="reply: disconnected archive"
+ date="2020-03-16T18:56:13Z"
+ content="""
+> If the laptop is used offsite with the usb drive archive and the
+> laptop archives a file never yet seen by the NAS, will the NAS ever
+> get this file?
+
+It looks like there is a path the content could go in this case:
+
+    laptop -> USB -> desktop -> NAS
+
+You don't mention how you are syncing, but assuming that you're doing
+so in a way that actually transfers the content to each node of that
+path (e.g., `git annex sync --content` with appropriately configured
+preferred content), then I'd say the answer is \"yes\".
+
+"""]]

diff --git a/doc/bugs/enableremote_stuck_with_a_recentish_git-annex/comment_15_ba2420e2d8f41dbdafc839246b8362aa._comment b/doc/bugs/enableremote_stuck_with_a_recentish_git-annex/comment_15_ba2420e2d8f41dbdafc839246b8362aa._comment
new file mode 100644
index 000000000..fbf7436a2
--- /dev/null
+++ b/doc/bugs/enableremote_stuck_with_a_recentish_git-annex/comment_15_ba2420e2d8f41dbdafc839246b8362aa._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 15"""
+ date="2020-03-16T18:27:34Z"
+ content="""
+Re ControlPersist=yes, git-annex runs ssh -O stop on a socket file on exit,
+unless some other git-annex process is also using that socket. So they don't
+hangaround stale. By passing options to make ssh use other sockets, 
+you bypass that.
+
+I do see in https://github.com/datalad/datalad/pull/4265
+that you seem to have reproduced the hang without running git-annex at all?
+Is that right? Seems to say not a git-annex bug. Perhaps some innocuous
+change in behavior by git-annex, that tickles whatever the real problem is.
+"""]]

diff --git a/doc/bugs/enableremote_stuck_with_a_recentish_git-annex/comment_14_a532adc63a5ad97ab37a0a775cda0d0e._comment b/doc/bugs/enableremote_stuck_with_a_recentish_git-annex/comment_14_a532adc63a5ad97ab37a0a775cda0d0e._comment
new file mode 100644
index 000000000..6b9e30f34
--- /dev/null
+++ b/doc/bugs/enableremote_stuck_with_a_recentish_git-annex/comment_14_a532adc63a5ad97ab37a0a775cda0d0e._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 14"""
+ date="2020-03-16T18:18:52Z"
+ content="""
+I'm having a hard time seeing what I can do about this. It's not clear that
+git-annex is at fault at all, I don't know how to reproduce it, etc.
+
+You should be able to bisect the what changed the behavior, I suppose.
+"""]]

diff --git a/doc/todo/restore_--include-dotfiles_as_a_no-op_for_backwards_compatibility.mdwn b/doc/todo/restore_--include-dotfiles_as_a_no-op_for_backwards_compatibility.mdwn
index fb98806e5..f7975282a 100644
--- a/doc/todo/restore_--include-dotfiles_as_a_no-op_for_backwards_compatibility.mdwn
+++ b/doc/todo/restore_--include-dotfiles_as_a_no-op_for_backwards_compatibility.mdwn
@@ -1 +1,4 @@
 Thanks for [[addressing|news/version_8.20200226]] "[[bugs/dotfiles_handled_differently]]".  One small thing: to preserve backwards compatibility, could `--include-dotfiles` be made a no-op, rather than an invalid flag?
+
+> I think that my comment shows why this should not happen, so [[done]].
+> --[[Joey]]

diff --git a/doc/todo/create_debug_logs_but_erase_them_on_success/comment_1_72b1e3b25a221f42ea7919aaecd6012d._comment b/doc/todo/create_debug_logs_but_erase_them_on_success/comment_1_72b1e3b25a221f42ea7919aaecd6012d._comment
new file mode 100644
index 000000000..5dcf61d1f
--- /dev/null
+++ b/doc/todo/create_debug_logs_but_erase_them_on_success/comment_1_72b1e3b25a221f42ea7919aaecd6012d._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2020-03-16T18:09:30Z"
+ content="""
+I'm doubtful about this:
+
+* It's not super likely that a debug log will have enough information in it
+  to replicate a one-off problem. At best they generally provide some clues
+  that need to be confirmed with experiments, so the problem needs to be
+  reproduced before I can fix it.
+* This risks accumulating a bunch of debug logs if the user is doing things
+  that fail. Things can fail for a wide array or reasons that do not need
+  to be debugged, eg git-annex get fails all the time for valid reasons
+  such as a host not being accessible or drive not being mounted.
+* A debug log might contain some sensitive information, git-annex should
+  certianly not be sending them around without the user's eyes on them.
+* If the user noticed git-annex is accumulating a bunch of debug logs,
+  and does feel they are sensitive information, they may lose trust in
+  git-annex.
+"""]]

diff --git a/doc/todo/git-annex_find_--batch_will_not_accept_absolute_paths/comment_1_5340007d4d849db6057b3138ba1ba37c._comment b/doc/todo/git-annex_find_--batch_will_not_accept_absolute_paths/comment_1_5340007d4d849db6057b3138ba1ba37c._comment
new file mode 100644
index 000000000..019b84cdf
--- /dev/null
+++ b/doc/todo/git-annex_find_--batch_will_not_accept_absolute_paths/comment_1_5340007d4d849db6057b3138ba1ba37c._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2020-03-16T18:06:47Z"
+ content="""
+Hmm, I am not reproducing this problem here.
+
+Were you passing other options besides --batch, to eg match some files?
+
+And what version?
+"""]]

diff --git a/doc/bugs/Preserving_times_for_Annexed_files_on_Android___47___Termux_not_permitted/comment_1_093b92c3a751d32600958f34c3f2122d._comment b/doc/bugs/Preserving_times_for_Annexed_files_on_Android___47___Termux_not_permitted/comment_1_093b92c3a751d32600958f34c3f2122d._comment
new file mode 100644
index 000000000..2eab7fed0
--- /dev/null
+++ b/doc/bugs/Preserving_times_for_Annexed_files_on_Android___47___Termux_not_permitted/comment_1_093b92c3a751d32600958f34c3f2122d._comment
@@ -0,0 +1,24 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2020-03-16T17:56:51Z"
+ content="""
+What git-annex could do is avoid passing -p to cp when it's running on
+android.
+
+Utility.Android.osAndroid already has a way to detect
+that, but running uname on every file copy is not an acceptable
+performance hit, so it would need to somehow only do it once.
+
+I am not currently seeing a satisfactory way to do that,
+everything adds at least some overhead (ie a MVar lookup) 
+to every file copy in the non-android case, and it's just 
+not acceptable that a niche use case like android adversely
+affect linux.
+
+Also, I don't think I saw this when I used git-annex on android,
+although I'm not sure if I tried anything that does copy a file.
+And it probably happens when the repo is in the sdcard, but not when it's
+in other locations, like the termux home directory, that are not on the
+mess of a filesystem stack that android uses for the sdcard.
+"""]]

diff --git a/doc/bugs/enableremote_stuck_with_a_recentish_git-annex/comment_13_afc2af08abebba808886464fbcd0b9d7._comment b/doc/bugs/enableremote_stuck_with_a_recentish_git-annex/comment_13_afc2af08abebba808886464fbcd0b9d7._comment
new file mode 100644
index 000000000..d479374fb
--- /dev/null
+++ b/doc/bugs/enableremote_stuck_with_a_recentish_git-annex/comment_13_afc2af08abebba808886464fbcd0b9d7._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 13"
+ date="2020-03-16T17:57:27Z"
+ content="""
+It should be the same host:
+
+```
+$> grep test /etc/hosts
+127.0.0.1  	datalad-test
+
+```
+
+FWIW more of details of my struggle is available on [datalad/pull/4265#issuecomment-597416284](https://github.com/datalad/datalad/pull/4265#issuecomment-597416284). The last suspicion was that may be while on travis that process simply doesn't return fully if it opens a new socket, path to which we provide but do not have ssh yet \"serving\" it.  Another side topic (might formalize later on) which might or not be related is that git-annex uses `ControlPersist=yes` thus without any time out. FWIW, when datalad starts one, we use `ControlPersist=15m` (we might want to reduce it but at least it is not forever).  Setting it to `ControlPersist=1m` (not `yes`) by git-annex, and hoping that ssh would close that eventually, might unstuck us... didn't try
+"""]]

diff --git a/doc/bugs/very_slow_export_to_directory_special_remote___40__on_USB_drive__41__/comment_1_921af0fe20bfe690c008f0173394b765._comment b/doc/bugs/very_slow_export_to_directory_special_remote___40__on_USB_drive__41__/comment_1_921af0fe20bfe690c008f0173394b765._comment
new file mode 100644
index 000000000..86b5a9e0a
--- /dev/null
+++ b/doc/bugs/very_slow_export_to_directory_special_remote___40__on_USB_drive__41__/comment_1_921af0fe20bfe690c008f0173394b765._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2020-03-16T17:37:27Z"
+ content="""
+The directory special remote uses haskell's native ByteString library,
+which tends to be easily capable of fully saturating IO on most systems.
+The imposition of a meter by Utility.Metered does not change that
+appreciably, it just uses a small amount of CPU time to update a counter 
+and occasionally display progress.
+
+ByteString uses a default 32kb chunk size, so if having the drive mounted sync
+means it flushes the cache after every 32kb write, well there's your problem.
+
+All your other questions have been discussed elsewhere on this website
+AFAIK, and I'm not going to try to discuss all that here. Bug reports
+should be about a single bug.
+"""]]

diff --git a/doc/bugs/git-annex_has_no_useful_debug_logging/comment_1_9c9808c6e8363b9c230b160f21115a13._comment b/doc/bugs/git-annex_has_no_useful_debug_logging/comment_1_9c9808c6e8363b9c230b160f21115a13._comment
new file mode 100644
index 000000000..e271ddf25
--- /dev/null
+++ b/doc/bugs/git-annex_has_no_useful_debug_logging/comment_1_9c9808c6e8363b9c230b160f21115a13._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2020-03-16T17:27:59Z"
+ content="""
+I guess that [[bugs/filenames_with_dots_and_spaces_can_not_be_exported]]
+is the bug report about the actual failure, and lack of a useful error
+message after the failure, and this bug is left as just a complaint about
+lack  of debug logging.
+
+I'm not sure what to do about this bug. I'm not going to go around adding debug
+logging statement to git-annex at random until some arbitrary criteria is
+reached at which point there is "enough" to close this bug. It kind of
+follows that I either leave the bug open forever, which is useless, or
+close it immediately. Do you have an alternative suggestion?
+"""]]

diff --git a/doc/bugs/p2p_auth_token_can_only_be_retrieved_at_generation_time/comment_1_53132295395cb3e504b55c90bc705518._comment b/doc/bugs/p2p_auth_token_can_only_be_retrieved_at_generation_time/comment_1_53132295395cb3e504b55c90bc705518._comment
new file mode 100644
index 000000000..187827846
--- /dev/null
+++ b/doc/bugs/p2p_auth_token_can_only_be_retrieved_at_generation_time/comment_1_53132295395cb3e504b55c90bc705518._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2020-03-16T17:20:10Z"
+ content="""
+You can run git-annex p2p --gen-addresses repeatedly. Each address
+can be given to one entity you want to grant access to the repository.
+
+That way, if you choose to revoke access later, you can revoke just one.
+
+Not that there's currently a command to revoke, but it just deletes
+the address from .git/annex/creds/p2pauth.
+
+If you'd like to contribute, you could maybe improve the documentation
+so it's clearer that --gen-addresses can be used repeatedly, 
+or add a --remove-address or something like that.
+"""]]

diff --git a/doc/bugs/networkbsd_flag_default_differs_in_stack.yaml_and_git-annex.cabal.mdwn b/doc/bugs/networkbsd_flag_default_differs_in_stack.yaml_and_git-annex.cabal.mdwn
index 8b95fd24d..20e1d33c6 100644
--- a/doc/bugs/networkbsd_flag_default_differs_in_stack.yaml_and_git-annex.cabal.mdwn
+++ b/doc/bugs/networkbsd_flag_default_differs_in_stack.yaml_and_git-annex.cabal.mdwn
@@ -1 +1,3 @@
 Not sure it's a bug, but the networkbsd flag defaults to true in git-annex.cabal and to false in stack.yaml -- is that intended?
+
+> not a bug, [[done]] --[[Joey]]
diff --git a/doc/bugs/networkbsd_flag_default_differs_in_stack.yaml_and_git-annex.cabal/comment_1_73e6442cc842f21d6f26e20041d7f88d._comment b/doc/bugs/networkbsd_flag_default_differs_in_stack.yaml_and_git-annex.cabal/comment_1_73e6442cc842f21d6f26e20041d7f88d._comment
new file mode 100644
index 000000000..38dedf53c
--- /dev/null
+++ b/doc/bugs/networkbsd_flag_default_differs_in_stack.yaml_and_git-annex.cabal/comment_1_73e6442cc842f21d6f26e20041d7f88d._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2020-03-16T17:14:20Z"
+ content="""
+Yes. When cabal is used, it will unset the flag as
+necessary if an older version of network is available. Meanwhile,
+stack uses lts-14.27, which includes network-2.x, and somehow stack
+forces the networkbsd flag to not be unset in that case. (I don't know
+how/why.)
+"""]]

diff --git a/doc/bugs/enableremote_stuck_with_a_recentish_git-annex/comment_12_435c4cad7d3837aa09292642b983f041._comment b/doc/bugs/enableremote_stuck_with_a_recentish_git-annex/comment_12_435c4cad7d3837aa09292642b983f041._comment
new file mode 100644
index 000000000..9b8869757
--- /dev/null
+++ b/doc/bugs/enableremote_stuck_with_a_recentish_git-annex/comment_12_435c4cad7d3837aa09292642b983f041._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 12"""
+ date="2020-03-16T16:48:38Z"
+ content="""
+It seems to me that the process tree you pasted there comes from 
+the host where git-annex is running, and not the host that it sshes
+to in order to run git-annex-shell.
+
+What I was suggesting is, if ssh $host git-annex-shell seems to be hanging,
+it then makes sense to go look at $host and see if git-annex-shell is
+running there, or has already run there (eg looking at
+the ssh log). That bisects the problem space to one side or the other.
+"""]]

diff --git a/Annex.hs b/Annex.hs
index 9e0bcd3d8..c914748d5 100644
--- a/Annex.hs
+++ b/Annex.hs
@@ -325,7 +325,11 @@ overrideGitConfig f = changeState $ \s -> s
 	}
 
 {- Adds an adjustment to the Repo data. Adjustments persist across reloads
- - of the repo's config. -}
+ - of the repo's config.
+ -
+ - Note that the action may run more than once, and should avoid eg,
+ - appending the same value to a repo's config when run repeatedly.
+ -}
 adjustGitRepo :: (Git.Repo -> IO Git.Repo) -> Annex ()
 adjustGitRepo a = do
 	changeState $ \s -> s { repoadjustment = \r -> repoadjustment s r >>= a }
diff --git a/CHANGELOG b/CHANGELOG
index 711a2b549..de59f8972 100644
--- a/CHANGELOG
+++ b/CHANGELOG
@@ -1,3 +1,10 @@
+git-annex (8.20200310) UNRELEASED; urgency=medium
+
+  * Fix a minor bug that caused options provided with -c to be passed
+    multiple times to git.
+
+ -- Joey Hess <id@joeyh.name>  Mon, 16 Mar 2020 12:43:33 -0400
+
 git-annex (8.20200309) upstream; urgency=medium
 
   * Fix bug that caused unlocked annexed dotfiles to be added to git by the
diff --git a/CmdLine/GitAnnex/Options.hs b/CmdLine/GitAnnex/Options.hs
index 2fe128e0e..c901f5d4f 100644
--- a/CmdLine/GitAnnex/Options.hs
+++ b/CmdLine/GitAnnex/Options.hs
@@ -93,8 +93,11 @@ gitAnnexGlobalOptions = commonGlobalOptions ++
   where
 	setnumcopies n = Annex.changeState $ \s -> s { Annex.forcenumcopies = Just $ NumCopies n }
 	setuseragent v = Annex.changeState $ \s -> s { Annex.useragent = Just v }
-	setgitconfig v = Annex.adjustGitRepo $ \r -> Git.Config.store (encodeBS' v) $ 
-		r { gitGlobalOpts = gitGlobalOpts r ++ [Param "-c", Param v] }
+	setgitconfig v = Annex.adjustGitRepo $ \r -> 
+		if Param v `elem` gitGlobalOpts r
+			then return r
+			else Git.Config.store (encodeBS' v) $ 
+				r { gitGlobalOpts = gitGlobalOpts r ++ [Param "-c", Param v] }
 	setdesktopnotify v = Annex.changeState $ \s -> s { Annex.desktopnotify = Annex.desktopnotify s <> v }
 
 {- Parser that accepts all non-option params. -}
diff --git a/doc/bugs/Some_calls_to_git_repeat_--config_values.mdwn b/doc/bugs/Some_calls_to_git_repeat_--config_values.mdwn
index 9fbda78a0..424dd5ceb 100644
--- a/doc/bugs/Some_calls_to_git_repeat_--config_values.mdwn
+++ b/doc/bugs/Some_calls_to_git_repeat_--config_values.mdwn
@@ -37,3 +37,5 @@ worth filing in case there's a simple fix.
 
 [[!meta author=kyle]]
 [[!tag projects/datalad]]
+
+> [[fixed|done]] --[[Joey]]

diff --git a/doc/bugs/get_-J8_on_OSX_leads_to_git-annex__58___git__58___createProcess__58___runInteractiveProcess__58___pipe__58___resource_exhausted___40__Too_many_open_files__41__.mdwn b/doc/bugs/get_-J8_on_OSX_leads_to_git-annex__58___git__58___createProcess__58___runInteractiveProcess__58___pipe__58___resource_exhausted___40__Too_many_open_files__41__.mdwn
index 3e58b2cde..e416c89a8 100644
--- a/doc/bugs/get_-J8_on_OSX_leads_to_git-annex__58___git__58___createProcess__58___runInteractiveProcess__58___pipe__58___resource_exhausted___40__Too_many_open_files__41__.mdwn
+++ b/doc/bugs/get_-J8_on_OSX_leads_to_git-annex__58___git__58___createProcess__58___runInteractiveProcess__58___pipe__58___resource_exhausted___40__Too_many_open_files__41__.mdwn
@@ -50,3 +50,5 @@ I will try to get a chance to troubleshoot it more to provide possibly more deta
 
 [[!meta author=yoh]]
 [[!tag projects/datalad]]
+
+[[!tag moreinfo]]

diff --git a/doc/bugs/get_-J8_on_OSX_leads_to_git-annex__58___git__58___createProcess__58___runInteractiveProcess__58___pipe__58___resource_exhausted___40__Too_many_open_files__41__/comment_1_5f9e9600d65c1270b479cc8910d507d0._comment b/doc/bugs/get_-J8_on_OSX_leads_to_git-annex__58___git__58___createProcess__58___runInteractiveProcess__58___pipe__58___resource_exhausted___40__Too_many_open_files__41__/comment_1_5f9e9600d65c1270b479cc8910d507d0._comment
new file mode 100644
index 000000000..7bdde7d8e
--- /dev/null
+++ b/doc/bugs/get_-J8_on_OSX_leads_to_git-annex__58___git__58___createProcess__58___runInteractiveProcess__58___pipe__58___resource_exhausted___40__Too_many_open_files__41__/comment_1_5f9e9600d65c1270b479cc8910d507d0._comment
@@ -0,0 +1,26 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2020-03-16T16:13:00Z"
+ content="""
+The obvious question to ask, which I can't really imagine making any
+progress without an answer to: What files did git-annex have open?
+
+I did notice that of the two git-annex logs, one got 19 files before
+failing, while the other got 27. It seems unlikely that, if git-annex, or
+an external remote, or git, or whatever is somehow leaking file handles,
+it would leak different numbers at different times. Which leads to the
+second question: What else on the system has files open and how many?
+
+OSX has a global limit of 12k open files, and a per process limit of 10k.
+
+`git-annex get` on linux needs to open around 16 files per file it
+downloads. So if git-annex were somehow leaking every single open FD,
+it would successfully download over 600 files before hitting the
+per-process limit. If every subprocess git-annex forks also leaked every
+open FD, it would of course vary by remote, but with a regular git clone
+on the local filesystem, the number of files opened per get is still only
+62, so still over an order of magnitude less.
+
+Seems much more likely that the system is unhappy for some other reason.
+"""]]

diff --git a/doc/forum/Disconnected_Archive_and_Backups.mdwn b/doc/forum/Disconnected_Archive_and_Backups.mdwn
index aea91813b..8d5a35454 100644
--- a/doc/forum/Disconnected_Archive_and_Backups.mdwn
+++ b/doc/forum/Disconnected_Archive_and_Backups.mdwn
@@ -1,6 +1,8 @@
 I am using git annex to sync a portion of my home directory. The main use/sync point is on my desktop and laptop. The desktop and laptop are connected to a NAS and usb drives.
 
 So, the repos are connected like so:
+
+```
        NAS - backup
           ^          ^
          /             \
@@ -8,6 +10,7 @@ desktop - client      laptop - client
          \              /
           v            v
           USB drive - archive
+```
 
 The idea is the NAS should get all files, the USB drive acts as an archive to keep the clients a bit lighter weight, even while off site.
 

diff --git a/doc/forum/Disconnected_Archive_and_Backups.mdwn b/doc/forum/Disconnected_Archive_and_Backups.mdwn
new file mode 100644
index 000000000..aea91813b
--- /dev/null
+++ b/doc/forum/Disconnected_Archive_and_Backups.mdwn
@@ -0,0 +1,15 @@
+I am using git annex to sync a portion of my home directory. The main use/sync point is on my desktop and laptop. The desktop and laptop are connected to a NAS and usb drives.
+
+So, the repos are connected like so:
+       NAS - backup
+          ^          ^
+         /             \
+desktop - client      laptop - client
+         \              /
+          v            v
+          USB drive - archive
+
+The idea is the NAS should get all files, the USB drive acts as an archive to keep the clients a bit lighter weight, even while off site.
+
+Question:
+If the laptop is used offsite with the usb drive archive and the laptop archives a file never yet seen by the NAS, will the NAS ever get this file? Note: the USB drive is never directly connected to the NAS and is not in its list of remotes.

diff --git a/doc/forum/walkthrough_report_setting_up_tor_p2p_remote.mdwn b/doc/forum/walkthrough_report_setting_up_tor_p2p_remote.mdwn
index 874083942..c5d496295 100644
--- a/doc/forum/walkthrough_report_setting_up_tor_p2p_remote.mdwn
+++ b/doc/forum/walkthrough_report_setting_up_tor_p2p_remote.mdwn
@@ -85,3 +85,7 @@ I needed some time to find out that I need to configure "annex-tracking-branch"
 - <https://git-annex.branchable.com/tips/peer_to_peer_network_with_tor>
 - <https://2019.www.torproject.org/docs/onion-services>
 - <https://riseup.net/en/security/network-security/tor/onionservices-best-practices>
+
+## Update 2020-03-16
+
+https://git-annex.branchable.com/bugs/p2p_auth_token_can_only_be_retrieved_at_generation_time

diff --git a/doc/bugs/p2p_auth_token_can_only_be_retrieved_at_generation_time.mdwn b/doc/bugs/p2p_auth_token_can_only_be_retrieved_at_generation_time.mdwn
new file mode 100644
index 000000000..616ae3eff
--- /dev/null
+++ b/doc/bugs/p2p_auth_token_can_only_be_retrieved_at_generation_time.mdwn
@@ -0,0 +1,9 @@
+### Please describe the problem.
+
+`git annex p2p --gen-address` creates an auth token and than immediately prints it out so that it can be used to pair with another machine.
+
+But what am I supposed to do if I want to pair a third machine later? I do not want to call `--gen-address` again since it probably creates another token or even worse overwrites the token already used for one pairing.
+
+So we lack a command like `git annex p2p --show-address` that just prints the same as `--gen-address`. This is trivial since we just need to concatenate `.git/annex/creds/p2paddrs`, a colon and `.git/annex/creds/p2pauth`?
+
+Actually this would be a fun starter project for a new contributor to git-annex? (me?)

diff --git a/doc/bugs/adb_special_remote_fetches_but_does_not_add_all_files/comment_3_3b4100037ee9180346ffc2240a34064e._comment b/doc/bugs/adb_special_remote_fetches_but_does_not_add_all_files/comment_3_3b4100037ee9180346ffc2240a34064e._comment
new file mode 100644
index 000000000..5d56f4b61
--- /dev/null
+++ b/doc/bugs/adb_special_remote_fetches_but_does_not_add_all_files/comment_3_3b4100037ee9180346ffc2240a34064e._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="jksrecko"
+ avatar="http://cdn.libravatar.org/avatar/5b4ec0230521d006e2ece44fe1d9800b"
+ subject="comment 3"
+ date="2020-03-15T09:54:00Z"
+ content="""
+I forgot to mention that I also get:
+
+\"Not updating export to [remote] to reflect changes to the tree, because export tracking is not enabled.  (Set remote.[remotename].annex-tracking-branch to enable it.)\"
+
+But I have this set. Maybe I get it because there was no successful sync yet?
+"""]]

diff --git a/doc/bugs/git-annex_remotedaemon_--foreground_exits_immediately_if_run_as_systemd_service.mdwn b/doc/bugs/git-annex_remotedaemon_--foreground_exits_immediately_if_run_as_systemd_service.mdwn
index 1d6a90a22..96033a8ed 100644
--- a/doc/bugs/git-annex_remotedaemon_--foreground_exits_immediately_if_run_as_systemd_service.mdwn
+++ b/doc/bugs/git-annex_remotedaemon_--foreground_exits_immediately_if_run_as_systemd_service.mdwn
@@ -1,6 +1,6 @@
 ### Please describe the problem.
 
-I want to start git-annex remotedaemon on login as a systemd user service. And I want to have logs in journald, not in .gi/annex/daemon.log. Thus I use this service definition:
+I want to start git-annex remotedaemon on login as a systemd user service. And I want to have logs in journald, not in .git/annex/daemon.log. Thus I use this service definition:
 
 ```
 [Unit]

diff --git a/doc/bugs/git-annex_remotedaemon_--foreground_exits_immediately_if_run_as_systemd_service/comment_2_34fa48bba13bf896e6b3809ec22fc58e._comment b/doc/bugs/git-annex_remotedaemon_--foreground_exits_immediately_if_run_as_systemd_service/comment_2_34fa48bba13bf896e6b3809ec22fc58e._comment
new file mode 100644
index 000000000..5efe2585a
--- /dev/null
+++ b/doc/bugs/git-annex_remotedaemon_--foreground_exits_immediately_if_run_as_systemd_service/comment_2_34fa48bba13bf896e6b3809ec22fc58e._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="thk"
+ avatar="http://cdn.libravatar.org/avatar/bfef10a428769701aeee1db978951461"
+ subject="Tor remote does not use stdin"
+ date="2020-03-15T09:35:18Z"
+ content="""
+Hi Joey,
+
+I use the remotedaemon only for tor remotes and it works the way I documented above. So it does not need stdin and stdout at all?
+"""]]

diff --git a/doc/bugs/adb_special_remote_fetches_but_does_not_add_all_files/comment_2_09f5982e930a04c25ea3ce8caac449c4._comment b/doc/bugs/adb_special_remote_fetches_but_does_not_add_all_files/comment_2_09f5982e930a04c25ea3ce8caac449c4._comment
new file mode 100644
index 000000000..f641b9e21
--- /dev/null
+++ b/doc/bugs/adb_special_remote_fetches_but_does_not_add_all_files/comment_2_09f5982e930a04c25ea3ce8caac449c4._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="jksrecko"
+ avatar="http://cdn.libravatar.org/avatar/5b4ec0230521d006e2ece44fe1d9800b"
+ subject="comment 2"
+ date="2020-03-15T09:13:27Z"
+ content="""
+I'm facing a same issue and it persists (tried to sync a couple of times) for one of my adb remotes (DCIM on SD card, i.e. /storage/[vol_id]/DCIM and wanted expression which excludes thumbs and .emptyshow file).
+
+I get \"Failed to import some files from [remotename]. Re-run command to resume import.\" message and no files are imported. Same as for the reporter of the issue, I get that all the files are pulled ok.
+
+I'm using the latest version of git annex (8.20200309-ga9d56a1ab).
+
+"""]]

diff --git a/doc/bugs/git-annex_remotedaemon_--foreground_exits_immediately_if_run_as_systemd_service/comment_1_8573d3bb5ae9f3490265767128027ed1._comment b/doc/bugs/git-annex_remotedaemon_--foreground_exits_immediately_if_run_as_systemd_service/comment_1_8573d3bb5ae9f3490265767128027ed1._comment
new file mode 100644
index 000000000..25d398f51
--- /dev/null
+++ b/doc/bugs/git-annex_remotedaemon_--foreground_exits_immediately_if_run_as_systemd_service/comment_1_8573d3bb5ae9f3490265767128027ed1._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2020-03-14T19:47:45Z"
+ content="""
+remotedaemon --foreground speaks a line-based API over stdio.
+So it does not make sense to use it the way you're using it.
+
+It may be that --foreground should be renamed to something else, and a new
+--foreground option added that just runs the daemon in its usual mode w/o
+backgrounding. I think only the assistant uses --foreground, although it is
+a documented option and there's always the possibility someone has found a
+use for it.
+"""]]

diff --git a/doc/bugs/filenames_with_dots_and_spaces_can_not_be_exported/comment_1_b1ac799adea59dad8fe148183060fb22._comment b/doc/bugs/filenames_with_dots_and_spaces_can_not_be_exported/comment_1_b1ac799adea59dad8fe148183060fb22._comment
new file mode 100644
index 000000000..19da541f0
--- /dev/null
+++ b/doc/bugs/filenames_with_dots_and_spaces_can_not_be_exported/comment_1_b1ac799adea59dad8fe148183060fb22._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2020-03-14T19:44:48Z"
+ content="""
+This seems likely to invole the specific filesystem used for
+/media/thk/thk-sg2/. I woud not be surprised if eg FAT had limitations on
+filenames with dots.
+
+Generally I think that if the remote being exported to cannot support the
+filename, the export should fail. Mangling the filenames should be up to
+the user. 
+
+But there should certianly be a better error message than "failed" in this
+case, so that at least needs to be fixed.
+"""]]

diff --git a/doc/bugs/git-annex_remotedaemon_--foreground_exits_immediately_if_run_as_systemd_service.mdwn b/doc/bugs/git-annex_remotedaemon_--foreground_exits_immediately_if_run_as_systemd_service.mdwn
index c3df3085a..1d6a90a22 100644
--- a/doc/bugs/git-annex_remotedaemon_--foreground_exits_immediately_if_run_as_systemd_service.mdwn
+++ b/doc/bugs/git-annex_remotedaemon_--foreground_exits_immediately_if_run_as_systemd_service.mdwn
@@ -226,3 +226,18 @@ I added some log statements and found out that in module **RemoteDaemon.Core** i
 exits with an exception saying
 
     <stdin>: hGetLine: end of file
+
+### 2020-03-14 Update with workaround
+
+So **man systemd.exec** says in section **StandardInput=**:
+
+> If null is selected, standard input will be connected to /dev/null, i.e. all read attempts by the process will result in immediate EOF.
+
+and
+
+> This setting defaults to null.
+
+My current workaround is this ExecStart line in my systemd service definition:
+
+    ExecStart=/bin/sh -c 'sleep infinity | git-annex remotedaemon --verbose --debug --foreground'
+

diff --git a/doc/bugs/git-annex_remotedaemon_--foreground_exits_immediately_if_run_as_systemd_service.mdwn b/doc/bugs/git-annex_remotedaemon_--foreground_exits_immediately_if_run_as_systemd_service.mdwn
index a05cb6b94..c3df3085a 100644
--- a/doc/bugs/git-annex_remotedaemon_--foreground_exits_immediately_if_run_as_systemd_service.mdwn
+++ b/doc/bugs/git-annex_remotedaemon_--foreground_exits_immediately_if_run_as_systemd_service.mdwn
@@ -216,3 +216,13 @@ systemd[1644]: annex-remotedaemon.service: Succeeded.
 ### What version of git-annex are you using? On what operating system?
 
 git-annex version: 8.20200227-gf56dfe791 on Debian testing
+
+### 2020-03-14 Update
+
+I added some log statements and found out that in module **RemoteDaemon.Core** in function **runInteractive** the expression
+
+    reader `concurrently` writer `concurrently` controller
+
+exits with an exception saying
+
+    <stdin>: hGetLine: end of file

diff --git a/doc/bugs/filenames_with_dots_and_spaces_can_not_be_exported.mdwn b/doc/bugs/filenames_with_dots_and_spaces_can_not_be_exported.mdwn
new file mode 100644
index 000000000..3bdb067e3
--- /dev/null
+++ b/doc/bugs/filenames_with_dots_and_spaces_can_not_be_exported.mdwn
@@ -0,0 +1,15 @@
+### Please describe the problem.
+
+The file `Kontoauszug 01.01.2019 - 31.12.2019 - CH1234567890123456789 - 2019-12-31.pdf` can not be exported. The error message is just "failed".
+
+I added code (pull request underway) to log IOExceptions and saw this exception message:
+
+    /media/thk/thk-sg2/annex-exporttree-sg2/shared/finance/taxes/2019/: openTempFile: invalid argument (Invalid argument)
+
+After renaming the file to `Kontoauszug 01012019 - 31122019 - CH2480808009412070498 - 2019-12-31.pdf` it could be exported.
+
+I am not yet sure what exact combinations of dots, spaces and maybe dashes cause the failure.
+
+### What version of git-annex are you using? On what operating system?
+
+git-annex version: 8.20200309-05df404212, Debian testing

diff --git a/doc/todo/document_git-annex_dependencies/comment_2_bcd0fa1ace9a22b0cc09cea2e7cad84c._comment b/doc/todo/document_git-annex_dependencies/comment_2_bcd0fa1ace9a22b0cc09cea2e7cad84c._comment
new file mode 100644
index 000000000..75639b4ee
--- /dev/null
+++ b/doc/todo/document_git-annex_dependencies/comment_2_bcd0fa1ace9a22b0cc09cea2e7cad84c._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="gsasl dependency"
+ date="2020-03-11T22:13:47Z"
+ content="""
+Thanks for the `debian/control` pointer.
+
+Is `gsasl` a dependency?  Homebrew thinks it is, and it's mentioned in the forums, but I can't find uses of it in the code.
+"""]]

diff --git a/doc/forum/File_history/comment_2_ebe8025d4769d22cafa81ad0f2ae969a._comment b/doc/forum/File_history/comment_2_ebe8025d4769d22cafa81ad0f2ae969a._comment
new file mode 100644
index 000000000..951579136
--- /dev/null
+++ b/doc/forum/File_history/comment_2_ebe8025d4769d22cafa81ad0f2ae969a._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="comment 2"
+ date="2020-03-11T22:00:53Z"
+ content="""
+actually, for (3), `git-annex-log` isn't what you want: it shows _past_ locations, you want _current_ ones.  See [[`git-annex-whereis`|git-annex-whereis]] and [[`git-annex-list`|git-annex-list]].
+"""]]

diff --git a/doc/forum/File_history/comment_1_6c15cdf71b99ae3bf8fd5de489a7d3ee._comment b/doc/forum/File_history/comment_1_6c15cdf71b99ae3bf8fd5de489a7d3ee._comment
new file mode 100644
index 000000000..e7f112a78
--- /dev/null
+++ b/doc/forum/File_history/comment_1_6c15cdf71b99ae3bf8fd5de489a7d3ee._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="past versions of annexed files"
+ date="2020-03-11T21:55:57Z"
+ content="""
+1. \"Of a file, to see the changes to that file's content that have happened over time\" -- See [[todo/git-annex-init_should_configure_git_diff_driver]].
+2. \"Of a file, to be able to revert it to an older version of that file's content\" -- if you create a branch off the commit with that file version,  and check out that branch, this will check out the file pointer to the older contents version.  You may need to then [[`git-annex-get`|git-annex-get]] that old content if it has been moved somewhere.
+3. \"Of a file, to get visibility into what versions of that file's content are available on what remotes\" -- see [[`git-annex-log`|git-annex-log]]
+"""]]

diff --git a/doc/todo/git-annex_find_--batch_will_not_accept_absolute_paths.mdwn b/doc/todo/git-annex_find_--batch_will_not_accept_absolute_paths.mdwn
new file mode 100644
index 000000000..78f802914
--- /dev/null
+++ b/doc/todo/git-annex_find_--batch_will_not_accept_absolute_paths.mdwn
@@ -0,0 +1,5 @@
+`git annex find --batch` will not accept absolute paths to files in the repo, but `git annex find /abs/path` works.
+
+I tested `git annex lookupkey --batch` which does not have this problem.
+
+--spwhitton

diff --git a/doc/forum/which_version_should_I_install__63__/comment_8_ef725153df7a9b65f7ade4d7e6cecffb._comment b/doc/forum/which_version_should_I_install__63__/comment_8_ef725153df7a9b65f7ade4d7e6cecffb._comment
new file mode 100644
index 000000000..903469f4d
--- /dev/null
+++ b/doc/forum/which_version_should_I_install__63__/comment_8_ef725153df7a9b65f7ade4d7e6cecffb._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="comment 8"
+ date="2020-03-11T21:34:14Z"
+ content="""
+\"conda script looks gross, its opaque, and wants to install ms / vs code\" -- in its defense, conda is open-source and is very widely used, so any problems with it are unlikely to go undetected.  What is \"ms / vs\"?
+
+It _would_ be good at some point to create a Docker image with git-annex, that could operate sandboxed, but Docker doesn't handle symlinks well.
+
+\"this website is a train wreck\" -- the website is an editable wiki, so you can fix things yourself, or submit [[pull requests|forum/where_to_submit_pull_requests_for_git-annex?]].  But can I suggest you phrase things less... harshly?  @joeyh has done and is doing a crazy amount of work on git-annex and other public projects, demanding a perfect website on top of that is too much.
+"""]]

diff --git a/doc/bugs/git-annex_remotedaemon_--foreground_exits_immediately_if_run_as_systemd_service.mdwn b/doc/bugs/git-annex_remotedaemon_--foreground_exits_immediately_if_run_as_systemd_service.mdwn
new file mode 100644
index 000000000..a05cb6b94
--- /dev/null
+++ b/doc/bugs/git-annex_remotedaemon_--foreground_exits_immediately_if_run_as_systemd_service.mdwn
@@ -0,0 +1,218 @@
+### Please describe the problem.
+
+I want to start git-annex remotedaemon on login as a systemd user service. And I want to have logs in journald, not in .gi/annex/daemon.log. Thus I use this service definition:
+
+```
+[Unit]
+Description=remotedaemon running in ~/annex
+
+[Service]
+ExecStart=%h/.local/bin/git-annex remotedaemon --verbose --debug --foreground
+WorkingDirectory=%h/annex
+```
+
+Unfortunately, the git-annex process exits immediately. So I added strace:
+
+    ExecStart=/usr/bin/strace %h/.local/bin/git-annex remotedaemon --verbose --debug --foreground
+
+And got (journald logs; removed time, username and "strace[$PID]" from line beginnings):
+
+```
+systemd[1644]: Started remotedaemon running in ~/annex.
+execve("/home/thk/.local/bin/git-annex", ["/home/thk/.local/bin/git-annex", "remotedaemon", "--verbose", "--debug", "--foreground"], 0x7fff95d3eda0 /* 42 vars */) = 0
+brk(NULL)                               = 0x4f44000
+access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
+openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
+fstat(3, {st_mode=S_IFREG|0644, st_size=148740, ...}) = 0
+mmap(NULL, 148740, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f63b2a9f000
+close(3)                                = 0
+
+<<<<<<<<< cut library loading >>>>>>>>>
+
+mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f63b252d000
+mmap(NULL, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f63b252a000
+arch_prctl(ARCH_SET_FS, 0x7f63b252a740) = 0
+mprotect(0x7f63b2720000, 12288, PROT_READ) = 0
+mprotect(0x7f63b2540000, 4096, PROT_READ) = 0
+mprotect(0x7f63b2829000, 4096, PROT_READ) = 0
+mprotect(0x7f63b2568000, 4096, PROT_READ) = 0
+mprotect(0x7f63b2732000, 4096, PROT_READ) = 0
+mprotect(0x7f63b27b5000, 4096, PROT_READ) = 0
+mprotect(0x7f63b27ba000, 4096, PROT_READ) = 0
+mprotect(0x7f63b27c7000, 4096, PROT_READ) = 0
+mprotect(0x7f63b27e4000, 4096, PROT_READ) = 0
+mprotect(0x7f63b280b000, 8192, PROT_READ) = 0
+mprotect(0x7f63b2a9b000, 4096, PROT_READ) = 0
+mprotect(0x7f63b2951000, 16384, PROT_READ) = 0
+mprotect(0x388b000, 77824, PROT_READ)   = 0
+mprotect(0x7f63b2aec000, 4096, PROT_READ) = 0
+munmap(0x7f63b2a9f000, 148740)          = 0
+set_tid_address(0x7f63b252aa10)         = 144630
+set_robust_list(0x7f63b252aa20, 24)     = 0
+rt_sigaction(SIGRTMIN, {sa_handler=0x7f63b28156b0, sa_mask=[], sa_flags=SA_RESTORER|SA_SIGINFO, sa_restorer=0x7f63b2821520}, NULL, 8) = 0
+rt_sigaction(SIGRT_1, {sa_handler=0x7f63b2815750, sa_mask=[], sa_flags=SA_RESTORER|SA_RESTART|SA_SIGINFO, sa_restorer=0x7f63b2821520}, NULL, 8) = 0
+rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) = 0
+prlimit64(0, RLIMIT_STACK, NULL, {rlim_cur=8192*1024, rlim_max=RLIM64_INFINITY}) = 0
+brk(NULL)                               = 0x4f44000
+brk(0x4f65000)                          = 0x4f65000
+openat(AT_FDCWD, "/usr/lib/locale/locale-archive", O_RDONLY|O_CLOEXEC) = 3
+fstat(3, {st_mode=S_IFREG|0644, st_size=3031632, ...}) = 0
+mmap(NULL, 3031632, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f63b2245000
+close(3)                                = 0
+clock_gettime(CLOCK_PROCESS_CPUTIME_ID, {tv_sec=0, tv_nsec=10054427}) = 0
+sysinfo({uptime=38828, loads=[21056, 51328, 54784], totalram=16756289536, freeram=1420591104, sharedram=967385088, bufferram=867651584, totalswap=34099687424, freeswap=34099687424, procs=1643, totalhigh=0, freehigh=0, mem_unit=1}) = 0
+prlimit64(0, RLIMIT_AS, NULL, {rlim_cur=RLIM64_INFINITY, rlim_max=RLIM64_INFINITY}) = 0
+mmap(0x4200000000, 1099512676352, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x4200000000
+madvise(0x4200000000, 1099512676352, MADV_DONTNEED) = 0
+madvise(0x4200000000, 1099512676352, MADV_DONTDUMP) = 0
+mmap(0x4200000000, 1048576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x4200000000
+madvise(0x4200000000, 1048576, MADV_WILLNEED) = 0
+madvise(0x4200000000, 1048576, MADV_DODUMP) = 0
+mmap(0x4200100000, 1048576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x4200100000
+madvise(0x4200100000, 1048576, MADV_WILLNEED) = 0
+madvise(0x4200100000, 1048576, MADV_DODUMP) = 0
+mmap(NULL, 8392704, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_STACK, -1, 0) = 0x7f63b1a44000
+mprotect(0x7f63b1a45000, 8388608, PROT_READ|PROT_WRITE) = 0
+clone(child_stack=0x7f63b2243fb0, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, parent_tidptr=0x7f63b22449d0, tls=0x7f63b2244700, child_tidptr=0x7f63b22449d0) = 144633
+openat(AT_FDCWD, "/proc/self/task/144633/comm", O_RDWR) = 4
+write(4, "ghc_ticker", 10)              = 10
+close(4)                                = 0
+rt_sigaction(SIGINT, {sa_handler=0x36a9820, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7f63b2821520}, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=0}, 8) = 0
+rt_sigaction(SIGINT, NULL, {sa_handler=0x36a9820, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7f63b2821520}, 8) = 0
+rt_sigaction(SIGINT, {sa_handler=0x36a9820, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7f63b25a4100}, NULL, 8) = 0
+rt_sigaction(SIGPIPE, {sa_handler=0x36a9780, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7f63b2821520}, {sa_handler=SIG_IGN, sa_mask=[], sa_flags=0}, 8) = 0
+rt_sigaction(SIGQUIT, {sa_handler=0x36a9800, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7f63b2821520}, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=0}, 8) = 0
+rt_sigaction(SIGTSTP, {sa_handler=0x36a9840, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7f63b2821520}, NULL, 8) = 0
+epoll_create(256)                       = 4
+fcntl(4, F_SETFD, FD_CLOEXEC)           = 0
+pipe([5, 6])                            = 0
+fcntl(6, F_GETFL)                       = 0x1 (flags O_WRONLY)
+fcntl(6, F_SETFL, O_WRONLY|O_NONBLOCK)  = 0
+fcntl(5, F_SETFD, FD_CLOEXEC)           = 0
+fcntl(6, F_SETFD, FD_CLOEXEC)           = 0
+eventfd2(0, 0)                          = 7
+fcntl(7, F_GETFL)                       = 0x2 (flags O_RDWR)
+fcntl(7, F_SETFL, O_RDWR|O_NONBLOCK)    = 0
+fcntl(7, F_SETFD, FD_CLOEXEC)           = 0
+epoll_ctl(4, EPOLL_CTL_ADD, 5, {EPOLLIN, {u32=5, u64=5}}) = 0
+epoll_ctl(4, EPOLL_CTL_ADD, 7, {EPOLLIN, {u32=7, u64=7}}) = 0
+mmap(NULL, 8392704, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_STACK, -1, 0) = 0x7f63b1243000
+mprotect(0x7f63b1244000, 8388608, PROT_READ|PROT_WRITE) = 0
+clone(child_stack=0x7f63b1a42fb0, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, parent_tidptr=0x7f63b1a439d0, tls=0x7f63b1a43700, child_tidptr=0x7f63b1a439d0) = 144635
+openat(AT_FDCWD, "/proc/self/task/144635/comm", O_RDWR) = 8
+write(8, "git-annex:w", 11)             = 11
+close(8)                                = 0
+futex(0x4f63820, FUTEX_WAKE_PRIVATE, 1) = 1
+futex(0x4f636f8, FUTEX_WAIT_PRIVATE, 0, NULL) = 0
+futex(0x4f63700, FUTEX_WAKE_PRIVATE, 1) = 0
+pipe([8, 9])                            = 0
+fcntl(9, F_GETFL)                       = 0x1 (flags O_WRONLY)
+fcntl(9, F_SETFL, O_WRONLY|O_NONBLOCK)  = 0
+fcntl(8, F_SETFD, FD_CLOEXEC)           = 0
+fcntl(9, F_SETFD, FD_CLOEXEC)           = 0
+eventfd2(0, 0)                          = 10
+fcntl(10, F_GETFL)                      = 0x2 (flags O_RDWR)
+fcntl(10, F_SETFL, O_RDWR|O_NONBLOCK)   = 0
+fcntl(10, F_SETFD, FD_CLOEXEC)          = 0
+futex(0x4f63818, FUTEX_WAKE_PRIVATE, 1) = 1
+futex(0x4f63820, FUTEX_WAKE_PRIVATE, 1) = 1
+futex(0x3eea308, FUTEX_WAKE_PRIVATE, 1) = 1
+clock_gettime(CLOCK_PROCESS_CPUTIME_ID, {tv_sec=0, tv_nsec=11616402}) = 0
+futex(0x3eea308, FUTEX_WAIT_PRIVATE, 2, NULL) = -1 EAGAIN (Resource temporarily unavailable)
+futex(0x3eea308, FUTEX_WAIT_PRIVATE, 2, NULL) = 0
+futex(0x3eea308, FUTEX_WAKE_PRIVATE, 1) = 0
+rt_sigprocmask(SIG_BLOCK, [INT], [], 8) = 0
+rt_sigaction(SIGINT, {sa_handler=0x36a98c0, sa_mask=[], sa_flags=SA_RESTORER|SA_RESETHAND|SA_SIGINFO, sa_restorer=0x7f63b2821520}, NULL, 8) = 0
+rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
+ioctl(0, TCGETS, 0x7ffec62b8ec0)        = -1 ENOTTY (Inappropriate ioctl for device)
+ioctl(1, TCGETS, 0x7ffec62b8ec0)        = -1 ENOTTY (Inappropriate ioctl for device)
+ioctl(2, TCGETS, 0x7ffec62b8ec0)        = -1 ENOTTY (Inappropriate ioctl for device)
+getcwd("/home/thk/annex", 4096)         = 16
+stat("/home/thk/annex/.git/config", {st_mode=S_IFREG|0640, st_size=958, ...}) = 0
+pipe([11, 12])                          = 0
+pipe([13, 14])                          = 0
+rt_sigprocmask(SIG_BLOCK, [INT], [], 8) = 0
+vfork()                                 = 144638
+close(12)                               = 0
+fcntl(11, F_SETFD, FD_CLOEXEC)          = 0
+close(14)                               = 0
+fcntl(13, F_SETFD, FD_CLOEXEC)          = 0
+read(13, "", 4)                         = 0
+close(13)                               = 0
+rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
+fcntl(11, F_GETFL)                      = 0 (flags O_RDONLY)
+fcntl(11, F_SETFL, O_RDONLY|O_NONBLOCK) = 0
+ioctl(11, TCGETS, 0x7ffec62b8ec0)       = -1 ENOTTY (Inappropriate ioctl for device)
+read(11, 0x42001de010, 8192)            = -1 EAGAIN (Resource temporarily unavailable)
+epoll_ctl(4, EPOLL_CTL_MOD, 11, {EPOLLIN|EPOLLONESHOT, {u32=11, u64=11}}) = -1 ENOENT (No such file or directory)
+epoll_ctl(4, EPOLL_CTL_ADD, 11, {EPOLLIN|EPOLLONESHOT, {u32=11, u64=11}}) = 0
+futex(0x4f636fc, FUTEX_WAIT_PRIVATE, 0, NULL) = 0
+futex(0x4f63700, FUTEX_WAKE_PRIVATE, 1) = 0
+read(11, "include.path\n/usr/share/git-core"..., 8192) = 4547
+read(11, "", 8192)                      = 0
+close(11)                               = 0
+futex(0x4f6381c, FUTEX_WAKE_PRIVATE, 1) = 1
+futex(0x4f63820, FUTEX_WAKE_PRIVATE, 1) = 1
+futex(0x3eea308, FUTEX_WAKE_PRIVATE, 1) = 1
+wait4(144638, [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], 0, NULL) = 144638
+getcwd("/home/thk/annex", 4096)         = 16
+stat(".git", {st_mode=S_IFDIR|0750, st_size=4096, ...}) = 0
+dup(0)                                  = 11
+ioctl(11, TCGETS, 0x7ffec62b8ec0)       = -1 ENOTTY (Inappropriate ioctl for device)
+dup(1)                                  = 12
+ioctl(12, TCGETS, 0x7ffec62b8ec0)       = -1 ENOTTY (Inappropriate ioctl for device)
+openat(AT_FDCWD, "/dev/null", O_RDONLY|O_NOCTTY|O_NONBLOCK) = 13
+fstat(13, {st_mode=S_IFCHR|0666, st_rdev=makedev(0x1, 0x3), ...}) = 0
+ioctl(13, TCGETS, 0x7ffec62b8ec0)       = -1 ENOTTY (Inappropriate ioctl for device)
+close(0)                                = 0
+dup2(13, 0)                             = 0
+ioctl(0, TCGETS, 0x7ffec62b8ec0)        = -1 ENOTTY (Inappropriate ioctl for device)
+close(1)                                = 0
+dup2(2, 1)                              = 1
+ioctl(1, TCGETS, 0x7ffec62b8ec0)        = -1 ENOTTY (Inappropriate ioctl for device)
+futex(0x7f63a4000be8, FUTEX_WAKE_PRIVATE, 1) = 1
+futex(0x7f63a4000bf0, FUTEX_WAKE_PRIVATE, 1) = 1
+futex(0x3eea308, FUTEX_WAKE_PRIVATE, 1) = 1
+futex(0x4f636f8, FUTEX_WAIT_PRIVATE, 0, NULL
+strace[144630]: futex(0x4f636f8, FUTEX_WAIT_PRIVATE, 0, NULL
+strace[144630]: 2020-03-11 20:32:43.838670
+2020-03-11 20:32:43.838670
+ = 0
+futex(0x4f63) = 0
+futex(0x7f63a4000bec, FUTEX_WAKE_PRIVATE, 1) = 1
+futex(0x7f63a4000bf0, FUTEX_WAKE_PRIVATE, 1) = 1
+futex(0x3eea308, FUTEX_WAKE_PRIVATE, 1) = 1
+futex(0x4f636fc, FUTEX_WAIT_PRIVATE, 0, NULL) = 0
+futex(0x4f63700, FUTEX_WAKE_PRIVATE, 1) = 0
+wait4(-1, 0x42000abc68, WNOHANG|WSTOPPED, NULL) = 0
+clock_gettime(CLOCK_PROCESS_CPUTIME_ID, {tv_sec=0, tv_nsec=15617173}) = 0
+write(9, "\376", 1)                     = 1
+write(6, "\376", 1)                     = 1
+openat(AT_FDCWD, "/sys/devices/system/cpu/online", O_RDONLY|O_CLOEXEC) = 4
+read(4, "0-7\n", 8192)                  = 4
+close(4)                                = 0
+rt_sigprocmask(SIG_BLOCK, [INT], [], 8) = 0

(Diff truncated)

diff --git a/doc/install/comment_10_a949bc4faa61f59021e896101efecb30._comment b/doc/install/comment_10_a949bc4faa61f59021e896101efecb30._comment
new file mode 100644
index 000000000..a2a69bae4
--- /dev/null
+++ b/doc/install/comment_10_a949bc4faa61f59021e896101efecb30._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="eric.w@eee65cd362d995ced72640c7cfae388ae93a4234"
+ nickname="eric.w"
+ avatar="http://cdn.libravatar.org/avatar/8d9808c12db3a3f93ff7f9e74c0870fc"
+ subject="comment 10"
+ date="2020-03-11T19:30:31Z"
+ content="""
+Just in case someone ends up here from google... 
+
+here are the release notes for git-annex
+
+https://hackage.haskell.org/package/git-annex-8.20200309/changelog
+
+my question was answered elsewhere, so I am just adding the link to this thread.
+
+"""]]

diff --git a/doc/forum/which_version_should_I_install__63__/comment_7_b563b2be227a1a128d8ac0679108f5b5._comment b/doc/forum/which_version_should_I_install__63__/comment_7_b563b2be227a1a128d8ac0679108f5b5._comment
new file mode 100644
index 000000000..012b5c73c
--- /dev/null
+++ b/doc/forum/which_version_should_I_install__63__/comment_7_b563b2be227a1a128d8ac0679108f5b5._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="eric.w@eee65cd362d995ced72640c7cfae388ae93a4234"
+ nickname="eric.w"
+ avatar="http://cdn.libravatar.org/avatar/8d9808c12db3a3f93ff7f9e74c0870fc"
+ subject="comment 7"
+ date="2020-03-11T18:21:59Z"
+ content="""
+I'm sorry but that conda script looks gross, its opaque, and wants to install ms / vs code... so i kinda noped out of it. 
+
+I guess I'll just stay 1 rev behind current for now. if I have to I can always use a vm.
+"""]]

diff --git a/doc/forum/which_version_should_I_install__63__/comment_6_c0f850927683d45dbe4d6d1d61788b4a._comment b/doc/forum/which_version_should_I_install__63__/comment_6_c0f850927683d45dbe4d6d1d61788b4a._comment
new file mode 100644
index 000000000..404c99c8a
--- /dev/null
+++ b/doc/forum/which_version_should_I_install__63__/comment_6_c0f850927683d45dbe4d6d1d61788b4a._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="comment 6"
+ date="2020-03-11T18:12:09Z"
+ content="""
+[[install/conda]] installation works on any Linux, don't need to be root.
+"""]]

diff --git a/doc/forum/which_version_should_I_install__63__/comment_5_1c8201cf1de60fde73a2370a6e6c3ad3._comment b/doc/forum/which_version_should_I_install__63__/comment_5_1c8201cf1de60fde73a2370a6e6c3ad3._comment
new file mode 100644
index 000000000..c7569edd4
--- /dev/null
+++ b/doc/forum/which_version_should_I_install__63__/comment_5_1c8201cf1de60fde73a2370a6e6c3ad3._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="eric.w@eee65cd362d995ced72640c7cfae388ae93a4234"
+ nickname="eric.w"
+ avatar="http://cdn.libravatar.org/avatar/8d9808c12db3a3f93ff7f9e74c0870fc"
+ subject="comment 5"
+ date="2020-03-11T18:07:32Z"
+ content="""
+thank you again for being so helpful:
+
+I was using an old lts ubuntu, but the repos only had git-annex v6, and install from source wasn't working, so I upgraded to... ubuntu 19.10 / eoan, and it looks like http://neuro.debian.net/ doesn't yet support that release. 
+
+I don't exactly love polluting my apt sources, but I can be compelled to if that's my best / only option.
+
+I'll keep digging, if I can find a prebuilt .deb, I'll likely use that. (too bad there isn't a snap?)
+"""]]

diff --git a/doc/forum/which_version_should_I_install__63__/comment_4_f627212a612f5d746bb8bcc5e1ea48df._comment b/doc/forum/which_version_should_I_install__63__/comment_4_f627212a612f5d746bb8bcc5e1ea48df._comment
new file mode 100644
index 000000000..06aca1b2c
--- /dev/null
+++ b/doc/forum/which_version_should_I_install__63__/comment_4_f627212a612f5d746bb8bcc5e1ea48df._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="comment 4"
+ date="2020-03-11T17:32:35Z"
+ content="""
+Sure you need to build from source?  There are many [[install]] methods for pre-built binaries.
+"""]]

diff --git a/doc/forum/which_version_should_I_install__63__/comment_3_c85c107a60b4b642ed9a8de7d233f95e._comment b/doc/forum/which_version_should_I_install__63__/comment_3_c85c107a60b4b642ed9a8de7d233f95e._comment
new file mode 100644
index 000000000..87630445a
--- /dev/null
+++ b/doc/forum/which_version_should_I_install__63__/comment_3_c85c107a60b4b642ed9a8de7d233f95e._comment
@@ -0,0 +1,46 @@
+[[!comment format=mdwn
+ username="eric.w@eee65cd362d995ced72640c7cfae388ae93a4234"
+ nickname="eric.w"
+ avatar="http://cdn.libravatar.org/avatar/8d9808c12db3a3f93ff7f9e74c0870fc"
+ subject="make install failing for 8.20200309, any ideas as to why?"
+ date="2020-03-11T17:26:06Z"
+ content="""
+screen scrape below, I have no idea why it thinks that text file is locked, so weird.
+
+
+# git status
+HEAD detached at 8.20200309
+nothing to commit, working tree clean
+
+
+
+# make install PREFIX=/usr/local
+if [ \"cabal\" = ./Setup ]; then ghc --make Setup; fi
+if [ \"cabal\" != stack ]; then \
+	cabal configure  --ghc-options=\"\"; \
+else \
+	cabal setup ; \
+fi
+Warning: The configure command is a part of the legacy v1 style of cabal
+usage.
+
+Please switch to using either the new project style and the new-configure
+command or the legacy v1-configure alias as new-style projects will become the
+default in the next version of cabal-install. Please file a bug if you cannot
+replicate a working v1- use case with the new-style commands.
+
+For more information, see: https://wiki.haskell.org/Cabal/NewBuild
+
+Resolving dependencies...
+Warning: solver failed to find a solution:
+Could not resolve dependencies:
+[__0] trying: git-annex-8.20200309 (user goal)
+[__1] unknown package: filepath-bytestring (dependency of git-annex)
+[__1] fail (backjumping, conflict set: filepath-bytestring, git-annex)
+After searching the rest of the dependency tree exhaustively, these were the
+goals I've had most trouble fulfilling: git-annex, filepath-bytestring
+Trying configure anyway.
+./dist/setup/setup.version: openFile: resource busy (file is locked)
+make: *** [Makefile:37: tmp/configure-stamp] Error 1
+
+"""]]

diff --git a/doc/forum/which_version_should_I_install__63__/comment_2_b7ec6925fccf8653596ff0e13a2762ef._comment b/doc/forum/which_version_should_I_install__63__/comment_2_b7ec6925fccf8653596ff0e13a2762ef._comment
new file mode 100644
index 000000000..b7e6e7856
--- /dev/null
+++ b/doc/forum/which_version_should_I_install__63__/comment_2_b7ec6925fccf8653596ff0e13a2762ef._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="eric.w@eee65cd362d995ced72640c7cfae388ae93a4234"
+ nickname="eric.w"
+ avatar="http://cdn.libravatar.org/avatar/8d9808c12db3a3f93ff7f9e74c0870fc"
+ subject="comment 2"
+ date="2020-03-11T17:13:28Z"
+ content="""
+did he move it to hackage because this website is a train wreck or is there some other reason?
+
+I do appreciate the response btw, thank you.
+
+"""]]

diff --git a/doc/install/comment_9_b25b61f63a90b777e9669b36d9189f3c._comment b/doc/install/comment_9_b25b61f63a90b777e9669b36d9189f3c._comment
new file mode 100644
index 000000000..4b58fa675
--- /dev/null
+++ b/doc/install/comment_9_b25b61f63a90b777e9669b36d9189f3c._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="eric.w@eee65cd362d995ced72640c7cfae388ae93a4234"
+ nickname="eric.w"
+ avatar="http://cdn.libravatar.org/avatar/8d9808c12db3a3f93ff7f9e74c0870fc"
+ subject="where are the release notes for git annex?"
+ date="2020-03-11T17:09:46Z"
+ content="""
+and details like what are high level differences between v6 / v7 / v8?
+
+such as, is v7 \"stable\" and v8 \"beta\" ? this info seems to be no where on this site. 
+
+(git-annex/ assistant) has release notes, why do we have to go to (git-annex/news ?!?!!) for the same?
+
+I've been looking for this info for awhile now, I really don't get this omission. 
+"""]]

diff --git a/doc/forum/Preferred_contents_based_on_presence_in_repo/comment_4_ffda2c94cbccab1d462a4e333816773b._comment b/doc/forum/Preferred_contents_based_on_presence_in_repo/comment_4_ffda2c94cbccab1d462a4e333816773b._comment
new file mode 100644
index 000000000..125a79369
--- /dev/null
+++ b/doc/forum/Preferred_contents_based_on_presence_in_repo/comment_4_ffda2c94cbccab1d462a4e333816773b._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="erewhon"
+ avatar="http://cdn.libravatar.org/avatar/b9bd5ad7176ebe149d0f051dcfe0a63e"
+ subject="comment 4"
+ date="2020-03-11T16:11:54Z"
+ content="""
+Thanks for digging this out. It makes sense.
+"""]]

diff --git a/doc/bugs/Some_calls_to_git_repeat_--config_values.mdwn b/doc/bugs/Some_calls_to_git_repeat_--config_values.mdwn
new file mode 100644
index 000000000..9fbda78a0
--- /dev/null
+++ b/doc/bugs/Some_calls_to_git_repeat_--config_values.mdwn
@@ -0,0 +1,39 @@
+Some of git-annex's calls to git duplicate the `--config` values that
+are passed by the caller.  Here's an example:
+
+[[!format sh """
+cd "$(mktemp -d --tmpdir gx-XXXXXXX)"
+git init
+git annex init -c foo.bar=true --debug
+"""]]
+
+```
+[...]
+[2020-03-11 10:59:12.932497354] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","foo.bar=true","config","annex.uuid","ffad618f-a272-4d1b-8a5b-73778661ac1b"]
+[2020-03-11 10:59:12.934971688] process done ExitSuccess
+[2020-03-11 10:59:12.93926062] read: git ["config","--null","--list"]
+[2020-03-11 10:59:12.941719766] process done ExitSuccess
+[2020-03-11 10:59:12.942450637] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","foo.bar=true","-c","foo.bar=true","show-ref","git-annex"]
+[...]
+[2020-03-11 10:59:12.955818683] read: git ["config","--null","--list"]
+[2020-03-11 10:59:12.958211547] process done ExitSuccess
+[2020-03-11 10:59:12.958313557] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","foo.bar=true","-c","foo.bar=true","-c","foo.bar=true","status","--porcelain"]
+[2020-03-11 10:59:12.960857733] process done ExitSuccess
+[2020-03-11 10:59:12.960928142] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","foo.bar=true","-c","foo.bar=true","-c","foo.bar=true","config","filter.annex.smudge","git-annex smudge -- %f"]
+[2020-03-11 10:59:12.963408762] process done ExitSuccess
+[...]
+```
+
+Based on looking at the full output, it seems like a repeated
+`--config` value gets tacked on each time after the configuration is
+re-read.
+
+The above is with a git-annex built from 8.20200226-161-g1978a2420.  I
+see the same duplicates with a git-annex built from
+7.20190819-2-g908476a9b.
+
+Those extra values shouldn't cause any problems, but this issue seems
+worth filing in case there's a simple fix.
+
+[[!meta author=kyle]]
+[[!tag projects/datalad]]

diff --git a/doc/forum/File_history.mdwn b/doc/forum/File_history.mdwn
index bc172dbca..4f25c03c5 100644
--- a/doc/forum/File_history.mdwn
+++ b/doc/forum/File_history.mdwn
@@ -4,6 +4,7 @@ I'm having some trouble getting an understanding and visibility into the content
 `git log -p` reveals these changes as symlink changes under `.git/annex`.
 
 What I want is:
+
 1. Of a file, to see the changes to that file's content that have happened over time.
 2. Of a file, to be able to revert it to an older version of that file's content.
 3. Of a file, to get visibility into what versions of that file's content are available on what remotes.

diff --git a/doc/forum/File_history.mdwn b/doc/forum/File_history.mdwn
new file mode 100644
index 000000000..bc172dbca
--- /dev/null
+++ b/doc/forum/File_history.mdwn
@@ -0,0 +1,9 @@
+I'm having some trouble getting an understanding and visibility into the content history of the files managed by my git annex repository.
+
+`git log` shows changes to the files, but these changes are essentially just symlink changes.
+`git log -p` reveals these changes as symlink changes under `.git/annex`.
+
+What I want is:
+1. Of a file, to see the changes to that file's content that have happened over time.
+2. Of a file, to be able to revert it to an older version of that file's content.
+3. Of a file, to get visibility into what versions of that file's content are available on what remotes.

diff --git a/doc/bugs/upgrade_to_V8_fails/comment_9_eea7e7aaccded131b201acabfe8ac699._comment b/doc/bugs/upgrade_to_V8_fails/comment_9_eea7e7aaccded131b201acabfe8ac699._comment
new file mode 100644
index 000000000..6700a6aff
--- /dev/null
+++ b/doc/bugs/upgrade_to_V8_fails/comment_9_eea7e7aaccded131b201acabfe8ac699._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="scinu"
+ avatar="http://cdn.libravatar.org/avatar/c5a190c5c0ce61a5be141609dff37fe1"
+ subject="comment 9"
+ date="2020-03-11T04:51:17Z"
+ content="""
+yes, you're right
+"""]]