diff --git a/doc/bugs/Empty_files_make_git_status_slow/comment_5_e2c9b041388685bb2ada57244c1735fd._comment b/doc/bugs/Empty_files_make_git_status_slow/comment_5_e2c9b041388685bb2ada57244c1735fd._comment
new file mode 100644
index 0000000000..d61cb66e04
--- /dev/null
+++ b/doc/bugs/Empty_files_make_git_status_slow/comment_5_e2c9b041388685bb2ada57244c1735fd._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2019-08-28T16:05:53Z"
+ content="""
+Since it's not clear from the above, git only behaves this way when the
+empty file is unlocked. So `git annex lock` is a good workaround too.
+
+(Also, `git annex export` has since gotten the ability to export
+non-annexed files, for the record.)
+"""]]
diff --git a/doc/bugs/Massive_git_add_produces_sqlite_crashes.mdwn b/doc/bugs/Massive_git_add_produces_sqlite_crashes.mdwn
index 9e343c251c..1e7212dd6b 100644
--- a/doc/bugs/Massive_git_add_produces_sqlite_crashes.mdwn
+++ b/doc/bugs/Massive_git_add_produces_sqlite_crashes.mdwn
@@ -60,3 +60,9 @@ Oh yeah, I am still discovering this powerfull git annex tool.
In fact, collegues and I are forming a group during the process to exchange about different use cases, encountered problems and help each other.
[[!meta title="v7: intermittent sqlite ErrorIO crash (especially in WSL)"]]
+
+> This bug still exists, and there's a more recent bug report
+> documenting how it behaves in WSL now.
+>
+> So I don't think there's any point leaving this open, closing as a
+> duplicate. [[done]] --[[Joey]]
diff --git a/doc/bugs/v7_unlock_big_file__58___out_of_memory.mdwn b/doc/bugs/v7_unlock_big_file__58___out_of_memory.mdwn
index 7fdb2b378e..3ad892906b 100644
--- a/doc/bugs/v7_unlock_big_file__58___out_of_memory.mdwn
+++ b/doc/bugs/v7_unlock_big_file__58___out_of_memory.mdwn
@@ -82,3 +82,6 @@ fatal: Out of memory, realloc failed
Git Annex is unique piece of Art, there is nothing like it.
+
+> This bug got fixed in git. I just tested with 2.23 and verified it's
+> [[done]] --[[Joey]]
diff --git a/doc/todo/v7_path_toward_default.mdwn b/doc/todo/v7_path_toward_default.mdwn
index e1034c08a7..689b73e8c2 100644
--- a/doc/todo/v7_path_toward_default.mdwn
+++ b/doc/todo/v7_path_toward_default.mdwn
@@ -46,13 +46,21 @@ Since v5 repos and v7 repos not using unlocked files are functionally
almost identical, this is unlikely to break much. Unlocking files will of
course change behavior though.
-The only significant difference is that Annex.Content in v7
-reads and writes to the keys database. So any problem with the database
-code could prevent using git-annex. WSL has such a problem currently,
-but it doesn't seem to affect using v7 repos, only adjusted branches.
-
-(Actually, v5 does read and write to the keys database some too,
-though unncessarily so.)
+When not using unlocked files, the only significant difference is that
+Annex.Content in v7 reads and writes to the keys database. So any problem
+with the database code could prevent using git-annex.
+
+* WSL has such a problem currently,
+ but it doesn't seem to affect using v7 repos, only adjusted branches.
+
+* A 2016 bug reported the keys database not working on lustre,
+ presumably due to sqlite needing part of POSIX that lustre does not provide
+ or something.
+
+
+There are also some slight performance differences, but they go both ways,
+for example the pre-commit hook is faster in v7 than v5, but v7 runs git
+diff in reconcileStaged.
A concern is that a v5 repository may be used by multiple machines,
some not supporting v7 and some that do. If one upgrades to v7