diff --git a/doc/bugs/Q__58___is_there_a_reason_to___34__sense__34___git_annex_post-receive_in_a_hook__63__.mdwn b/doc/bugs/Q__58___is_there_a_reason_to___34__sense__34___git_annex_post-receive_in_a_hook__63__.mdwn
new file mode 100644
index 0000000000..dd021a9828
--- /dev/null
+++ b/doc/bugs/Q__58___is_there_a_reason_to___34__sense__34___git_annex_post-receive_in_a_hook__63__.mdwn
@@ -0,0 +1,13 @@
+I looked into post-receive hook of an arbitrary git/git-annex repo to find
+
+[[!format sh """
+(git-annex)hopa:/tmp/testds/.git/hooks[master]
+$> cat post-receive           
+#!/bin/sh
+# automatically configured by git-annex
+if git annex post-receive --help >/dev/null 2>&1; then git annex post-receive; fi
+"""]]
+
+and wondered why it actually needs conditioning? `--help` runs for me longer (40-50ms) than actual `git annex post-receive` call (20ms) when there is nothing todo.  So I wondered why wasting time on `--help`?
+
+[[!meta author=yoh]]
diff --git a/doc/bugs/crippled_filesystem__58___SQLite3_returned_ErrorBusy/comment_6_21e8b47c5f100196f3d2062001a484d8._comment b/doc/bugs/crippled_filesystem__58___SQLite3_returned_ErrorBusy/comment_6_21e8b47c5f100196f3d2062001a484d8._comment
new file mode 100644
index 0000000000..97f617d22b
--- /dev/null
+++ b/doc/bugs/crippled_filesystem__58___SQLite3_returned_ErrorBusy/comment_6_21e8b47c5f100196f3d2062001a484d8._comment
@@ -0,0 +1,61 @@
+[[!comment format=mdwn
+ username="oliv5"
+ avatar="http://cdn.libravatar.org/avatar/d7f0d33c51583bbd8578e4f1f9f8cf4b"
+ subject="comment 6"
+ date="2019-09-26T20:39:41Z"
+ content="""
+The lock issue seems confirmed here. And the \"nobrl\" mount option solves the issue.
+
+Maybe you should inform the user about \"nobrl\" & \"annex.pidlock\" during the \"git annex init\" filesystem check, refuse to go on and propose legacy direct mode instead if user cannot accept to have no filesystem locking ?
+
+Without changing my mount options:
+
+    SQLite version 3.27.2 2019-02-25 16:06:06
+    Enter \".help\" for usage hints.
+    sqlite> PRAGMA journal_mode=WAL;
+    Error: database is locked
+    sqlite> create table foo (name varchar);
+    Error: database is locked
+    sqlite> insert into foo (name) values (\"joey\");
+    Error: no such table: foo
+    sqlite> .exit
+
+After adding \"nobrl\" in the mount options:
+
+    SQLite version 3.27.2 2019-02-25 16:06:06
+    Enter \".help\" for usage hints.
+    sqlite> PRAGMA journal_mode=WAL;
+    wal
+    sqlite> create table foo (name varchar);
+    sqlite> insert into foo (name) values (\"joey\");
+    sqlite> .exit
+
+It seems \"nolock\" is an alias for \"nobrl\", results are the same; when I put \"nolock\" in the mount options, I end up with \"nobrl\" in the \"mount\" command output.
+
+Finally, with the \"nobrl\" mount option:
+
+    $ cd /media/mydisk/tmp/
+    $ date > file1
+    $ git init .
+    Dépôt Git vide initialisé dans /media/mydisk/tmp/.git/
+    $ git annex init test
+    init test 
+      Detected a filesystem without fifo support.
+
+      Disabling ssh connection caching.
+
+      Detected a crippled filesystem.
+
+      Entering an adjusted branch where files are unlocked as this filesystem does not support locked files.
+
+    Basculement sur la branche 'adjusted/master(unlocked)'
+    ok
+    (recording state in git...)
+    $ git annex add file1 
+    add file1 ok
+    (recording state in git...)
+
+Hurray ! 
+
+
+"""]]
diff --git a/doc/forum/Preserving_the_v5_experience/comment_3_b15c92675cf6a5087ced6a649dd1b6c7._comment b/doc/forum/Preserving_the_v5_experience/comment_3_b15c92675cf6a5087ced6a649dd1b6c7._comment
new file mode 100644
index 0000000000..df902e16df
--- /dev/null
+++ b/doc/forum/Preserving_the_v5_experience/comment_3_b15c92675cf6a5087ced6a649dd1b6c7._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="smithclarkson001@2d22c4a26d6e52831b460b949377a8c9d6139a94"
+ nickname="smithclarkson001"
+ avatar="http://cdn.libravatar.org/avatar/e050ab885958a05800aa3360200e2ec1"
+ subject="comment 3"
+ date="2019-09-27T13:16:01Z"
+ content="""
+\"Having a annex.neverlock option that plain-out rejects adding files in locked mode\" -- did you mean unlocked mode?
+
+A related suggestion: auto-lock files after one edit
+
+Make sense.
+"""]]
diff --git a/doc/git-annex-unlock/comment_4_d04a1d4159306939b91a34fd17ab0325._comment b/doc/git-annex-unlock/comment_4_d04a1d4159306939b91a34fd17ab0325._comment
new file mode 100644
index 0000000000..64a8c2b83d
--- /dev/null
+++ b/doc/git-annex-unlock/comment_4_d04a1d4159306939b91a34fd17ab0325._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="tobiasBora"
+ avatar="http://cdn.libravatar.org/avatar/80a7d8c2a7b475b6b71198cce0faa6b0"
+ subject="Move file from git annex to just git in one commit"
+ date="2019-09-26T22:52:35Z"
+ content="""
+Hello. I'd like to know, how could I move back a file managed by git annex to a normal file (for example, say I added by mistake a text file in it). For now, I do `git unlock MYFILE`, then I remove the file from git: `git rm --cached MYFILE`, and `git commit -am 'Remove file'`, and finally I add back the file, `git add MYFILE && git commit -am 'File added back in git'`. However, this creates two commits, which is a bit annoying and leave the feeling that the file has been removed while it was just a kind of modification. How could I do that in less commands, and with a single commit?
+Thanks! 
+"""]]
diff --git a/doc/workflow/comment_2_67edac29c0e7b5a768511a0fd0878947._comment b/doc/workflow/comment_2_67edac29c0e7b5a768511a0fd0878947._comment
new file mode 100644
index 0000000000..26704ca5ad
--- /dev/null
+++ b/doc/workflow/comment_2_67edac29c0e7b5a768511a0fd0878947._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="why not git-annex-sync"
+ date="2019-09-26T17:47:55Z"
+ content="""
+Just curious, what makes you want to avoid using [[`git-annex-sync`|git-annex-sync]]?  Without it you'd need to manually sync the [[git-annex branch|internals#The_git-annex_branch]], and merge it using [[`git-annex-merge`|git-annex-merge]].
+
+\"what's the best way to get a repo's UUID\" -- [[`git-annex-info --fast`|git-annex-info]] prints it.
+"""]]