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

doc/devblog/day_601__v7_default/comment_1_54af3bf0a521597d49bd8f8ef0ab5555._comment

@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="grawity@2ea26be48562f66fcb9b66307da72b1e2e37453f"
+ nickname="grawity"
+ avatar="http://cdn.libravatar.org/avatar/7003e967f47003bae82966aa373de8ef"
+ subject="Direct mode"
+ date="2019-09-15T09:57:57Z"
+ content="""
+I've been trying to have something resembling direct mode using the recommended \"adjusted branch\" feature (with annex.thin), and the results aren't really satisfactory:
+
+- If I use `annex adjust --unlock --hide-missing`, the non-present files are of course missing entirely. No convenient way to `annex get` them on demand.
+
+- If I use just `annex adjust --unlock`, or even if I permanently `annex unlock` everything, the non-present files still appear *as regular files* (containing /annex/objects inside), which makes it much harder to distinguish whether the file is present or absent. (In v5 direct mode, absent files appeared as broken symlinks.) Additionally, the adjust command is very slow, unlocking maybe 2–3 files per second (they're video files, approx. ~300MB each).
+
+I don't mind regular (indirect) mode in general, but unfortunately some apps just... don't like symlinks, so I want to have plain unlocked files at least on this particular clone of this particular repo. So it would be great if there was an adjusted branch mode kinda like `--hide-missing` but which kept missing files as broken symlinks just like the regular mode does.
+
+But if that's not possible, I think I'll be able to use `bindfs --resolve-symlinks` to achieve a similar result...
+"""]]

doc/news/version_7.20190912/comment_1_58351144b9da1dd19626ba9cdd7502d5._comment

@@ -0,0 +1,22 @@
+[[!comment format=sh
+ username="Michael"
+ avatar="http://cdn.libravatar.org/avatar/86811fdafa094c610ec8ef8858a78dbf"
+ subject=""Git is older than version 2.22""
+ date="2019-09-15T19:33:28Z"
+ content="""
+Installing 7.20190912 from the \"ancient\" tarball at https://downloads.kitenet.net/git-annex/linux/current/git-annex-standalone-i386-ancient.tar.gz on an x86 Synology NAS, I get
+
+$ git annex merge
+
+  Git is older than version 2.22 and so it has a memory leak that affects using unlocked files. Recommend you upgrade git before unlocking any files in your repository.
+merge git-annex ok
+git-annex: thread blocked indefinitely in an MVar operation
+
+$ which git
+/var/services/homes/michael/git-annex.linux/git
+
+$ /var/services/homes/michael/git-annex.linux/git --version
+git version 2.1.4
+
+Seems like included git is too old then?
+"""]]

doc/todo/remote-ready-command/comment_2_0e79b93a9c614a259b9a7d7c1f6cb6dc._comment

@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="forums+git-annex@d2ec818a5e37440c45fa5f3cbd82fe5110b32020"
+ nickname="forums+git-annex"
+ avatar="http://cdn.libravatar.org/avatar/b6fde94dbf127b822f7b6109399d50c9"
+ subject="comment 2"
+ date="2019-09-13T23:17:37Z"
+ content="""
+> I wonder, what about downloads from the remote, those could also overload some remote.
+
+That is a good point, but it's not needed for my use case; KBFS hasn't had any trouble so far keeping up with reading data, only with writing.
+
+> Is your KBFS remote an external special remote, or are you just using a directory special remote on that filesystem? If it were an external special remote, you could just make it delay until ready when it receives a TRANSFER request.
+
+I originally had a directory special remote pointing to the FUSE-mounted KBFS, but I was having some issues with that, so I switched to an rsync special remote (also pointing to FUSE-mounted KBFS).
+
+> (BTW, the solution to each git-annex copy creating a git-annex branch commit is annex.alwayscommit=false. Or perhaps usng --batch to drive a single copy command.)
+
+Awesome, looks like either of those would be better workarounds than I have right now.  Thanks!
+"""]]