diff --git a/doc/forum/git-annex-sync_without_syncing_master/comment_5_a125638afe0cf57fe97e6051da943406._comment b/doc/forum/git-annex-sync_without_syncing_master/comment_5_a125638afe0cf57fe97e6051da943406._comment
new file mode 100644
index 000000000..115c9ea42
--- /dev/null
+++ b/doc/forum/git-annex-sync_without_syncing_master/comment_5_a125638afe0cf57fe97e6051da943406._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="Nick_P"
+ avatar="http://cdn.libravatar.org/avatar/abf8aa3ac1a976a6a292416b9c604581"
+ subject="comment 5"
+ date="2020-02-18T10:17:25Z"
+ content="""
+(repeat with corrected formatting)
+
+I think the new `git annex sync --only-annex` will replace the last three lines of my sequence above. I aim to experiment to confirm that.
+
+<https://git-annex.branchable.com/todo/sync_--branches__to_sync_only_specified_branches___40__e.g._git-annex__41__/#comment-52dbdba2331659011519bcc4bda4cf18>
+"""]]

diff --git a/doc/forum/git-annex-sync_without_syncing_master/comment_4_a8f681ec33f2fef16b9b8eb6633f8fe4._comment b/doc/forum/git-annex-sync_without_syncing_master/comment_4_a8f681ec33f2fef16b9b8eb6633f8fe4._comment
new file mode 100644
index 000000000..582d294c7
--- /dev/null
+++ b/doc/forum/git-annex-sync_without_syncing_master/comment_4_a8f681ec33f2fef16b9b8eb6633f8fe4._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="Nick_P"
+ avatar="http://cdn.libravatar.org/avatar/abf8aa3ac1a976a6a292416b9c604581"
+ subject="comment 4"
+ date="2020-02-18T10:15:13Z"
+ content="""
+I think the new 'git annex sync --only-annex' will replace the last three lines of my sequence above. I aim to experiment to confirm that.
+
+https://git-annex.branchable.com/todo/sync_--branches__to_sync_only_specified_branches___40__e.g._git-annex__41__/#comment-52dbdba2331659011519bcc4bda4cf18
+"""]]

diff --git a/doc/todo/sync_--branches__to_sync_only_specified_branches___40__e.g._git-annex__41__/comment_8_6c683fcba5d69a4c0051eb42b8c558a0._comment b/doc/todo/sync_--branches__to_sync_only_specified_branches___40__e.g._git-annex__41__/comment_8_6c683fcba5d69a4c0051eb42b8c558a0._comment
new file mode 100644
index 000000000..cd0785691
--- /dev/null
+++ b/doc/todo/sync_--branches__to_sync_only_specified_branches___40__e.g._git-annex__41__/comment_8_6c683fcba5d69a4c0051eb42b8c558a0._comment
@@ -0,0 +1,48 @@
+[[!comment format=mdwn
+ username="Dan"
+ avatar="http://cdn.libravatar.org/avatar/986de9e060699ae70ff7c31342393adc"
+ subject="An overdue and overlong reply"
+ date="2020-02-17T22:59:19Z"
+ content="""
+It looks like this functionality was implemented before I could get my comment writen, but I thought it might be useful to post it anyway. It seems like the implementing changes are now in master, so if I build from source I'll get these new features, right? I assume they'll also make it into the next release of git-annex (at which point I'll version bump at homebrew, which is what I'm having my students use to install git-annex).
+
+Thanks for your thoughtful response. I also agree that having an --only-annex option is perfectly satisfactory and more nuanced --branch-to-sync options are probably overkill. As to whether --only-annex should imply --content, I'm more agnostic and defer to your wisdom. However, if I call git-annex with --only-annex --no-content, will it push/pull the git-annex branches and leave the content alone? From looking at your commit message, it sounds like there is now a --not-only-annex option which can override a configured only-annex property, but it's not clear how --no-content might enter the picture.
+
+Let me try to finish my dangling thought from the last comment thread. For clarity, I'll introduce some labels for repositories and assume the only people working on this project are me (Dan) and two students, Alice and Bob. Let Dan-local refer to the repository on my laptop (and similar for {Alice,Bob}-local), let Dan-github refer to my repo on GitHub, and {Alice,Bob}-github refer to my student's forks. Dan has push access to {Dan,Alice,Bob}-github. Alice and Bob can fetch from {Dan,Alice,Bob}-github, but can *only* push to their own github repositories (Alice can push to Alice-github, Bob to Bob-github).
+
+Without an --only-annex option, I have two primary concerns. The first is the thought I left dangling, which I'll now complete:
+Throughout this process I'm trying to teach them how to use git-annex (it's pretty clearly the right tool for the job :) ) but need to be really careful with what git annex sync commands I encourage them to run since I don't want them to inadvertantly pull changes into their local branches (especially integrating changes from one another) and then wind up being confused as to how things got there. Like many newcomers to git, they're still at the rote learning stage where they are memorizing commands to type and are still developing a mental model of what's happening when they fetch/pull/push. For this reason, I think that avoiding their local branches changing as a side-effect of a git-annex command (i.e., by specifying this option in the config that travels in git-annex branch) will make it easier for them to understand base git. There's some risk that they'll learn bad git-annex habits from this and be surprised at all the things git annex sync does when they use it elsewhere, but for now it seems easier to help them understand git but use git-annex mechanically, and once they're comfortable with that I can help them to understand what git-annex is actually doing and the nuances of git annex sync.
+
+The second problem is that because I'm the only one with push access to Dan-GitHub, everything has to get there either via a pull request (which I  can accept after review) or I need to push it there myself via Dan-local. In particular, to keep the git-annex branch in Dan-GitHub up to date, I need to be integrating {Alice,Bob}-github/git-annex (or perhaps synced/git-annex?) into Dan-local/git-annex and then push it to Dan-GitHub/git-annex. I can do this manually, but it's a lot of typing (especially if there are many more students than just Alice and Bob), so git annex sync seems like a nice way to accomplish this. However, it has the side effect of *also* pulling in {Alice,Bob}-GitHub/{synced/master,master} and then pushing that up to Dan-GitHub/synced/master, and if Alice and Bob are also running git annex sync, changes from Alice will show up in Bob-local/master and vice versa. Moreover, if they're also pushing e.g. Alice-local/master -> Alice-GitHub/master, their pull requests will suddenly get very noisy as they'll incorporate more than just their own changes, and for them to remedy this it will require careful use of git reset which is a dangerous command for them to run at this stage of their learning.
+
+Git that I am, after running git annex sync I saw that my Dan-local/master was now ahead of Dan-GitHub/master, and I foolishly pushed, which now plopped half-baked code from Alice and Bob into the primary branch of our primary repository on github.
+It also had the unfortunate side-effect of closing out open pull requests from Alice and Bob (since github saw that their changes were now reachable from Dan-Github/master). I did some reset-ing, git annex sync --cleanup, and some force pushes to clean everything up before Alice or Bob could fetch, so other than having to re-open their pull requests, this didn't screw them up too much.
+
+
+Finally, I want to clarify my understanding of the synced/branch workflow, which seems clever but I never fully understood it. From some simple experimenting (I have not waded very far into the source code), it seems that if I just run git annex sync (with no flags and assuming I haven't configured anything to do otherwise), and assuming that BRANCH is checked out locally, it will do the following, *I think*:
+
+1. Stage and commit any changes in tracked files
+1. Merge synced/BRANCH into BRANCH
+2. Loop over remotes, for each
+   2. Pull from the remote (seems like it just fetches all branches)
+   2. Merge REMOTE/BRANCH into BRANCH
+   3. If REMOTE/synced/BRANCH exists, merge it into BRANCH
+7. Do octopus merge of all REMOTE/git-annex and REMOTE/synced/git-annex branches into local git-annex branch
+4. Loop over remotes again, for each
+   5. Push git-annex -> REMOTE/synced/git-annex
+   6. Push git-annex -> REMOTE/git-annex
+   6. Push BRANCH -> REMOTE/synced/BRANCH
+
+
+
+
+I'm a little confused by what the synced/git-annex branches are for, but I suppose they're even less likely to ever be checkoued out that git-annex and provide a safeguard. I *think* they will be included in the octopus merge described above.
+
+Step 3.2 (merge REMOTE/BRANCH into BRANCH) was a surprise to me based on my reading of the git annex sync documentation since I only expected it to only integrate changes from REMOTE/synced/BRANCH.
+
+
+It seems like neither the sync documentation on [branchable](https://git-annex.branchable.com/sync/) nor what is obtained with `man git-annex-sync` enumerate all of these steps, although reading them together gives an almost complete picture of what is going on. Since the documentation suggests the end user can just run these steps manually as an alternative to using `git annex sync`, it seems like it'd be helpful to very concretely document what those steps are.
+I'd be happy to take a crack at updating the documentation to be more thorough, but wanted to make sure I actually understand what is going on before doing so. 
+
+Again, I want to re-articulate how much I enjoy git annex and how difficult it would be to do any sort of version control for our data without it. I deeply appreciate the time and energy that you put into this very valuable and useful tool.
+"""]]

diff --git a/Assistant/Sync.hs b/Assistant/Sync.hs
index 4a90b0994..a69064936 100644
--- a/Assistant/Sync.hs
+++ b/Assistant/Sync.hs
@@ -164,7 +164,7 @@ pushToRemotes' now remotes = do
 		updatemap succeeded failed
 		return failed
 		
-	push branch remote = Command.Sync.pushBranch remote branch
+	push branch remote = Command.Sync.pushBranch remote (Just branch)
 
 parallelPush :: Git.Repo -> [Remote] -> (Remote -> Git.Repo -> IO Bool)-> Assistant ([Remote], [Remote])
 parallelPush g rs a = do
diff --git a/CHANGELOG b/CHANGELOG
index 4f442ca95..dca27dea6 100644
--- a/CHANGELOG
+++ b/CHANGELOG
@@ -1,5 +1,9 @@
 git-annex (7.20200205) UNRELEASED; urgency=medium
 
+  * Added sync --only-annex, which syncs the git-annex branch and annexed
+    content but leaves managing the other git branches up to you.
+  * Added annex.synconlyannex git config setting, which can also be set with
+    git-annex config to configure sync in all clones of the repo.
   * fsck --from remote: Fix a concurrency bug that could make it incorrectly
     detect that content in the remote is corrupt, and remove it, resulting in
     data loss.
diff --git a/Command/Merge.hs b/Command/Merge.hs
index 79d028ec8..fe1119dc8 100644
--- a/Command/Merge.hs
+++ b/Command/Merge.hs
@@ -12,7 +12,7 @@ import qualified Annex.Branch
 import qualified Git
 import qualified Git.Branch
 import Annex.CurrentBranch
-import Command.Sync (prepMerge, mergeLocal, mergeConfig, merge)
+import Command.Sync (prepMerge, mergeLocal, mergeConfig, merge, SyncOptions(..))
 
 cmd :: Command
 cmd = command "merge" SectionMaintenance
@@ -41,4 +41,5 @@ mergeSyncedBranch = mergeLocal mergeConfig def =<< getCurrentBranch
 mergeBranch :: Git.Ref -> CommandStart
 mergeBranch r = starting "merge" (ActionItemOther (Just (Git.fromRef r))) $ do
 	currbranch <- getCurrentBranch
-	next $ merge currbranch mergeConfig def Git.Branch.ManualCommit r
+	let o = def { notOnlyAnnexOption = True }
+	next $ merge currbranch mergeConfig o Git.Branch.ManualCommit r
diff --git a/Command/PostReceive.hs b/Command/PostReceive.hs
index 096cc87e4..0202fef7b 100644
--- a/Command/PostReceive.hs
+++ b/Command/PostReceive.hs
@@ -14,7 +14,7 @@ import qualified Annex
 import Git.Types
 import Annex.UpdateInstead
 import Annex.CurrentBranch
-import Command.Sync (mergeLocal, prepMerge, mergeConfig)
+import Command.Sync (mergeLocal, prepMerge, mergeConfig, SyncOptions(..))
 
 -- This does not need to modify the git-annex branch to update the 
 -- work tree, but auto-initialization might change the git-annex branch.
@@ -51,4 +51,5 @@ fixPostReceiveHookEnv = do
 updateInsteadEmulation :: CommandStart
 updateInsteadEmulation = do
 	prepMerge
-	mergeLocal mergeConfig def =<< getCurrentBranch
+	let o = def { notOnlyAnnexOption = True }
+	mergeLocal mergeConfig o =<< getCurrentBranch
diff --git a/Command/Sync.hs b/Command/Sync.hs
index 341d169d9..8a052ef27 100644
--- a/Command/Sync.hs
+++ b/Command/Sync.hs
@@ -1,7 +1,7 @@
 {- git-annex command
  -
  - Copyright 2011 Joachim Breitner <mail@joachim-breitner.de>
- - Copyright 2011-2019 Joey Hess <id@joeyh.name>
+ - Copyright 2011-2020 Joey Hess <id@joeyh.name>
  -
  - Licensed under the GNU AGPL version 3 or higher.
  -}
@@ -24,6 +24,7 @@ module Command.Sync (
 	syncBranch,
 	updateBranches,
 	seekExportContent,
+	SyncOptions(..),
 ) where
 
 import Command
@@ -78,8 +79,10 @@ cmd = withGlobalOptions [jobsOption] $
 		"synchronize local repository with remotes"
 		(paramRepeating paramRemote) (seek <--< optParser)
 
-data SyncOptions  = SyncOptions
+data SyncOptions = SyncOptions
 	{ syncWith :: CmdParams
+	, onlyAnnexOption :: Bool
+	, notOnlyAnnexOption :: Bool
 	, commitOption :: Bool
 	, noCommitOption :: Bool
 	, messageOption :: Maybe String
@@ -90,13 +93,26 @@ data SyncOptions  = SyncOptions
 	, contentOfOption :: [FilePath]
 	, cleanupOption :: Bool
 	, keyOptions :: Maybe KeyOptions
-	, resolveMergeOverride :: ResolveMergeOverride
+	, resolveMergeOverride :: Bool
 	}
 
-newtype ResolveMergeOverride = ResolveMergeOverride Bool
-
-instance Default ResolveMergeOverride where
-	def = ResolveMergeOverride False
+instance Default SyncOptions where
+	def = SyncOptions
+		{ syncWith = []
+		, onlyAnnexOption = False
+		, notOnlyAnnexOption = False
+		, commitOption = False
+		, noCommitOption = False
+		, messageOption = Nothing
+		, pullOption = False
+		, pushOption = False
+		, contentOption = False
+		, noContentOption = False
+		, contentOfOption = []
+		, cleanupOption = False
+		, keyOptions = Nothing
+		, resolveMergeOverride = False
+		}
 
 optParser :: CmdParamsDesc -> Parser SyncOptions
 optParser desc = SyncOptions
@@ -104,6 +120,15 @@ optParser desc = SyncOptions
 		( metavar desc
 		<> completeRemotes
 		))
+	<*> switch 
+		( long "only-annex"
+		<> short 'a'
+		<> help "only sync git-annex branch and annexed file contents"
+		)
+	<*> switch 
+		( long "not-only-annex"
+		<> help "sync git branches as well as annex"
+		)
 	<*> switch
 		( long "commit"
 		<> help "commit changes to git"
@@ -124,16 +149,16 @@ optParser desc = SyncOptions
 		)
 	<*> switch 
 		( long "content"
-		<> help "transfer file contents" 
+		<> help "transfer annexed file contents" 
 		)
 	<*> switch
 		( long "no-content"
-		<> help "do not transfer file contents"
+		<> help "do not transfer annexed file contents"
 		)
 	<*> many (strOption
 		( long "content-of"
 		<> short 'C'
-		<> help "transfer file contents of files in a given location"
+		<> help "transfer contents of annexed files in a given location"
 		<> metavar paramPath
 		))
 	<*> switch
@@ -141,15 +166,17 @@ optParser desc = SyncOptions
 		<> help "remove synced/ branches from previous sync"
 		)
 	<*> optional parseAllOption
-	<*> (ResolveMergeOverride <$> invertableSwitch "resolvemerge" True
+	<*> invertableSwitch "resolvemerge" True
 		( help "do not automatically resolve merge conflicts"
-		))
+		)
 
 -- Since prepMerge changes the working directory, FilePath options
 -- have to be adjusted.
 instance DeferredParseClass SyncOptions where
 	finishParse v = SyncOptions
 		<$> pure (syncWith v)
+		<*> pure (onlyAnnexOption v)
+		<*> pure (notOnlyAnnexOption v)
 		<*> pure (commitOption v)
 		<*> pure (noCommitOption v)
 		<*> pure (messageOption v)
@@ -189,7 +216,7 @@ seek' o = do
 			-- These actions cannot be run concurrently.
 			mapM_ includeCommandAction $ concat
 				[ [ commit o ]
-				, [ withbranch (mergeLocal mergeConfig (resolveMergeOverride o)) ]
+				, [ withbranch (mergeLocal mergeConfig o) ]
 				, map (withbranch . pullRemote o mergeConfig) gitremotes
 				,  [ mergeAnnex ]
 				]
@@ -215,13 +242,14 @@ seek' o = do
 						, [ commitAnnex, mergeAnnex ]
 						]

(Diff truncated)

diff --git a/doc/contribute/comment_5_c5f7f809da5829f4c259d0a630f0f722._comment b/doc/contribute/comment_5_c5f7f809da5829f4c259d0a630f0f722._comment
new file mode 100644
index 000000000..72378f3e7
--- /dev/null
+++ b/doc/contribute/comment_5_c5f7f809da5829f4c259d0a630f0f722._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Dan"
+ avatar="http://cdn.libravatar.org/avatar/986de9e060699ae70ff7c31342393adc"
+ subject="Thanks"
+ date="2020-02-17T17:52:20Z"
+ content="""
+Got it! In this case, since the [conversation](https://git-annex.branchable.com/todo/sync_--branches__to_sync_only_specified_branches___40__e.g._git-annex__41__/#comment-a232b074bb04a942903468cf0d7a13b1) has now moved on, I'll just complete my thought in reply to your most recent comment, but I'll use the workflow you suggested in the future if I need to edit a comment.
+"""]]

diff --git a/doc/todo/sync_--branches__to_sync_only_specified_branches___40__e.g._git-annex__41__/comment_6_15e336ea35f0233e22f7c5b656b616d2._comment b/doc/todo/sync_--branches__to_sync_only_specified_branches___40__e.g._git-annex__41__/comment_6_15e336ea35f0233e22f7c5b656b616d2._comment
new file mode 100644
index 000000000..bb5af0160
--- /dev/null
+++ b/doc/todo/sync_--branches__to_sync_only_specified_branches___40__e.g._git-annex__41__/comment_6_15e336ea35f0233e22f7c5b656b616d2._comment
@@ -0,0 +1,56 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""Re: Still wanted (update with example)"""
+ date="2020-02-17T17:15:10Z"
+ content="""
+@Dan, thanks for explaining your use case.
+
+In particular, I see why you don't want to pull their master
+branches with the unfinished whatever, but do want to pull
+their git-annex branch, and probably fetch their feature branches
+too.
+
+I'm still unclear on why, after merging someone's feature
+branch into your branch (master I suppose), you would not
+want sync to push that updated branch back to origin? Is the issue not
+about pushing master to origin, but that you don't want it to push 
+master to their forks? But if their forks contain other changes in
+their master branches, it would not overwrite the changes.
+
+It does seem like setting remote.name.fetch would work in your use case,
+but I also understand why you might not want to use it -- refspecs are
+hard! -- and when you're dealing with feature branches that might be named
+anything, it's hard to write a refspec that does what you want, other than
+one that fetches everything and merges nothing.
+
+So I do see the appeal of a git-annex sync --only-annex that separates
+concerns, letting you use whatever git commands you normally would to
+commit and pull and push everything, except for the git-annex branch.
+
+And, that name implies it also syncs the annexed content, so no need to
+remember to use --content with it. (I want --content to be sync default,
+but there are backcompat issues with that so annex.synccontent is only an
+option.)
+
+Soo, I'm leaning toward adding that option and not some other --branches
+option that lists branches to sync or whatever.
+
+----
+
+And, since `git-annex config` can set repo-wide annex.synccontent and
+annex.autocommit that change the behavior of `git-annex sync`,
+it could make sense to also have a setting that enables --only-annex
+by default. I don't know if I'd encourage setting that in your repo though;,
+it might teach the students a non-standard git-annex behavior.
+Re that, it would be helpful if you could finish this interrupted
+thought of yours:
+
+> Throughout this process I'm trying to teach them how to use git-annex (it's
+> pretty clearly the right tool for the job :) but need to be really careful
+> with what `git annex sync` commands I encourage them to run since I don't
+> want the, 
+
+Because I'm not yet seeing how any use of git-annex sync by the students
+could be problimatic; it won't be able to push their master branch
+to your repo or anything.
+"""]]

diff --git a/doc/contribute/comment_4_21a75c774757f27911a9249f9b42368d._comment b/doc/contribute/comment_4_21a75c774757f27911a9249f9b42368d._comment
new file mode 100644
index 000000000..fe091d91d
--- /dev/null
+++ b/doc/contribute/comment_4_21a75c774757f27911a9249f9b42368d._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""@Dan"""
+ date="2020-02-17T17:05:03Z"
+ content="""
+That might be an ikiwiki issue, because you're supposed to be able to git
+push any change that a user could make on the web, and I think anyone can
+delete a comment and then make a new comment in its place. Probably
+two pushes would work ... or just copy and then delete the comment and paste
+into a new comment.
+"""]]

diff --git a/doc/tips/automatically_adding_metadata/comment_11_6eeb21b66aa3541491ddc0dd3058ddc7._comment b/doc/tips/automatically_adding_metadata/comment_11_6eeb21b66aa3541491ddc0dd3058ddc7._comment
new file mode 100644
index 000000000..ad09dd636
--- /dev/null
+++ b/doc/tips/automatically_adding_metadata/comment_11_6eeb21b66aa3541491ddc0dd3058ddc7._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""re: adding support for additional metadata tools?"""
+ date="2020-02-17T16:55:20Z"
+ content="""
+@max, notice that the hook script contains special case handling for
+exiftool, including a config option for it. That was contributed by
+Klaus Ethgen. I'd be inclined to merge patches that add handling
+for other tools.
+
+I imagine you could add config settings for the format string etc.
+"""]]

diff --git a/doc/bugs/annex.genmetadata_should_default_to_true.mdwn b/doc/bugs/annex.genmetadata_should_default_to_true.mdwn
index afc004ed0..5aef50d45 100644
--- a/doc/bugs/annex.genmetadata_should_default_to_true.mdwn
+++ b/doc/bugs/annex.genmetadata_should_default_to_true.mdwn
@@ -9,3 +9,5 @@ Add a file to a fresh annex, observe it has no metadata.
 
 ### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
 Yes I love it! (Except for its spotty timestamp support)
+
+> [[notabug|done]] --[[Joey]]
diff --git a/doc/bugs/annex.genmetadata_should_default_to_true/comment_5_8cd47851ca76005e0011da7c2f62d77d._comment b/doc/bugs/annex.genmetadata_should_default_to_true/comment_5_8cd47851ca76005e0011da7c2f62d77d._comment
new file mode 100644
index 000000000..69f6444e6
--- /dev/null
+++ b/doc/bugs/annex.genmetadata_should_default_to_true/comment_5_8cd47851ca76005e0011da7c2f62d77d._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2020-02-17T16:47:33Z"
+ content="""
+I agree with Ilya's points.
+
+And it's unresonable to characterize this as data loss, because git itself
+does not store file timestamp data. Making such mischaracterizations does,
+however, cause me, as the maintainer, to wonder if this is a feature that
+is worth keeping, since I have no interest in descending that rabbit hole
+or fighting such accusations. Generally, going to the strongest possible
+argument, when requesting a change, is not actually your best move.
+
+Closing this bug report.
+"""]]

diff --git a/doc/bugs/warning_about_ssh_caching_keeps_showing/comment_5_24f7717029ef520f932123130088d76d._comment b/doc/bugs/warning_about_ssh_caching_keeps_showing/comment_5_24f7717029ef520f932123130088d76d._comment
new file mode 100644
index 000000000..5dfc6d355
--- /dev/null
+++ b/doc/bugs/warning_about_ssh_caching_keeps_showing/comment_5_24f7717029ef520f932123130088d76d._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2020-02-17T16:29:58Z"
+ content="""
+I think the idea with detecting at build time is that if git-annex is being
+built on a platform where ssh doesn't support it, eg because it's not
+openssh but some other ssh implementation, it might as well compile out
+support rather than fail obscurely when it tries to use it. And it's
+uncommon for the systems where a program is built and used to have
+different ssh implementations, so runtime probing would only slow it
+down. (git-annex makes similar assumptions about eg, `cp --reflink` being
+supported or not, and I don't think it's very unusual to probe OS features
+at compile time.)
+
+The warning seems useful, because here we've discovered that you have been
+building git-annex without support for ssh caching all along!
+
+The way to disable the warning is to set annex.sshcaching=true
+(after [[!commit a4909470688287fc0009eaf82dab2e108bd214f1]]).
+"""]]

diff --git a/doc/special_remotes/comment_41_26a29fe6169eee1c62dd10672040851c._comment b/doc/special_remotes/comment_41_26a29fe6169eee1c62dd10672040851c._comment
new file mode 100644
index 000000000..6d46a8c6a
--- /dev/null
+++ b/doc/special_remotes/comment_41_26a29fe6169eee1c62dd10672040851c._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 41"""
+ date="2020-02-17T16:26:45Z"
+ content="""
+@giuly.ippoliti this is not the best place to ask.. 
+[[design/external_special_remote_protocol]] is a better place to discuss
+special remote implementation.
+
+Anyway, git-annex's --quiet option will shut up the INFO.
+DEBUG is only ever displayed when you use the --debug option.
+ERROR should only be used if you have a problem that the user is going to
+care about seeing.
+"""]]

diff --git a/doc/todo/provide_machine_readable___40__--json__63____41___version_of_initremote_--whatelse/comment_1_5ed9864ef616d9e9b77a3d62561363fd._comment b/doc/todo/provide_machine_readable___40__--json__63____41___version_of_initremote_--whatelse/comment_1_5ed9864ef616d9e9b77a3d62561363fd._comment
new file mode 100644
index 000000000..f5065c546
--- /dev/null
+++ b/doc/todo/provide_machine_readable___40__--json__63____41___version_of_initremote_--whatelse/comment_1_5ed9864ef616d9e9b77a3d62561363fd._comment
@@ -0,0 +1,24 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2020-02-17T16:06:26Z"
+ content="""
+My design process for this feature included almost getting stuck on wanting
+some kind of types for the values, and way to track which options are
+required, or exclusive of other options, or dependencies of other options,
+etc. All stuff that eg, an applicative option parser can support quite
+well, but it would complicate the external protocol enourmously, if it
+could be represented at all in it. So I had to eliminate all that.
+
+I think it's fairly uncommon for tab completion to do anything special
+about required parameters, or even mutually exclusive options (although
+git-annex tab completion does handle the latter), and while I can imagine
+a gui interface marking an input field as required, it seems
+that would be the least of its problems if it doesn't know what kind of
+control to use for the field?
+
+It would be easy to add --whatelse-json, but it would be limited to the
+name, a description of the purpose of the field, and maybe a description
+of the expected value or list of valid values.
+I'm unsure about the utility of that..
+"""]]

diff --git a/doc/todo/some_way_to_get_a_list_of_options_for_a_special_remote_of_a_given_type/comment_3_b75ffc63f0e9a85c3d1f01bdce21c97c._comment b/doc/todo/some_way_to_get_a_list_of_options_for_a_special_remote_of_a_given_type/comment_3_b75ffc63f0e9a85c3d1f01bdce21c97c._comment
new file mode 100644
index 000000000..34ccd48f6
--- /dev/null
+++ b/doc/todo/some_way_to_get_a_list_of_options_for_a_special_remote_of_a_given_type/comment_3_b75ffc63f0e9a85c3d1f01bdce21c97c._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2020-02-17T15:57:28Z"
+ content="""
+I stuggled with naming this option. I did consider something 
+with "config" (redundant with other configs), or "parameter"
+or "option" (redundant with other options). It was 
+--describe-other-params for a while but that was too long to type.
+
+--help would be the best name, but tying it into the main option parser is
+impractical; amoung other things it would make tab completion need to
+somehow run external special remotes to get a list of their parameters!
+
+The mnemonic for --whatelse, such as it is: You've gotten at least as
+far as type= (without which it won't work and will prompt for that),
+and want to know what else you can configure.
+"""]]

diff --git a/doc/todo/Don__39__t_re-encrypt_when_key_is_already_in_.git__47__annex__47__tmp/comment_1_0650918c86fca0554755aede19a12fd3._comment b/doc/todo/Don__39__t_re-encrypt_when_key_is_already_in_.git__47__annex__47__tmp/comment_1_0650918c86fca0554755aede19a12fd3._comment
new file mode 100644
index 000000000..01ebb8c02
--- /dev/null
+++ b/doc/todo/Don__39__t_re-encrypt_when_key_is_already_in_.git__47__annex__47__tmp/comment_1_0650918c86fca0554755aede19a12fd3._comment
@@ -0,0 +1,53 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2020-02-17T15:33:31Z"
+ content="""
+@lykos, what happens when git-annex-remote-googledrive tries
+to resume in this situation and git-annex has written a different tmp file
+than what it partially uploaded before?
+
+I imagine it might resume after the last byte it sent before, and so
+the uploaded file gets corrupted?
+
+If so, there are two hard problems with this idea:
+
+1. If git-annex changes to reuse the same tmp file, then git-annex-remote-googledrive
+   will work with the new git-annex, but corrupt files when used with an old
+   git-annex.
+2. If someone has two clones, and starts an upload in one, but it's 
+   interrupted and then started later in the second clone, it would again
+   corrupt the file that gets uploaded. (This would also happen,
+   with a single clone, if git-annex unused gets used in between upload
+   attempts, and cleans up the tmp file.)
+
+The first could be dealt with by some protocol flag, but the second seems
+rather intractable, if git-annex-remote-googledrive behaves as I
+hypothesize it might. And even if git-annex-remote-googledrive behaves
+better that that somehow, it's certianly likely that some other remote
+would behave that way at some point.
+
+----
+
+As to implementation details, I started investigating before thinking
+about the above problem, so am leaving some notes here:
+
+This would first require that the tmp file is written atomically,
+otherwise an interruption in the wrong place would resume with a partial
+file. (File size can't be used since gpg changes the file size with
+compression etc.) Seems easy to implement: Make
+Remote.Helper.Special.fileStorer write to a different tmp file and rename
+it into place. 
+
+Internally, git-annex pipes the content from gpg, so it is only written to
+a temp file when using a remote that operates on files, as the external
+remotes do. Some builtin remotes don't. So resuming an upload to an
+encrypted remote past the chunk level can't work in general.
+
+There would need to be some way for the code that encrypts chunks
+(or whole objects) to detect that it's being used with a remote that
+operates on files, and then check if the tmp file already exists, and avoid
+re-writing it. This would need some way to examine a `Storer` and tell
+if it operates on files, which is not currently possisble, so would need
+some change to the data type.
+"""]]

diff --git a/doc/bugs/warning_about_ssh_caching_keeps_showing/comment_4_ab823204f02dd26ebfe0613f711e0f9d._comment b/doc/bugs/warning_about_ssh_caching_keeps_showing/comment_4_ab823204f02dd26ebfe0613f711e0f9d._comment
new file mode 100644
index 000000000..9a029fefb
--- /dev/null
+++ b/doc/bugs/warning_about_ssh_caching_keeps_showing/comment_4_ab823204f02dd26ebfe0613f711e0f9d._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="comment 4"
+ date="2020-02-16T04:05:11Z"
+ content="""
+Yes, I meant external remotes.
+"""]]

diff --git a/doc/bugs/warning_about_ssh_caching_keeps_showing/comment_3_49182db51bd86f0c60fadde5e4643f77._comment b/doc/bugs/warning_about_ssh_caching_keeps_showing/comment_3_49182db51bd86f0c60fadde5e4643f77._comment
new file mode 100644
index 000000000..0b8e66f30
--- /dev/null
+++ b/doc/bugs/warning_about_ssh_caching_keeps_showing/comment_3_49182db51bd86f0c60fadde5e4643f77._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 3"
+ date="2020-02-15T04:45:01Z"
+ content="""
+Ilya, you wrote \"the ability to easily write your own external **backends** has been especially helpful\".  Did you mean \"external **remotes**\"? since \"external backends\" are yet [TODO AFAIK](https://git-annex.branchable.com/todo/external_backends/)
+"""]]

diff --git a/doc/bugs/warning_about_ssh_caching_keeps_showing/comment_2_43b651b09b91986d5cb4ae14c83017c7._comment b/doc/bugs/warning_about_ssh_caching_keeps_showing/comment_2_43b651b09b91986d5cb4ae14c83017c7._comment
new file mode 100644
index 000000000..c2335f2b1
--- /dev/null
+++ b/doc/bugs/warning_about_ssh_caching_keeps_showing/comment_2_43b651b09b91986d5cb4ae14c83017c7._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="ssh caching"
+ date="2020-02-14T20:53:27Z"
+ content="""
+\"your build of git-annex may have been made without ssh connection caching support, which would happen if its configure program detected at build time that ssh doesn't support it\" -- yes, according to the [build log](https://dev.azure.com/conda-forge/84710dde-1620-425b-80d0-4cf5baca359d/_apis/build/builds/117561/logs/8).  I can add an ssh dependency to the conda-forge git-annex recipe.  It would be more flexible to not have that dependency and instead to have git-annex's behavior depend on the ssh available at runtime; but, I guess there's a reason it's a compile-time option?
+
+Also, I don't have ssh prompting for passwords since I use ssh-agent, and having the warning shown every time is distracting.  Maybe, a config option could be added to disable the warning?
+"""]]

diff --git a/doc/special_remotes/comment_40_2a36f9c874b00fd5de94836e3dcde782._comment b/doc/special_remotes/comment_40_2a36f9c874b00fd5de94836e3dcde782._comment
new file mode 100644
index 000000000..9f71e141f
--- /dev/null
+++ b/doc/special_remotes/comment_40_2a36f9c874b00fd5de94836e3dcde782._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="giuly.ippoliti@c1e2f0d5e40b128900f94f3d107d3719f87c3ff7"
+ nickname="giuly.ippoliti"
+ avatar="http://cdn.libravatar.org/avatar/4444ce1930af68fd817e9649d40e0359"
+ subject="Disable git annex logs"
+ date="2020-02-14T19:39:26Z"
+ content="""
+Hi,
+
+So while writing the globus special remote (git-annex-remote-globus) I often redirect my logs to annex. Nevertheless these logs are always logged out in the console, them being INFO, ERROR, DEBUG and I would like to control that. Is there a way to disable console logging of logs sent back to git annex?
+
+Something like ANNEX_LOG_LEVEL=self.annex.ERROR
+
+Thanks !!
+
+Regards
+Giulia
+"""]]

diff --git a/Annex/Branch.hs b/Annex/Branch.hs
index 6934e62ba..91d0276da 100644
--- a/Annex/Branch.hs
+++ b/Annex/Branch.hs
@@ -577,10 +577,11 @@ performTransitionsLocked jl ts neednewlocalbranch transitionedrefs = do
 	 -}
 	run [] = noop
 	run changers = do
+		config <- Annex.getGitConfig
 		trustmap <- calcTrustMap <$> getStaged trustLog
 		remoteconfigmap <- calcRemoteConfigMap <$> getStaged remoteLog
 		-- partially apply, improves performance
-		let changers' = map (\c -> c trustmap remoteconfigmap) changers
+		let changers' = map (\c -> c config trustmap remoteconfigmap) changers
 		fs <- branchFiles
 		forM_ fs $ \f -> do
 			content <- getStaged f
diff --git a/Annex/Branch/Transitions.hs b/Annex/Branch/Transitions.hs
index 3041d54b3..72c593c11 100644
--- a/Annex/Branch/Transitions.hs
+++ b/Annex/Branch/Transitions.hs
@@ -22,6 +22,7 @@ import Types.TrustLevel
 import Types.UUID
 import Types.MetaData
 import Types.Remote
+import Types.GitConfig
 import Types.ProposedAccepted
 import Annex.SpecialRemote.Config
 
@@ -35,7 +36,7 @@ data FileTransition
 	= ChangeFile Builder
 	| PreserveFile
 
-type TransitionCalculator = TrustMap -> M.Map UUID RemoteConfig -> RawFilePath -> L.ByteString -> FileTransition
+type TransitionCalculator = GitConfig -> TrustMap -> M.Map UUID RemoteConfig -> RawFilePath -> L.ByteString -> FileTransition
 
 getTransitionCalculator :: Transition -> Maybe TransitionCalculator
 getTransitionCalculator ForgetGitHistory = Nothing
@@ -54,7 +55,7 @@ getTransitionCalculator ForgetDeadRemotes = Just dropDead
 -- is not removed from the remote log, for the same reason the trust log
 -- is not changed.
 dropDead :: TransitionCalculator
-dropDead trustmap remoteconfigmap f content = case getLogVariety f of
+dropDead config trustmap remoteconfigmap f content = case getLogVariety config f of
 	Just OldUUIDBasedLog
 		| f == trustLog -> PreserveFile
 		| f == remoteLog -> ChangeFile $
diff --git a/CHANGELOG b/CHANGELOG
index 227f74805..4f442ca95 100644
--- a/CHANGELOG
+++ b/CHANGELOG
@@ -9,6 +9,9 @@ git-annex (7.20200205) UNRELEASED; urgency=medium
     be used, to clearly state why.
   * Avoid throwing fatal errors when asked to write to a readonly
     git remote on http.
+  * Fix support for repositories tuned with annex.tune.branchhash1=true,
+    including --all not working and git-annex log not displaying anything
+    for annexed files.
 
  -- Joey Hess <id@joeyh.name>  Fri, 14 Feb 2020 14:12:25 -0400
 
diff --git a/Command/Log.hs b/Command/Log.hs
index 397e6068d..5597bfbf4 100644
--- a/Command/Log.hs
+++ b/Command/Log.hs
@@ -210,6 +210,7 @@ getAllLog = getGitLog []
 
 getGitLog :: [FilePath] -> [CommandParam] -> Annex ([RefChange], IO Bool)
 getGitLog fs os = do
+	config <- Annex.getGitConfig
 	(ls, cleanup) <- inRepo $ pipeNullSplit $
 		[ Param "log"
 		, Param "-z"
@@ -220,7 +221,7 @@ getGitLog fs os = do
 		[ Param $ Git.fromRef Annex.Branch.fullname
 		, Param "--"
 		] ++ map Param fs
-	return (parseGitRawLog (map decodeBL' ls), cleanup)
+	return (parseGitRawLog config (map decodeBL' ls), cleanup)
 
 -- Parses chunked git log --raw output, which looks something like:
 --
@@ -236,8 +237,8 @@ getGitLog fs os = do
 --
 -- The timestamp is not included before all changelines, so
 -- keep track of the most recently seen timestamp.
-parseGitRawLog :: [String] -> [RefChange]
-parseGitRawLog = parse epoch
+parseGitRawLog :: GitConfig -> [String] -> [RefChange]
+parseGitRawLog config = parse epoch
   where
 	epoch = toEnum 0 :: POSIXTime
 	parse oldts ([]:rest) = parse oldts rest
@@ -250,7 +251,7 @@ parseGitRawLog = parse epoch
 			(tss, cl') -> (parseTimeStamp tss, cl')
 	  	mrc = do
 			(old, new) <- parseRawChangeLine cl
-			key <- locationLogFileKey (toRawFilePath c2)
+			key <- locationLogFileKey config (toRawFilePath c2)
 			return $ RefChange
 				{ changetime = ts
 				, oldref = old
diff --git a/Logs.hs b/Logs.hs
index 5faec561e..906f40679 100644
--- a/Logs.hs
+++ b/Logs.hs
@@ -1,6 +1,6 @@
 {- git-annex log file names
  -
- - Copyright 2013-2019 Joey Hess <id@joeyh.name>
+ - Copyright 2013-2020 Joey Hess <id@joeyh.name>
  -
  - Licensed under the GNU AGPL version 3 or higher.
  -}
@@ -27,8 +27,8 @@ data LogVariety
 
 {- Converts a path from the git-annex branch into one of the varieties
  - of logs used by git-annex, if it's a known path. -}
-getLogVariety :: RawFilePath -> Maybe LogVariety
-getLogVariety f
+getLogVariety :: GitConfig -> RawFilePath -> Maybe LogVariety
+getLogVariety config f
 	| f `elem` topLevelOldUUIDBasedLogs = Just OldUUIDBasedLog
 	| f `elem` topLevelNewUUIDBasedLogs = Just NewUUIDBasedLog
 	| isRemoteStateLog f = Just NewUUIDBasedLog
@@ -36,7 +36,7 @@ getLogVariety f
 	| isChunkLog f = ChunkLog <$> extLogFileKey chunkLogExt f
 	| isRemoteMetaDataLog f = Just RemoteMetaDataLog
 	| isMetaDataLog f || f `elem` otherLogs = Just OtherLog
-	| otherwise = PresenceLog <$> firstJust (presenceLogs f)
+	| otherwise = PresenceLog <$> firstJust (presenceLogs config f)
 
 {- All the old-format uuid-based logs stored in the top of the git-annex branch. -}
 topLevelOldUUIDBasedLogs :: [RawFilePath]
@@ -61,10 +61,10 @@ topLevelNewUUIDBasedLogs =
 
 
 {- All the ways to get a key from a presence log file -}
-presenceLogs :: RawFilePath -> [Maybe Key]
-presenceLogs f =
+presenceLogs :: GitConfig -> RawFilePath -> [Maybe Key]
+presenceLogs config f =
 	[ urlLogFileKey f
-	, locationLogFileKey f
+	, locationLogFileKey config f
 	]
 
 {- Top-level logs that are neither UUID based nor presence logs. -}
@@ -218,8 +218,17 @@ urlLogFileKey :: RawFilePath -> Maybe Key
 urlLogFileKey = extLogFileKey urlLogExt
 
 {- Converts a pathname into a key if it's a location log. -}
-locationLogFileKey :: RawFilePath -> Maybe Key
-locationLogFileKey path
-	-- Want only xx/yy/foo.log, not .log files in other places.
-	| length (splitDirectories (fromRawFilePath path)) /= 3 = Nothing
+locationLogFileKey :: GitConfig -> RawFilePath -> Maybe Key
+locationLogFileKey config path
+	| length (splitDirectories (fromRawFilePath path)) /= locationLogFileDepth config = Nothing
 	| otherwise = extLogFileKey ".log" path
+
+{- Depth of location log files within the git-annex branch.
+ -
+ - Normally they are xx/yy/key.log so depth 3. 
+ - The same extension is also used for other logs that
+ - are not location logs. -}
+locationLogFileDepth :: GitConfig -> Int
+locationLogFileDepth config = hashlevels + 1
+  where
+        HashLevels hashlevels = branchHashLevels config
diff --git a/Logs/Location.hs b/Logs/Location.hs
index 66532ae41..2c3439805 100644
--- a/Logs/Location.hs
+++ b/Logs/Location.hs
@@ -130,8 +130,10 @@ loggedKeys :: Annex [Unchecked Key]
 loggedKeys = loggedKeys' (not <$$> checkDead)
 
 loggedKeys' :: (Key -> Annex Bool) -> Annex [Unchecked Key]
-loggedKeys' check = mapMaybe (defercheck <$$> locationLogFileKey)
-	<$> Annex.Branch.files
+loggedKeys' check = do
+	config <- Annex.getGitConfig
+	mapMaybe (defercheck <$$> locationLogFileKey config)
+		<$> Annex.Branch.files
   where
 	defercheck k = Unchecked $ ifM (check k)
 		( return (Just k)
diff --git a/Upgrade/V2.hs b/Upgrade/V2.hs
index e255403d5..4a70a05d1 100644
--- a/Upgrade/V2.hs
+++ b/Upgrade/V2.hs
@@ -67,16 +67,17 @@ upgrade = do
 
 locationLogs :: Annex [(Key, FilePath)]
 locationLogs = do
+	config <- Annex.getGitConfig
 	dir <- fromRepo gitStateDir
 	liftIO $ do
 		levela <- dirContents dir
 		levelb <- mapM tryDirContents levela

(Diff truncated)

diff --git a/doc/bugs/git_annex_copy_fails_without_error_message_on_macOS___40__but_works_on_Linux__41__.mdwn b/doc/bugs/git_annex_copy_fails_without_error_message_on_macOS___40__but_works_on_Linux__41__.mdwn
index 86ebd3357..c971feb82 100644
--- a/doc/bugs/git_annex_copy_fails_without_error_message_on_macOS___40__but_works_on_Linux__41__.mdwn
+++ b/doc/bugs/git_annex_copy_fails_without_error_message_on_macOS___40__but_works_on_Linux__41__.mdwn
@@ -17,3 +17,5 @@ The same command worked on the linux boxes I set up a few days ago.
 The problem really is that I am getting no meaningful error message for triaging this problem.
 
 Any help would be appreciated!
+
+[[!tag moreinfo]]

diff --git a/CHANGELOG b/CHANGELOG
index 5b624ad37..227f74805 100644
--- a/CHANGELOG
+++ b/CHANGELOG
@@ -1,5 +1,8 @@
 git-annex (7.20200205) UNRELEASED; urgency=medium
 
+  * fsck --from remote: Fix a concurrency bug that could make it incorrectly
+    detect that content in the remote is corrupt, and remove it, resulting in
+    data loss.
   * When git-annex is built with a ssh that does not support ssh connection
     caching, default annex.sshcaching to false, but let the user override it.
   * Improve warning messages further when ssh connection caching cannot
diff --git a/Command/Fsck.hs b/Command/Fsck.hs
index 65c0112ea..cee57c763 100644
--- a/Command/Fsck.hs
+++ b/Command/Fsck.hs
@@ -1,6 +1,6 @@
 {- git-annex command
  -
- - Copyright 2010-2019 Joey Hess <id@joeyh.name>
+ - Copyright 2010-2020 Joey Hess <id@joeyh.name>
  -
  - Licensed under the GNU AGPL version 3 or higher.
  -}
@@ -161,6 +161,11 @@ performRemote key afile backend numcopies remote =
 		]
 	ai = mkActionItem (key, afile)
 	withtmp a = do
+		-- Put it in the gitAnnexTmpObjectDir since that's on a
+		-- filesystem where object temp files are normally
+		-- stored. The pid prevents multiple fsck processes
+		-- contending over the same file. (Multiple threads cannot,
+		-- because OnlyActionOn is used.)
 		pid <- liftIO getPID
 		t <- fromRepo gitAnnexTmpObjectDir
 		createAnnexDirectory t
@@ -541,7 +546,7 @@ badContentRemote remote localcopy key = do
 
 runFsck :: Incremental -> ActionItem -> Key -> Annex Bool -> CommandStart
 runFsck inc ai key a = stopUnless (needFsck inc key) $
-	starting "fsck" ai $ do
+	starting "fsck" (OnlyActionOn key ai) $ do
 		ok <- a
 		when ok $
 			recordFsckTime inc key
diff --git a/doc/bugs/Parallel_fsck_on_files_with_same_content_in_bup_remote_can_fail.mdwn b/doc/bugs/Parallel_fsck_on_files_with_same_content_in_bup_remote_can_fail.mdwn
index 80ab6b52e..d631ae5a4 100644
--- a/doc/bugs/Parallel_fsck_on_files_with_same_content_in_bup_remote_can_fail.mdwn
+++ b/doc/bugs/Parallel_fsck_on_files_with_same_content_in_bup_remote_can_fail.mdwn
@@ -145,3 +145,5 @@ whereis file2 (1 copy)
   	5d9b0df2-000b-4273-bc4a-fb3b9d8319bd -- testrepo [here]
 ok
 """]]
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/bugs/Parallel_fsck_on_files_with_same_content_in_bup_remote_can_fail/comment_1_8cc0d742cd59046b038879f4823c9639._comment b/doc/bugs/Parallel_fsck_on_files_with_same_content_in_bup_remote_can_fail/comment_1_8cc0d742cd59046b038879f4823c9639._comment
new file mode 100644
index 000000000..755f2bbf5
--- /dev/null
+++ b/doc/bugs/Parallel_fsck_on_files_with_same_content_in_bup_remote_can_fail/comment_1_8cc0d742cd59046b038879f4823c9639._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2020-02-14T18:49:07Z"
+ content="""
+Ugh, I think this could potentially result in data loss. Not when using bup, 
+but other special remotes.
+
+I've fixed it in git and will think about moving the date of the next
+release up.
+"""]]

diff --git a/CHANGELOG b/CHANGELOG
index 55a721781..5b624ad37 100644
--- a/CHANGELOG
+++ b/CHANGELOG
@@ -4,6 +4,8 @@ git-annex (7.20200205) UNRELEASED; urgency=medium
     caching, default annex.sshcaching to false, but let the user override it.
   * Improve warning messages further when ssh connection caching cannot
     be used, to clearly state why.
+  * Avoid throwing fatal errors when asked to write to a readonly
+    git remote on http.
 
  -- Joey Hess <id@joeyh.name>  Fri, 14 Feb 2020 14:12:25 -0400
 
diff --git a/Remote/Git.hs b/Remote/Git.hs
index ea07c0e4c..ca7edc383 100644
--- a/Remote/Git.hs
+++ b/Remote/Git.hs
@@ -432,7 +432,9 @@ dropKey' repo r (State connpool duc _ _) key
 				return True
 		, return False
 		)
-	| Git.repoIsHttp repo = giveup "dropping from http remote not supported"
+	| Git.repoIsHttp repo = do
+		warning "dropping from http remote not supported"
+		return False
 	| otherwise = commitOnCleanup repo r $ do
 		let fallback = Ssh.dropKey repo key
 		P2PHelper.remove (Ssh.runProto r connpool (return False) fallback) key
@@ -536,7 +538,9 @@ copyFromRemote'' repo forcersync r st@(State connpool _ _ _) key file dest meter
 		else P2PHelper.retrieve
 			(\p -> Ssh.runProto r connpool (return (False, UnVerified)) (fallback p))
 			key file dest meterupdate
-	| otherwise = giveup "copying from non-ssh, non-http remote not supported"
+	| otherwise = do
+		warning "copying from non-ssh, non-http remote not supported"
+		unVerified (return False)
   where
 	fallback p = unVerified $ feedprogressback $ \p' -> do
 		oh <- mkOutputHandlerQuiet
@@ -649,7 +653,9 @@ copyToRemote' repo r st@(State connpool duc _ _) key file meterupdate
 			(\p -> Ssh.runProto r connpool (return False) (copyremotefallback p))
 			key file meterupdate
 		
-	| otherwise = giveup "copying to non-ssh repo not supported"
+	| otherwise = do
+		warning "copying to non-ssh repo not supported"
+		return False
   where
 	copylocal Nothing = return False
 	copylocal (Just (object, checksuccess)) = do
diff --git a/doc/bugs/Remote_Tests__58___storeKey_fails_for_http_remotes___40__skip_instead__63____41__.mdwn b/doc/bugs/Remote_Tests__58___storeKey_fails_for_http_remotes___40__skip_instead__63____41__.mdwn
index e0736c978..217385e65 100644
--- a/doc/bugs/Remote_Tests__58___storeKey_fails_for_http_remotes___40__skip_instead__63____41__.mdwn
+++ b/doc/bugs/Remote_Tests__58___storeKey_fails_for_http_remotes___40__skip_instead__63____41__.mdwn
@@ -78,3 +78,8 @@ It's possible there's another issue here I'm not entirely aware of.
 ### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
 
 Of course!  I use and rely on it daily :)
+
+> This is not a bug in the test suite, it turns out, but in
+> git-annex's handling of a http remote. It was throwing fatal errors
+> rather than the correct behavior of displaying a warning. [[fixed|done]]
+> --[[Joey]]

diff --git a/Annex/Ssh.hs b/Annex/Ssh.hs
index 7d3d99a57..8304e04c1 100644
--- a/Annex/Ssh.hs
+++ b/Annex/Ssh.hs
@@ -98,46 +98,31 @@ consumeStdinParams NoConsumeStdin = [Param "-n"]
 {- Returns a filename to use for a ssh connection caching socket, and
  - parameters to enable ssh connection caching. -}
 sshCachingInfo :: (SshHost, Maybe Integer) -> Annex (Maybe FilePath, [CommandParam])
-sshCachingInfo (host, port) = go =<< sshCacheDir
+sshCachingInfo (host, port) = go =<< sshCacheDir'
   where
-	go (Just dir) =
+	go (Right dir) =
 		liftIO (bestSocketPath $ dir </> hostport2socket host port) >>= return . \case
 			Nothing -> (Nothing, [])
 			Just socketfile -> (Just socketfile, sshConnectionCachingParams socketfile)
 	-- No connection caching with concurrency is not a good
 	-- combination, so warn the user.
-	go Nothing = do
+	go (Left whynocaching) = do
 		Annex.getState Annex.concurrency >>= \case
                 	NonConcurrent -> return ()
-			Concurrent {} -> warnnocaching
-			ConcurrentPerCpu -> warnnocaching
+			Concurrent {} -> warnnocaching whynocaching
+			ConcurrentPerCpu -> warnnocaching whynocaching
 		return (Nothing, [])
 	
-	warnnocaching = do
+	warnnocaching whynocaching = do
 		warning nocachingwarning
-		ifM (fromMaybe True . annexSshCaching <$> Annex.getGitConfig)
-			( whenM crippledFileSystem $
-				warning crippledfswarning
-			, warning enablecachingwarning
-			)
+		warning whynocaching
 	
 	nocachingwarning = unwords
-		[ "You have enabled concurrency, but ssh connection caching"
-		, "is not enabled. This may result in multiple ssh processes"
-		, "prompting for passwords at the same time."
-		]
-	
-	crippledfswarning = unwords
-		[ "This repository is on a crippled filesystem, so unix named"
-		, "pipes probably don't work, and ssh connection caching"
-		, "relies on those. One workaround is to set"
-		, sshSocketDirEnv
-		, "to point to a directory on a non-crippled filesystem."
-		, "(Or, disable concurrency.)"
+		[ "You have enabled concurrency, but git-annex is not able"
+		, "to use ssh connection caching. This may result in"
+		, "multiple ssh processes prompting for passwords at the"
+		, "same time."
 		]
-	
-	enablecachingwarning = 
-		"Enable annex.sshcaching (or disable concurrency) to avoid this problem."
 
 {- Given an absolute path to use for a socket file,
  - returns whichever is shorter of that or the relative path to the same
@@ -172,22 +157,37 @@ sshSocketDirEnv = "GIT_ANNEX_SSH_SOCKET_DIR"
 {- ssh connection caching creates sockets, so will not work on a
  - crippled filesystem. -}
 sshCacheDir :: Annex (Maybe FilePath)
-sshCacheDir
-	| BuildInfo.sshconnectioncaching = 
-		ifM (fromMaybe True . annexSshCaching <$> Annex.getGitConfig)
-			( ifM crippledFileSystem
-				( maybe (return Nothing) usetmpdir =<< gettmpdir
-				, Just <$> fromRepo gitAnnexSshDir 
-				)
-			, return Nothing
+sshCacheDir = eitherToMaybe <$> sshCacheDir'
+
+sshCacheDir' :: Annex (Either String FilePath)
+sshCacheDir' = 
+	ifM (fromMaybe BuildInfo.sshconnectioncaching . annexSshCaching <$> Annex.getGitConfig)
+		( ifM crippledFileSystem
+			( gettmpdir >>= \case
+				Nothing ->
+					return (Left crippledfswarning)
+				Just tmpdir -> 
+					liftIO $ catchMsgIO $
+						usetmpdir tmpdir
+			, Right <$> fromRepo gitAnnexSshDir 
 			)
-	| otherwise = return Nothing
+		, return (Left "annex.sshcaching is not set to true")
+		)
   where
 	gettmpdir = liftIO $ getEnv sshSocketDirEnv
-	usetmpdir tmpdir = liftIO $ catchMaybeIO $ do
+
+	usetmpdir tmpdir = do
 		let socktmp = tmpdir </> "ssh"
 		createDirectoryIfMissing True socktmp
 		return socktmp
+	
+	crippledfswarning = unwords
+		[ "This repository is on a crippled filesystem, so unix named"
+		, "pipes probably don't work, and ssh connection caching"
+		, "relies on those. One workaround is to set"
+		, sshSocketDirEnv
+		, "to point to a directory on a non-crippled filesystem."
+		]
 
 portParams :: Maybe Integer -> [CommandParam]
 portParams Nothing = []
diff --git a/CHANGELOG b/CHANGELOG
index 788047113..55a721781 100644
--- a/CHANGELOG
+++ b/CHANGELOG
@@ -1,3 +1,12 @@
+git-annex (7.20200205) UNRELEASED; urgency=medium
+
+  * When git-annex is built with a ssh that does not support ssh connection
+    caching, default annex.sshcaching to false, but let the user override it.
+  * Improve warning messages further when ssh connection caching cannot
+    be used, to clearly state why.
+
+ -- Joey Hess <id@joeyh.name>  Fri, 14 Feb 2020 14:12:25 -0400
+
 git-annex (7.20200204) upstream; urgency=medium
 
   * Fix build with persistent-template 2.8.0.
diff --git a/doc/bugs/warning_about_ssh_caching_keeps_showing.mdwn b/doc/bugs/warning_about_ssh_caching_keeps_showing.mdwn
index 370be161a..987a853cd 100644
--- a/doc/bugs/warning_about_ssh_caching_keeps_showing.mdwn
+++ b/doc/bugs/warning_about_ssh_caching_keeps_showing.mdwn
@@ -55,3 +55,5 @@ local repository version: 7
 I've been using git-annex for 1.5 years to manage bioinformatics analyses.  It's a very versatile and well-designed tool.  I've been able to adapt it to many use cases;
 the ability to easily write your own external backends has been especially helpful for that.  The amount of work and thought that has gone into designing/building git-annex is
 enormous, and very much appreciated.
+
+> [[done]]; see comment --[[Joey]]
diff --git a/doc/bugs/warning_about_ssh_caching_keeps_showing/comment_1_711a8e784ba8fde0164469fa08176687._comment b/doc/bugs/warning_about_ssh_caching_keeps_showing/comment_1_711a8e784ba8fde0164469fa08176687._comment
new file mode 100644
index 000000000..b09d81c48
--- /dev/null
+++ b/doc/bugs/warning_about_ssh_caching_keeps_showing/comment_1_711a8e784ba8fde0164469fa08176687._comment
@@ -0,0 +1,25 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2020-02-14T17:48:41Z"
+ content="""
+It seems you must have annex.jobs set to something, since concurrency
+is enabled without any -J option, so the easy fix is just to unset that.
+
+It kind of looks like your build of git-annex may have been made without
+ssh connection caching support, which would happen if its configure program
+detected at build time that ssh doesn't support it.
+
+That would be unusual if so, all the builds of git-annex that I'm aware of
+are made with ssh that does support it.
+
+There are a couple of even less likely scenarios, like
+`GIT_ANNEX_SSH_SOCKET_DIR` being set to a directory you can't write to.
+
+I've changed the code to always say explicitly why ssh caching can't be
+enabled. I also let annex.sshcaching override the build-time detection.
+
+I guess that's enough to close this, unless it turns out its
+reasons for not enabling it are not one of those I mentioned above, but
+something entirely bogus.
+"""]]

diff --git a/doc/todo/some_way_to_get_a_list_of_options_for_a_special_remote_of_a_given_type/comment_2_96fae68472f7f9ef720c27149556f7a0._comment b/doc/todo/some_way_to_get_a_list_of_options_for_a_special_remote_of_a_given_type/comment_2_96fae68472f7f9ef720c27149556f7a0._comment
new file mode 100644
index 000000000..47fd2773d
--- /dev/null
+++ b/doc/todo/some_way_to_get_a_list_of_options_for_a_special_remote_of_a_given_type/comment_2_96fae68472f7f9ef720c27149556f7a0._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 2"
+ date="2020-02-14T17:20:27Z"
+ content="""
+Sweet, thanks for the feature!
+
+I wondered, why `--whatelse` which has no semantic relation to \"parameter\" or \"config\", and not something like `--help-params`, `--help-configs`, or `--listconfigs` to relate it to either PARAMS (as --help reports configs) or LISTCONFIGS protocol command?
+"""]]

diff --git a/doc/todo/provide_machine_readable___40__--json__63____41___version_of_initremote_--whatelse.mdwn b/doc/todo/provide_machine_readable___40__--json__63____41___version_of_initremote_--whatelse.mdwn
new file mode 100644
index 000000000..8e32ba0d4
--- /dev/null
+++ b/doc/todo/provide_machine_readable___40__--json__63____41___version_of_initremote_--whatelse.mdwn
@@ -0,0 +1,59 @@
+<details>
+<summary>ATM it is a formatted text (click to expand)</summary> 
+
+```shell
+$> git annex initremote myrsync type=rsync --whatelse
+shellescape
+	avoid usual shell escaping (not recommended)
+	(yes or no)
+rsyncurl
+	(required) url or hostname:/directory for rsync to use
+chunk
+	size of chunks (eg, 1MiB)
+encryption
+	how to encrypt data stored in the special remote
+	(hybrid or none or pubkey or shared or sharedpubkey)
+embedcreds
+	embed credentials into git repository
+	(yes or no)
+mac
+	how to encrypt filenames used on the remote
+	(HMACSHA1 or HMACSHA224 or HMACSHA256 or HMACSHA384 or HMACSHA512)
+keyid
+	gpg key id
+keyid+
+	add additional gpg key
+keyid-
+	remove gpg key
+exporttree
+	export trees of files to this remote
+	(yes or no)
+importtree
+	import trees of files from this remote
+	(yes or no)
+```
+</details>
+
+which would make it necessary to establish a possibly fragile parsing by any tool which would like to programmatically obtain/use/expose those options.
+
+It would be great if there was a way to trigger such listing be output in more friendly for machines form? e.g. a json dictionary alike
+
+```json
+{
+ "rsyncurl": {
+   "required": True,
+   "description": "url or hostname:/directory for rsync to use"
+ },
+ "shellescape": {
+   "description": "avoid usual shell escaping (not recommended)",
+   "choices": ["yes", "no"]
+   },
+   ...
+}
+```
+
+Looking at the [protocol](https://git-annex.branchable.com/design/external_special_remote_protocol/) I see no indication of "required" or "choices" to be actually explicitly provided by the remote fields, so I guess just supposed to be included in the text, so may be given current state of things, aforementioned dictionary would be simply ```{"NAME": "DESCRIPTION"}```,  which someone makes this proposed TODO less valuable.
+
+
+[[!meta author=yoh]]
+[[!tag projects/datalad]]

diff --git a/doc/forum/Transparent_compression_of_files/comment_2_a75e32b0825de0b405c45de14b9711c0._comment b/doc/forum/Transparent_compression_of_files/comment_2_a75e32b0825de0b405c45de14b9711c0._comment
new file mode 100644
index 000000000..a1ba8b4d4
--- /dev/null
+++ b/doc/forum/Transparent_compression_of_files/comment_2_a75e32b0825de0b405c45de14b9711c0._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="jochen.keil@38b1f86ab65128dab3e62e726403ceee4f5141bf"
+ nickname="jochen.keil"
+ avatar="http://cdn.libravatar.org/avatar/a1329c0b3a262017553cc5497aa12c18"
+ subject="comment 2"
+ date="2020-02-14T12:04:53Z"
+ content="""
+Thanks for your hint, I appretiate that and I think it could be done that way.
+
+However, on closer thought I was wondering if git-annex is the right tool for job. I had the impression that my idea came more from a hammer and nail situation. So, FUSE came to my mind. I popped it into google and found this: https://github.com/FS-make-simple/fusecompress
+Unfortunately this does not look very active though.
+
+Now, since I'm already at the FS layer I can look into ZFS compression. My repos are already on ZFS but I haven't looked at the built-in compression yet. I think I'll evaluate that first. If none of that is satisfactory I'll turn to git-annex again :)
+"""]]

diff --git a/doc/contribute/comment_4_de4d251bac610f1ed65556eb94534f52._comment b/doc/contribute/comment_4_de4d251bac610f1ed65556eb94534f52._comment
deleted file mode 100644
index 0eaf0fe3c..000000000
--- a/doc/contribute/comment_4_de4d251bac610f1ed65556eb94534f52._comment
+++ /dev/null
@@ -1,10 +0,0 @@
-[[!comment format=mdwn
- username="Dan"
- avatar="http://cdn.libravatar.org/avatar/986de9e060699ae70ff7c31342393adc"
- subject="Editing Comments?"
- date="2020-02-14T01:23:12Z"
- content="""
-Is it possible to edit comments on the branchable wiki? I realized there was a sentence I failed to finish when posting [this comment](https://git-annex.branchable.com/todo/sync_--branches__to_sync_only_specified_branches___40__e.g._git-annex__41__/#comment-19feab1afb2e0b33315a8368a7cdebf7) and I'd love to go back and finish the thought. The \"Edit\" button at the top of the page lets me edit the content of the page, but not any of the comments.
-
-I tried cloning the wiki, editing the file corresponding to my comment, and then pushing, but the push was rejected (the changes were in doc tree so I expected it to be accepted, but perhaps comments are more locked down).
-"""]]

diff --git a/doc/contribute/comment_4_de4d251bac610f1ed65556eb94534f52._comment b/doc/contribute/comment_4_de4d251bac610f1ed65556eb94534f52._comment
new file mode 100644
index 000000000..0eaf0fe3c
--- /dev/null
+++ b/doc/contribute/comment_4_de4d251bac610f1ed65556eb94534f52._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="Dan"
+ avatar="http://cdn.libravatar.org/avatar/986de9e060699ae70ff7c31342393adc"
+ subject="Editing Comments?"
+ date="2020-02-14T01:23:12Z"
+ content="""
+Is it possible to edit comments on the branchable wiki? I realized there was a sentence I failed to finish when posting [this comment](https://git-annex.branchable.com/todo/sync_--branches__to_sync_only_specified_branches___40__e.g._git-annex__41__/#comment-19feab1afb2e0b33315a8368a7cdebf7) and I'd love to go back and finish the thought. The \"Edit\" button at the top of the page lets me edit the content of the page, but not any of the comments.
+
+I tried cloning the wiki, editing the file corresponding to my comment, and then pushing, but the push was rejected (the changes were in doc tree so I expected it to be accepted, but perhaps comments are more locked down).
+"""]]

diff --git a/doc/contribute/comment_3_e7219514f52207fcfb97aeec03241e8d._comment b/doc/contribute/comment_3_e7219514f52207fcfb97aeec03241e8d._comment
new file mode 100644
index 000000000..513f6e5ae
--- /dev/null
+++ b/doc/contribute/comment_3_e7219514f52207fcfb97aeec03241e8d._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="Dan"
+ avatar="http://cdn.libravatar.org/avatar/986de9e060699ae70ff7c31342393adc"
+ subject="Editing Comments?"
+ date="2020-02-14T01:22:46Z"
+ content="""
+Is it possible to edit comments on the branchable wiki? I realized there was a sentence I failed to finish when posting [this comment](https://git-annex.branchable.com/todo/sync_--branches__to_sync_only_specified_branches___40__e.g._git-annex__41__/#comment-19feab1afb2e0b33315a8368a7cdebf7) and I'd love to go back and finish the thought. The \"Edit\" button at the top of the page lets me edit the content of the page, but not any of the comments.
+
+I tried cloning the wiki, editing the file corresponding to my comment, and then pushing, but the push was rejected (the changes were in doc tree so I expected it to be accepted, but perhaps comments are more locked down).
+"""]]

diff --git a/doc/todo/sync_--branches__to_sync_only_specified_branches___40__e.g._git-annex__41__/comment_5_8f19d38c815dd3051004301a15657cf6._comment b/doc/todo/sync_--branches__to_sync_only_specified_branches___40__e.g._git-annex__41__/comment_5_8f19d38c815dd3051004301a15657cf6._comment
new file mode 100644
index 000000000..47e2061fd
--- /dev/null
+++ b/doc/todo/sync_--branches__to_sync_only_specified_branches___40__e.g._git-annex__41__/comment_5_8f19d38c815dd3051004301a15657cf6._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="Dan"
+ avatar="http://cdn.libravatar.org/avatar/986de9e060699ae70ff7c31342393adc"
+ subject="Still wanted (update with example)"
+ date="2020-02-13T20:08:45Z"
+ content="""
+I see this page recently was edited (when todo's were tagged) and so I wanted to chime in that this is still a feature I'm looking for, and I have a much less hypothetical use case for it.
+
+I'm a PhD student working on a research project where I supervise several undergraduates. We have a git repository that manages all of our code, and I let git-annex manage the large datafiles (also in the same repository) on which we run our code. The main repository is hosted on GitHub, and my students have read-only access to it. They've each made forks to which they have write access. We use a special remote that we all have write-access to, with wanted set to standard and group set to archive, so that it gets all of the content and distributes it as needed (the data is massive so git-annex is vital here since the student laptops can't realistically download it all at any one time).
+
+They use pull requests to the main GitHub repository to integrate their code changes, but we need a way to get the content of the git-annex branches in their forks (which are pushed to from their local repos) into the git-annex branch in the main GitHub repository. The natural solution seems for me (who has read/write access to the main repo and the fork) to do this, essentially pulling in git-annex branches from their forks to my local repo, and then pushing it to the main repo on GitHub. It'd also be nice if I can then push this back to all of their forks, too. I can do this manually, but I think I'd need to actually check out the git-annex branch (or stuff it in another worktree) and then do lots of work manually (or automate it in a script).
+
+First I tried `git annex sync --no-commit --no-push --no-pull` which (somewhat to my surprise) *did* pull the git-annex branches from their forks into my local repo, but didn't push `git-annex` back anywhere, and it neither pushed nor pulled `master`. So this was a good start, but I wanted to also push *only* the git-annex branch to the main repo (and ideally to their forks, too). So then I (foolishly) started dropping flags, and ended up in inadvertently pulling their work-in-progress `master` branches into the mainline and pushing this super-merged thing back to all of them. I was able to do some reseting and quick force-pushes before anyone noticed, but I should've known better :)
+
+Throughout this process I'm trying to teach them how to use git-annex (it's pretty clearly the right tool for the job :) but need to be really careful with what `git annex sync` commands I encourage them to run since I don't want the, 
+
+I'd love it if there was like a `--git-annex-branch-only` option that I could pass that would then do all the pushing/pulling goodness of `git annex sync` but *without* touching `master` (or whatever branch happens to be checked out). I could then teach the students to always use this flag to avoid actually introducing changes to their master branch (they're still learning git, too, so they'd have a hard time recovering from this). Even better if this was configurable, and something I could stick in the `git-annex-config` options so that when they clone the repo this setting would propagate to them along with the git-annex branch. 
+
+Is something like this in the pipeline? Also, is there a simpler workaround I can do for now that doesn't involve tons of (manual) merges and pushes?
+
+Thanks so much for such an excellent tool; if we didn't have this, we'd essentially just give up on version control for our scientific data, which would be a real bummer. 
+"""]]

diff --git a/doc/forum/Transparent_compression_of_files/comment_1_7242325defa000572ca8e78e29012451._comment b/doc/forum/Transparent_compression_of_files/comment_1_7242325defa000572ca8e78e29012451._comment
new file mode 100644
index 000000000..a2a96f1b7
--- /dev/null
+++ b/doc/forum/Transparent_compression_of_files/comment_1_7242325defa000572ca8e78e29012451._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="lykos@d125a37d89b1cfac20829f12911656c40cb70018"
+ nickname="lykos"
+ avatar="http://cdn.libravatar.org/avatar/085df7b04d3408ba23c19f9c49be9ea2"
+ subject="comment 1"
+ date="2020-02-13T12:29:40Z"
+ content="""
+It's quite easy to implement an [external special remote](https://git-annex.branchable.com/special_remotes/external/) that does transparent compression. You can use the example implementations of the directory remote as a starting point (see [Bash](https://git-annex.branchable.com/special_remotes/external/example.sh/) or [Python](https://github.com/Lykos153/AnnexRemote/blob/master/examples/git-annex-remote-directory)). Then just modify the dostore() and doretrieve() functions to your liking. You probably don't want to support exporting when compression is enabled, though.
+"""]]

diff --git a/doc/forum/Transparent_compression_of_files.mdwn b/doc/forum/Transparent_compression_of_files.mdwn
new file mode 100644
index 000000000..2b3a28a35
--- /dev/null
+++ b/doc/forum/Transparent_compression_of_files.mdwn
@@ -0,0 +1,5 @@
+Hi,
+
+I have a lot of files which are around 80MB and can be easily compressed down to ~55MB. I did some tests with brotli and decompression was reasonable fast, at least fast enough that I would probably not notice given my current transfer speeds. In order to save disk space I would like to able to transparently compress my files. That means, a file is stored compressed in git-annex's blob store and decompressed when I `get` it.
+
+I understand that gpg does compression, but I don't want to deal with encryption, all my repos are local. I've looked at the code and from what I could see the Hash-Backends are rather simple. However, that's probably not the right place. Is this a planned feature? Would it be hard to implement? Of course, ideally the compression algorithm should be configurable. E.g. by just doing a syscall to `brotli` or `gzip`.

diff --git a/doc/bugs/warning_about_ssh_caching_keeps_showing.mdwn b/doc/bugs/warning_about_ssh_caching_keeps_showing.mdwn
new file mode 100644
index 000000000..370be161a
--- /dev/null
+++ b/doc/bugs/warning_about_ssh_caching_keeps_showing.mdwn
@@ -0,0 +1,57 @@
+### Please describe the problem.
+I keep getting the warning about ssh caching being disabled, even when I explicitly enable it.
+
+### What steps will reproduce the problem?
+See log below
+
+### What version of git-annex are you using? On what operating system?
+7.20200204 on Amazon Linux 2
+
+### Please provide any additional information below.
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+
+(just-git-annex-env) 13:00  [viral-ngs-benchmarks] $ git annex sync -c annex.sshcaching=true
+On branch is-devel
+Your branch is up to date with 'origin/is-devel'.
+
+
+It took 8.50 seconds to enumerate untracked files. 'status -uno'
+may speed it up, but you have to be careful not to forget to add
+new files yourself (see 'git help status').
+nothing to commit, working tree clean
+commit ok
+pull origin
+  You have enabled concurrency, but ssh connection caching is not enabled. This may result in multiple ssh processes prompting for pas\
+swords at the same time.
+ok
+
+(just-git-annex-env) 13:00  [viral-ngs-benchmarks] $ uname -a
+Linux ip-172-31-86-201.ec2.internal 4.14.165-131.185.amzn2.x86_64 #1 SMP Wed Jan 15 14:19:56 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
+(just-git-annex-env) 13:02  [viral-ngs-benchmarks] $ git annex version
+git-annex version: 7.20200204-g4db801d
+build flags: Assistant Webapp Pairing S3 WebDAV Inotify DBus DesktopNotify TorrentParser MagicMime Feeds Testsuite
+dependency versions: aws-0.21.1 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-sql\
+ite-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_2\
+24 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE\
+2B224E 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: 7
+upgrade supported from repository versions: 0 1 2 3 4 5 6
+local repository version: 7
+
+
+
+# End of transcript or log.
+"""]]
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+I've been using git-annex for 1.5 years to manage bioinformatics analyses.  It's a very versatile and well-designed tool.  I've been able to adapt it to many use cases;
+the ability to easily write your own external backends has been especially helpful for that.  The amount of work and thought that has gone into designing/building git-annex is
+enormous, and very much appreciated.

diff --git a/doc/forum/git-annex-sync_without_syncing_master/comment_3_233c20435643d2701c94a2cf30ca6483._comment b/doc/forum/git-annex-sync_without_syncing_master/comment_3_233c20435643d2701c94a2cf30ca6483._comment
new file mode 100644
index 000000000..2b1fd7922
--- /dev/null
+++ b/doc/forum/git-annex-sync_without_syncing_master/comment_3_233c20435643d2701c94a2cf30ca6483._comment
@@ -0,0 +1,25 @@
+[[!comment format=mdwn
+ username="Nick_P"
+ avatar="http://cdn.libravatar.org/avatar/abf8aa3ac1a976a6a292416b9c604581"
+ subject="comment 3"
+ date="2020-02-12T10:50:06Z"
+ content="""
+Relatedly, my team is struggling to identify the process for \"add and share a file\" - e.g., add the hash to git, and copy the content to a central git-annex remote, and push the git-annex branch information that the file is now in the central remote.
+
+We used 'git annex sync' and 'git annex sync --content' for a while, but this creates the synced/ branches which introduced confusion; and it's unclear why both --content and with args are needed; and if I remember, it also committed or pushed changes we didn't want it to.
+
+Now we do like this:
+
+     git checkout features/your-new-branch
+     git annex add my-new-file
+     git commit -m \".....\"
+     git push # pushes your \"features\" branch
+     git annex copy --to SharedRemote --jobs=5 <files or folders>
+     git fetch origin git-annex:refs/remotes/origin/git-annex
+     git annex merge
+     git push origin git-annex
+
+I've read through <https://git-annex.branchable.com/walkthrough/> , <https://git-annex.branchable.com/todo/sync_--branches__to_sync_only_specified_branches___40__e.g._git-annex__41__/> , <https://git-annex.branchable.com/sync/>
+
+Maybe the OP has the same confusion, that there seems to be a missing git-annex-sync that does only (a) copy to a remote and (b) the git-annex branch work - Anyone able to help out direct us to how it's intended to be done?
+"""]]

diff --git a/doc/special_remotes/S3/comment_33_36788d742259b3b078e02d7b2a251ce5._comment b/doc/special_remotes/S3/comment_33_36788d742259b3b078e02d7b2a251ce5._comment
new file mode 100644
index 000000000..2c4736101
--- /dev/null
+++ b/doc/special_remotes/S3/comment_33_36788d742259b3b078e02d7b2a251ce5._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="cnjr2"
+ avatar="http://cdn.libravatar.org/avatar/f7e9654cc967c8815947b19829bfd746"
+ subject="comment 33"
+ date="2020-02-12T10:37:24Z"
+ content="""
+First of all thanks for `git-annex`! I have recently discovered it and was so pleased to see how it solves problems that I had not anticipated!
+
+Related to [comment 26](http://git-annex.branchable.com/special_remotes/S3/#comment-e2000bfcb5d4c2d1a017f52c1c02a1ba) above, I want to create a bucket in Frankfurt. It seems like the aws library used by git-annex is from [aristidb/aws](https://github.com/aristidb/aws) where the topic of `V4` signing was raised in [this issue](https://github.com/aristidb/aws/issues/167) ([comment](https://github.com/aristidb/aws/issues/167#issuecomment-258864661) by you joey?). 
+
+Are there workarounds here? I can only use Frankfurt.
+
+Thanks again!
+
+
+"""]]

diff --git a/doc/forum/Annex_v7_repos_and_plain_git_files/comment_6_21648eecfaf9673b25d40327d11f7b59._comment b/doc/forum/Annex_v7_repos_and_plain_git_files/comment_6_21648eecfaf9673b25d40327d11f7b59._comment
new file mode 100644
index 000000000..7dc724bf5
--- /dev/null
+++ b/doc/forum/Annex_v7_repos_and_plain_git_files/comment_6_21648eecfaf9673b25d40327d11f7b59._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="default git-annex version in distros"
+ date="2020-02-10T18:55:29Z"
+ content="""
+\"you can expect the situation to be worse on 18.04 LTS\" -- if the default version there is before 7.20190912 there is no chance of user confusion, only versions 7.20190912 through 7.20191017 can cause it.  I take it it's not possible to change the default version included in existing distributions?  Sorry, don't know how Ubuntu/Debian packaging works...
+"""]]

diff --git a/doc/bugs/annex.genmetadata_should_default_to_true/comment_4_615bb36fb8e2958c001fc6df997b2928._comment b/doc/bugs/annex.genmetadata_should_default_to_true/comment_4_615bb36fb8e2958c001fc6df997b2928._comment
new file mode 100644
index 000000000..2e6f13477
--- /dev/null
+++ b/doc/bugs/annex.genmetadata_should_default_to_true/comment_4_615bb36fb8e2958c001fc6df997b2928._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="reasons not to have annex.genmetadata default to true"
+ date="2020-02-10T18:40:52Z"
+ content="""
+Some reasons `annex.genmetadata` should *not* default to true: (1) ordinary git does not preserve file modtimes, probably on purpose: if you have some kind of `make` process, you want `git update` to cause updated files to have updated modtimes, not the modtimes from when the files were added to git, so that `make` can detect the change and update downstream files; (2) as @joey noted, potentially wasteful bloat, especially for repos with many files; (3) two different copies of a file may have different modtimes, but all copies must have the same git-annex metadata, because metadata is attached to the [[key|backends]], which for most backends is computed from file contents.
+
+The WOM backend stores the modtime in the key, but then does not store checksums.  If [[todo/external_backends]] are implemented, you could make one that includes both the checksum and the modtime in the key. 
+"""]]

diff --git a/doc/forum/Annex_v7_repos_and_plain_git_files/comment_5_f47fec91d4ceebe653bc3fb221e2f8df._comment b/doc/forum/Annex_v7_repos_and_plain_git_files/comment_5_f47fec91d4ceebe653bc3fb221e2f8df._comment
new file mode 100644
index 000000000..34b1aa52a
--- /dev/null
+++ b/doc/forum/Annex_v7_repos_and_plain_git_files/comment_5_f47fec91d4ceebe653bc3fb221e2f8df._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="oliv5"
+ avatar="http://cdn.libravatar.org/avatar/d7f0d33c51583bbd8578e4f1f9f8cf4b"
+ subject="comment 5"
+ date="2020-02-10T10:10:06Z"
+ content="""
+Thks for pointing me to Conda, I didn't know it.
+
+About Ubuntu 19.10 old git-annex package, it seems I have the expected revision. I rarely mess with the package manager (only nvidia drivers!), so I don't expect any issue there.
+
+<https://ubuntu.pkgs.org/19.10/ubuntu-universe-amd64/git-annex_7.20190912-1_amd64.deb.html>
+<https://packages.ubuntu.com/eoan/git-annex>
+
+Yes, I agree, my git-annex package is an old one. Ubuntu is supposed to be a stable main stream distro, so optional packages like git-annex are not the cutting edge ones. And 19.10 is not a LTS release, you can expect the situation to be worse on 18.04 LTS. Same on Debian, Raspbian etc...
+
+
+"""]]

diff --git a/doc/tips/automatically_adding_metadata/comment_10_cf770ba8eed7963f08517877bd460d3f._comment b/doc/tips/automatically_adding_metadata/comment_10_cf770ba8eed7963f08517877bd460d3f._comment
new file mode 100644
index 000000000..8cb52f192
--- /dev/null
+++ b/doc/tips/automatically_adding_metadata/comment_10_cf770ba8eed7963f08517877bd460d3f._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="max"
+ avatar="http://cdn.libravatar.org/avatar/ebbd4dd37b341d018077a12e7ccf9fbd"
+ subject="adding support for additional metadata tools?"
+ date="2020-02-10T04:45:55Z"
+ content="""
+hi there, sincere gratitude for your work on git-annex.
+
+is it worth considering a more modular setup (maybe a python script :) or even haskell) for working with metadata extractors?
+
+currently it really only supports field-based filtering extractors. i am particularly interested in using (minimally):
+
+mp3info - offers a formatting string for printing but doesn't fit super nicely into the \"want\" fields in shell script. could probably be hacked in.
+
+mp4info - does not seem to offer any native parameters for filtering; would likely need some engineering/thought about how to take in all possible fields then filtering off of those.
+
+alternatively i could just write some personal scripts here, but just thought others would find it useful for auto extracting content from mp3/m4a files. extract doesn't seem to perform as well on these as, say, .flac files.
+
+thanks again!
+"""]]

diff --git a/doc/forum/Recomended_Setup_for_Syncthing_Remote.mdwn b/doc/forum/Recomended_Setup_for_Syncthing_Remote.mdwn
new file mode 100644
index 000000000..56ace65c3
--- /dev/null
+++ b/doc/forum/Recomended_Setup_for_Syncthing_Remote.mdwn
@@ -0,0 +1,5 @@
+Hello!
+
+     So with Android 10, Syncthing may be facing some issues regarding where we can put our files on the device. However, the Syncthing-Fork from the Google Play store has granular control over when sync tasks can run, which I very much require; I was thinking of combining git-annex and Syncthing by syncing the `.git/annex/objects` directory, but I am still *very* new to this. Can anyone advise me what the best setup would be for the procedure, according to [`syncthing special remote`](https://git-annex.branchable.com/todo/syncthing_special_remote/)?
+
+     Thank you kindly for the help!

diff --git a/doc/forum/Annex_v7_repos_and_plain_git_files/comment_4_fd1a3658ed6f3b6af2297c768b3f1ac2._comment b/doc/forum/Annex_v7_repos_and_plain_git_files/comment_4_fd1a3658ed6f3b6af2297c768b3f1ac2._comment
new file mode 100644
index 000000000..475464388
--- /dev/null
+++ b/doc/forum/Annex_v7_repos_and_plain_git_files/comment_4_fd1a3658ed6f3b6af2297c768b3f1ac2._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="git-annex ubuntu package"
+ date="2020-02-10T02:07:10Z"
+ content="""
+P.S. It's a bit concerning if 7.20190912 is the default git-annex version in a common distro: it's the version most likely to confuse users with the changed `git add` behavior.  Can this be fixed?  Is it definitely the default version?   I don't know much about Ubuntu packaging, but from [https://packages.ubuntu.com/](https://packages.ubuntu.com/), 19.10 (`focal`) seems to have version [7.20191230](https://packages.ubuntu.com/focal/utils/git-annex)?
+"""]]

diff --git a/doc/forum/Annex_v7_repos_and_plain_git_files/comment_3_6095eaa58aa298aca72237381f567ffb._comment b/doc/forum/Annex_v7_repos_and_plain_git_files/comment_3_6095eaa58aa298aca72237381f567ffb._comment
new file mode 100644
index 000000000..04edbe35a
--- /dev/null
+++ b/doc/forum/Annex_v7_repos_and_plain_git_files/comment_3_6095eaa58aa298aca72237381f567ffb._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="updating git-annex"
+ date="2020-02-10T00:05:00Z"
+ content="""
+You can use [[install/conda]] to install a recent git-annex version that supports `annex.gitaddtoannex`.
+"""]]

diff --git a/doc/forum/Annex_v7_repos_and_plain_git_files/comment_2_a0628a013b57c00ea449b40b93edd385._comment b/doc/forum/Annex_v7_repos_and_plain_git_files/comment_2_a0628a013b57c00ea449b40b93edd385._comment
new file mode 100644
index 000000000..37efa8fa0
--- /dev/null
+++ b/doc/forum/Annex_v7_repos_and_plain_git_files/comment_2_a0628a013b57c00ea449b40b93edd385._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="oliv5"
+ avatar="http://cdn.libravatar.org/avatar/d7f0d33c51583bbd8578e4f1f9f8cf4b"
+ subject="comment 2"
+ date="2020-02-09T22:59:35Z"
+ content="""
+Thks for pointing me to the \"git add v7\" very interesting thread. It explains everything.
+
+I'm using git-annex version: 7.20190912 (the default in Ubuntu 19.10 packages).
+
+Neither annex.gitaddtoannex nor annex.largefiles were set in my repo. In this version, I have to set annex.largefiles to \"nothing\" to get the expected behaviour, annex.gitaddtoannex true/false does not change anything. Of course, I verified this behaviour in a fresh new repo without any config change/hack.
+
+But even if annex.gitaddtoannex does not change anything right now, I'll set it to false, in case later version of git-annex uses it.
+
+"""]]

diff --git a/doc/forum/Annex_v7_repos_and_plain_git_files/comment_1_3bf39b5e6990d4343d9154465d951a77._comment b/doc/forum/Annex_v7_repos_and_plain_git_files/comment_1_3bf39b5e6990d4343d9154465d951a77._comment
new file mode 100644
index 000000000..64d442c0a
--- /dev/null
+++ b/doc/forum/Annex_v7_repos_and_plain_git_files/comment_1_3bf39b5e6990d4343d9154465d951a77._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="adding plain git files in v7 repos"
+ date="2020-02-09T18:08:30Z"
+ content="""
+What git-annex version are you using, and what are your git config settings?  In the current version, if `annex.largefiles` is not set, or if `annex.gitaddtoannex` is set to `false`, `git add` should [[add all files to plain git|forum/lets_discuss_git_add_behavior/#comment-37e0ecaf8e0f763229fd7b8ee9b5a577]].
+"""]]

diff --git a/doc/forum/Annex_v7_repos_and_plain_git_files.mdwn b/doc/forum/Annex_v7_repos_and_plain_git_files.mdwn
new file mode 100644
index 000000000..16c3b0083
--- /dev/null
+++ b/doc/forum/Annex_v7_repos_and_plain_git_files.mdwn
@@ -0,0 +1,23 @@
+Hi,
+This is not an issue, more some questions related to my 'legacy' git-annex worklfow which is disturbed with v7 repos.
+
+## The context
+I've got an old repo (initially v5) which has both plain git txt files and annexed binary files. The plain git files don't go through git-annex, only git.
+THis way, I have the classic git history of the txt files, versionning, plus the management of the (big) binaries via git-annex.
+The best of the two worlds.
+
+## The pb
+I converted it to v7, and it is now not possible to add plain git files anymore though 'git add', they are managed by git-annex automatically, probably because of the smudge filter added in .git/info/attributes.
+I understand (and like) this new behaviour, because it avoids adding big binary files though 'git add' by accident. But in this repo, I would like to come back to the old behaviour.
+
+## What I did
+I disabled git-annex smudge filter in the file .git/info/attributes, which is now:
+
+    #* filter=annex
+    .* !filter
+
+## Question at 100000$
+Is this safe ?
+
+## Question 2
+Is there an other way of achieving this (adding plain git files outside git-annex) ?

diff --git a/doc/todo/union_mounting/comment_6_65055977d7c8db3c9c29d90e033e5bb4._comment b/doc/todo/union_mounting/comment_6_65055977d7c8db3c9c29d90e033e5bb4._comment
new file mode 100644
index 000000000..650808c63
--- /dev/null
+++ b/doc/todo/union_mounting/comment_6_65055977d7c8db3c9c29d90e033e5bb4._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="chkno@50332f55d5ef2f4b7c6bec5253b853a8f2dc770e"
+ nickname="chkno"
+ avatar="http://cdn.libravatar.org/avatar/8194377c81da838dda761a5d93b9c25c"
+ subject="Three union-mounting methods that *don't* work"
+ date="2020-02-08T06:21:03Z"
+ content="""
+Linux's in-tree union-mounting option overlayfs [does not support modifications to underlying filesystems while an overlayfs mount is active](https://www.kernel.org/doc/Documentation/filesystems/overlayfs.txt):
+
+> Changes to the underlying filesystems while part of a mounted overlay filesystem are not allowed.  If the underlying filesystem is changed, the behavior of the overlay is undefined, though it will not result in a crash or deadlock.
+
+I.e., it's great for the LiveCD case of combining a read-only squashfs and a private tmpfs into something that behaves just like a normal filesystem, but it cannot be used to export a read-only view of multiple mutable resources.
+
+I can report that [aufs](http://aufs.sourceforge.net/) also doesn't work for this use case, at least as of 2014 when I last tried it.  Writes to underlying filesystems cause kernel panics that bring the whole machine down.
+
+I can also report that [hanwen/go-fuse's unionfs](https://github.com/hanwen/go-fuse/blob/master/example/unionfs/main.go) doesn't work for this use case.  Example problem: Growing files' sizes get stuck at the size they were the first time they were viewed through the union mount.
+"""]]

diff --git a/doc/bugs/Remote_Tests__58___storeKey_fails_for_http_remotes___40__skip_instead__63____41__.mdwn b/doc/bugs/Remote_Tests__58___storeKey_fails_for_http_remotes___40__skip_instead__63____41__.mdwn
new file mode 100644
index 000000000..e0736c978
--- /dev/null
+++ b/doc/bugs/Remote_Tests__58___storeKey_fails_for_http_remotes___40__skip_instead__63____41__.mdwn
@@ -0,0 +1,80 @@
+### Please describe the problem.
+When running `git annex testremote origin --test-readonly=filename` on a git http remote that supports git-annex, the `storeKey` test fails with error:
+
+```
+storeKey:                        FAIL
+./Command/TestRemote.hs:277:
+(got: Left "copying to non-ssh repo not supported")
+```
+
+(Full example output below)
+
+
+### What steps will reproduce the problem?
+
+Using https://downloads.kitenet.net/.git/ as an example of a public repository with https git annex support:
+
+```
+$ git clone https://downloads.kitenet.net/.git/
+Cloning into 'downloads.kitenet.net'...
+$ cd downloads.kitenet.net/debug-me/linux/current/
+$ git annex get debug-me-standalone-amd64.tar.gz
+get debug-me-standalone-amd64.tar.gz (from origin...)
+(checksum...) ok
+(recording state in git...)
+$ git annex testremote origin --test-readonly debug-me-standalone-amd64.tar.gz
+testremote origin Remote Tests
+  unavailable remote
+    removeKey:                         dropping from http remote not supported
+OK
+    storeKey:                        FAIL
+      ./Command/TestRemote.hs:277:
+      (got: Left "copying to non-ssh repo not supported")
+    checkPresent:                    OK (0.02s)
+    retrieveKeyFile:                   download failed: ConnectionFailure Network.Socket.getAddrInfo (called with preferred socket type/protocol: AddrInfo {addrFlags = [AI_ADDRCONFIG], addrFamily = AF_UNSPEC, addrSocketType = Stream, addrProtocol = 6, addrAddress = <assumed to be undefined>, addrCanonName = <assumed to be undefined>}, host name: Just "!dne!", service name: Just "443"): does not exist (Name or service not known)
+  download failed: ConnectionFailure Network.Socket.getAddrInfo (called with preferred socket type/protocol: AddrInfo {addrFlags = [AI_ADDRCONFIG], addrFamily = AF_UNSPEC, addrSocketType = Stream, addrProtocol = 6, addrAddress = <assumed to be undefined>, addrCanonName = <assumed to be undefined>}, host name: Just "!dne!", service name: Just "443"): does not exist (Name or service not known)
+OK (0.01s)
+    retrieveKeyFileCheap:            OK
+  key size Just 13600699; NoChunks; encryption none
+    present True:                    OK (0.61s)
+    retrieveKeyFile:                 OK (2.39s)
+    fsck downloaded object:          OK
+    retrieveKeyFile resume from 33%: OK (1.95s)
+    fsck downloaded object:          OK
+    retrieveKeyFile resume from 0:   OK (1.94s)
+    fsck downloaded object:          OK
+    retrieveKeyFile resume from end: OK (0.68s)
+    fsck downloaded object:          OK
+
+1 out of 14 tests failed (7.61s)
+failed
+git-annex: testremote: 1 failed
+```
+
+### What version of git-annex are you using? On what operating system?
+
+```
+git-annex version: 7.20191230-g985373f8e
+build flags: Assistant Webapp Pairing S3 WebDAV Inotify DBus DesktopNotify TorrentParser MagicMime Feeds Testsuite
+dependency versions: aws-0.21.1 bloomfilter-2.0.1.0 cryptonite-0.26 DAV-1.3.4 feed-1.2.0.1 ghc-8.6.5 http-client-0.6.4 persistent-sqlite-2.10.5 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: 7
+upgrade supported from repository versions: 0 1 2 3 4 5 6
+```
+
+OS: Arch Linux (5.5.1-arch1-1)
+
+### Please provide any additional information below.
+
+I came across this while trying to make our hosted git and git-annex service (gin.g-node.org) open to public https git annex downloads.  I was using the `testremote` command to make sure everything works as intended and saw the error thinking, at first, that the server was serving something incorrectly.  The error message does clearly state that `copying to non-ssh repo not supported`, so I thought I'd try with kitenet to see if the same happens and it does.
+
+I don't know if this is a bug or intentional—perhaps the test should be failing to indicate that the remote doesn't support `storeKey`?  On the other hand, the `removeKey` test displays the "not supported" message and then passes, so maybe the `storeKey` test should behave the same way.
+
+It's possible there's another issue here I'm not entirely aware of.
+
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+Of course!  I use and rely on it daily :)

diff --git a/doc/todo/alternate_keys_for_same_content/comment_7_1c0a975893c63c14b3f6e17712b5191c._comment b/doc/todo/alternate_keys_for_same_content/comment_7_1c0a975893c63c14b3f6e17712b5191c._comment
new file mode 100644
index 000000000..80f61be55
--- /dev/null
+++ b/doc/todo/alternate_keys_for_same_content/comment_7_1c0a975893c63c14b3f6e17712b5191c._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="potential security issues?"
+ date="2020-02-06T21:00:55Z"
+ content="""
+I wonder if storing checksums in a general-purpose mutable metadata field may cause security issues.  Someone could use the [[`git-annex-metadata`|git-annex-metadata]] command to overwrite the checksum.  It should be stored in a read-only field written only by `git-annex` itself, like the `field-lastchanged` metadata already is.
+
+Of course, if someone is able to write the [[git-annex branch|internals#The_git-annex_branch]] directly, or get the user to pull merges to it, they could alter the checksum stored there.  Maybe, only trust stored checksums if `merge.verifySignatures=true`?
+"""]]

diff --git a/doc/bugs/git_keeps_refreshing_index/comment_6_e0bfde0d53042ce8d310f356f88c610b._comment b/doc/bugs/git_keeps_refreshing_index/comment_6_e0bfde0d53042ce8d310f356f88c610b._comment
new file mode 100644
index 000000000..b561288e7
--- /dev/null
+++ b/doc/bugs/git_keeps_refreshing_index/comment_6_e0bfde0d53042ce8d310f356f88c610b._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="t+gitannex@1d62779e8b54f30a854739f61542a6885167b01f"
+ nickname="t+gitannex"
+ avatar="http://cdn.libravatar.org/avatar/87c7f62c00e4a744aa500423e421120f"
+ subject="comment 6"
+ date="2020-02-06T11:07:34Z"
+ content="""
+I'm able to reproduce this with git annex 7.20191230 and git 2.25.0 on Arch Linux, but I've had it on OSX in the past as well. The annex uses a v7 repository. I don't need to do anything besides unlocking some files and running git status. Unlocking 10 files, git status takes 3s and with 85 files it takes 20s, so it seems to scale linearly with the no of files. Happy to share more details about the repository if it's useful.
+"""]]

diff --git a/doc/todo/Don__39__t_re-encrypt_when_key_is_already_in_.git__47__annex__47__tmp.mdwn b/doc/todo/Don__39__t_re-encrypt_when_key_is_already_in_.git__47__annex__47__tmp.mdwn
new file mode 100644
index 000000000..6a461cfff
--- /dev/null
+++ b/doc/todo/Don__39__t_re-encrypt_when_key_is_already_in_.git__47__annex__47__tmp.mdwn
@@ -0,0 +1 @@
+I've implemented true resumable upload in git-annex-remote-googledrive which means that uploads can, just as downloads, be resumed at any point, even within one chunk. However, it currently does not work with encrypted files (or chunks) due to the non-deterministic nature of GPG. In order to make this feature useable on encrypted files, I propose to not overwrite encrypted files which are already present inside the `tmp` directory.

diff --git a/doc/thanks/list b/doc/thanks/list
index 3a5de35e3..af577f018 100644
--- a/doc/thanks/list
+++ b/doc/thanks/list
@@ -71,3 +71,4 @@ Svenne Krap,
 Jelmer Vernooij, 
 Rian McGuire, 
 Cesar, 
+LND, 

diff --git a/doc/todo/more_extensive_retries_to_mask_transient_failures/comment_6_5a7771a6169caa90fd91bc6ea7b4fe3d._comment b/doc/todo/more_extensive_retries_to_mask_transient_failures/comment_6_5a7771a6169caa90fd91bc6ea7b4fe3d._comment
new file mode 100644
index 000000000..51b9a693b
--- /dev/null
+++ b/doc/todo/more_extensive_retries_to_mask_transient_failures/comment_6_5a7771a6169caa90fd91bc6ea7b4fe3d._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="example of where retries could help"
+ date="2020-02-05T22:19:26Z"
+ content="""
+As one example, I just had a `git-annex-copy` command fail twice with `git-annex: thread blocked indefinitely in an STM transaction`, then have the same command succeed (or at least get much further -- still running) on the third try.   I can write my own wrappers to mask such errors, but a built-in implementation seems generally useful and would know better which failures are likely transient.
+"""]]

diff --git a/doc/todo/more_extensive_retries_to_mask_transient_failures/comment_5_69b132f465851421acb7e5edf009995d._comment b/doc/todo/more_extensive_retries_to_mask_transient_failures/comment_5_69b132f465851421acb7e5edf009995d._comment
new file mode 100644
index 000000000..e764bdd56
--- /dev/null
+++ b/doc/todo/more_extensive_retries_to_mask_transient_failures/comment_5_69b132f465851421acb7e5edf009995d._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="retries due to locked index file"
+ date="2020-02-05T16:59:40Z"
+ content="""
+\"A locked git index file does not prevent git-annex from making transfers\" -- by \"mask transient failures\" I meant all types of failures, not just transfers.  So e.g. if concurrent operations fail due to contention for the index file lock, retries (after increasing, randomized intervals) could mask the failure.  This would help especially for writing scripts/tools on top of git-annex.  Logically, some operations -- like `git-annex-add` -- should never fail, and being able to assume that makes scripting easier.
+"""]]

diff --git a/doc/todo/more_extensive_retries_to_mask_transient_failures/comment_4_418a9cbc38142ec1b2d08fd617a3e4d4._comment b/doc/todo/more_extensive_retries_to_mask_transient_failures/comment_4_418a9cbc38142ec1b2d08fd617a3e4d4._comment
new file mode 100644
index 000000000..814114176
--- /dev/null
+++ b/doc/todo/more_extensive_retries_to_mask_transient_failures/comment_4_418a9cbc38142ec1b2d08fd617a3e4d4._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="aborting stuck operations so they can be retried"
+ date="2020-02-05T16:39:36Z"
+ content="""
+\"The only way to guarantee such an abort is to kill the whole git-annex process and let the signal reap its children\" -- then maybe the initial `git-annex` command can be made a wrapper that starts a separate `git-annex` process to do the actual work, monitors its progress, and kills/reaps/restarts it if it gets stuck?   Or `-Jn` could work by starting up several separate git-annex processes, [[each handling a subset of files|parallel_possibilities/#comment-304240ba804513291c1a996b8eb3fd1c]], and the original process could kill/reap/restart any sub-process that gets stuck.  This of course presumes idempotent operations.
+"""]]

diff --git a/doc/news/version_7.20191106.mdwn b/doc/news/version_7.20191106.mdwn
deleted file mode 100644
index e51c99a3d..000000000
--- a/doc/news/version_7.20191106.mdwn
+++ /dev/null
@@ -1,5 +0,0 @@
-git-annex 7.20191106 released with [[!toggle text="these changes"]]
-[[!toggleable text="""
-   * init: Fix bug that lost modifications to unlocked files when init is
-     re-ran in an already initialized repo.
-   * benchmark: Add --databases to benchmark sqlite databases."""]]
\ No newline at end of file
diff --git a/doc/news/version_7.20200204.mdwn b/doc/news/version_7.20200204.mdwn
new file mode 100644
index 000000000..d9eb1a237
--- /dev/null
+++ b/doc/news/version_7.20200204.mdwn
@@ -0,0 +1,5 @@
+git-annex 7.20200204 released with [[!toggle text="these changes"]]
+[[!toggleable text="""
+   * Fix build with persistent-template 2.8.0.
+   * Makefile: Really move the fish completion to the
+     vendor\_completions.d directory."""]]
\ No newline at end of file

diff --git a/CHANGELOG b/CHANGELOG
index 61babf75d..2cffff002 100644
--- a/CHANGELOG
+++ b/CHANGELOG
@@ -1,6 +1,6 @@
 git-annex (7.20200204) UNRELEASED; urgency=medium
 
-  * Fix build with newest version of persistent-template.
+  * Fix build with persistent-template 2.8.0.
   * Makefile: Really move the fish completion to the
     vendor_completions.d directory.
 
diff --git a/Database/ContentIdentifier.hs b/Database/ContentIdentifier.hs
index 0ff296e56..25800524e 100644
--- a/Database/ContentIdentifier.hs
+++ b/Database/ContentIdentifier.hs
@@ -5,13 +5,16 @@
  - Licensed under the GNU AGPL version 3 or higher.
  -}
 
+{-# LANGUAGE CPP #-}
 {-# LANGUAGE QuasiQuotes, TypeFamilies, TemplateHaskell #-}
 {-# LANGUAGE OverloadedStrings, GADTs, FlexibleContexts, EmptyDataDecls #-}
 {-# LANGUAGE MultiParamTypeClasses, GeneralizedNewtypeDeriving #-}
 {-# LANGUAGE RankNTypes #-}
 {-# LANGUAGE UndecidableInstances #-}
+#if MIN_VERSION_persistent_template(2,8,0)
 {-# LANGUAGE DerivingStrategies #-}
 {-# LANGUAGE StandaloneDeriving #-}
+#endif
 
 module Database.ContentIdentifier (
 	ContentIdentifierHandle,
diff --git a/Database/Export.hs b/Database/Export.hs
index 67cb1c62b..c930e64ec 100644
--- a/Database/Export.hs
+++ b/Database/Export.hs
@@ -5,13 +5,16 @@
  - Licensed under the GNU AGPL version 3 or higher.
  -}
 
+{-# LANGUAGE CPP #-}
 {-# LANGUAGE QuasiQuotes, TypeFamilies, TemplateHaskell #-}
 {-# LANGUAGE OverloadedStrings, GADTs, FlexibleContexts #-}
 {-# LANGUAGE MultiParamTypeClasses, GeneralizedNewtypeDeriving #-}
 {-# LANGUAGE RankNTypes #-}
 {-# LANGUAGE UndecidableInstances #-}
+#if MIN_VERSION_persistent_template(2,8,0)
 {-# LANGUAGE DerivingStrategies #-}
 {-# LANGUAGE StandaloneDeriving #-}
+#endif
 
 module Database.Export (
 	ExportHandle,
diff --git a/Database/Fsck.hs b/Database/Fsck.hs
index 88416f8a6..9cf59f4cb 100644
--- a/Database/Fsck.hs
+++ b/Database/Fsck.hs
@@ -5,13 +5,16 @@
  - Licensed under the GNU AGPL version 3 or higher.
  -}
 
+{-# LANGUAGE CPP #-}
 {-# LANGUAGE QuasiQuotes, TypeFamilies, TemplateHaskell #-}
 {-# LANGUAGE OverloadedStrings, GADTs, FlexibleContexts #-}
 {-# LANGUAGE MultiParamTypeClasses, GeneralizedNewtypeDeriving #-}
 {-# LANGUAGE RankNTypes #-}
 {-# LANGUAGE UndecidableInstances #-}
+#if MIN_VERSION_persistent_template(2,8,0)
 {-# LANGUAGE DerivingStrategies #-}
 {-# LANGUAGE StandaloneDeriving #-}
+#endif
 
 module Database.Fsck (
 	FsckHandle,
diff --git a/Database/Keys/SQL.hs b/Database/Keys/SQL.hs
index 77029cc80..c1ac2ff4c 100644
--- a/Database/Keys/SQL.hs
+++ b/Database/Keys/SQL.hs
@@ -5,13 +5,16 @@
  - Licensed under the GNU AGPL version 3 or higher.
  -}
 
+{-# LANGUAGE CPP #-}
 {-# LANGUAGE QuasiQuotes, TypeFamilies, TemplateHaskell #-}
 {-# LANGUAGE OverloadedStrings, GADTs, FlexibleContexts #-}
 {-# LANGUAGE MultiParamTypeClasses, GeneralizedNewtypeDeriving #-}
 {-# LANGUAGE RankNTypes, ScopedTypeVariables #-}
 {-# LANGUAGE UndecidableInstances #-}
+#if MIN_VERSION_persistent_template(2,8,0)
 {-# LANGUAGE DerivingStrategies #-}
 {-# LANGUAGE StandaloneDeriving #-}
+#endif
 
 module Database.Keys.SQL where
 
diff --git a/doc/bugs/brew_install_git-annex_failed.mdwn b/doc/bugs/brew_install_git-annex_failed.mdwn
index 48718b010..e75a66cdc 100644
--- a/doc/bugs/brew_install_git-annex_failed.mdwn
+++ b/doc/bugs/brew_install_git-annex_failed.mdwn
@@ -47,3 +47,4 @@ git-annex: add OBJC_DISABLE_INITIALIZE_FORK_SAFETY environment variable https://
 ### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
 
 
+> [[fixed|done]] in git-annex master --[[Joey]]

diff --git a/CHANGELOG b/CHANGELOG
index a7e451d49..61babf75d 100644
--- a/CHANGELOG
+++ b/CHANGELOG
@@ -1,6 +1,8 @@
 git-annex (7.20200204) UNRELEASED; urgency=medium
 
   * Fix build with newest version of persistent-template.
+  * Makefile: Really move the fish completion to the
+    vendor_completions.d directory.
 
  -- Joey Hess <id@joeyh.name>  Tue, 04 Feb 2020 11:58:22 -0400
 
diff --git a/Makefile b/Makefile
index eb3a34e6a..722921e00 100644
--- a/Makefile
+++ b/Makefile
@@ -86,7 +86,7 @@ install-completions: build
 		> $(DESTDIR)$(ZSH_COMPLETIONS_PATH)/_git-annex
 	install -d $(DESTDIR)$(PREFIX)/$(SHAREDIR)/fish/vendor_completions.d
 	./git-annex --fish-completion-script git-annex 2>/dev/null \
-		> $(DESTDIR)$(PREFIX)/$(SHAREDIR)/fish/completions/git-annex.fish
+		> $(DESTDIR)$(PREFIX)/$(SHAREDIR)/fish/vendor_completions.d/git-annex.fish
 
 test: git-annex git-annex-shell
 	./git-annex test
diff --git a/doc/bugs/Incorrect_install_dir_for_fish_completion/comment_3_020854d8b66be6b17f850075fa8d95ac._comment b/doc/bugs/Incorrect_install_dir_for_fish_completion/comment_3_020854d8b66be6b17f850075fa8d95ac._comment
new file mode 100644
index 000000000..3e18d4c19
--- /dev/null
+++ b/doc/bugs/Incorrect_install_dir_for_fish_completion/comment_3_020854d8b66be6b17f850075fa8d95ac._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2020-02-04T16:09:04Z"
+ content="""
+So it did. Fixed now. Thanks for checking.
+"""]]

diff --git a/CHANGELOG b/CHANGELOG
index 197afcaed..a7e451d49 100644
--- a/CHANGELOG
+++ b/CHANGELOG
@@ -1,3 +1,9 @@
+git-annex (7.20200204) UNRELEASED; urgency=medium
+
+  * Fix build with newest version of persistent-template.
+
+ -- Joey Hess <id@joeyh.name>  Tue, 04 Feb 2020 11:58:22 -0400
+
 git-annex (7.20200202.7) upstream; urgency=medium
 
   * add: --force-annex/--force-git options make it easier to override
diff --git a/Database/ContentIdentifier.hs b/Database/ContentIdentifier.hs
index 024825eae..0ff296e56 100644
--- a/Database/ContentIdentifier.hs
+++ b/Database/ContentIdentifier.hs
@@ -10,6 +10,8 @@
 {-# LANGUAGE MultiParamTypeClasses, GeneralizedNewtypeDeriving #-}
 {-# LANGUAGE RankNTypes #-}
 {-# LANGUAGE UndecidableInstances #-}
+{-# LANGUAGE DerivingStrategies #-}
+{-# LANGUAGE StandaloneDeriving #-}
 
 module Database.ContentIdentifier (
 	ContentIdentifierHandle,
diff --git a/Database/Export.hs b/Database/Export.hs
index 28784ac45..67cb1c62b 100644
--- a/Database/Export.hs
+++ b/Database/Export.hs
@@ -10,6 +10,8 @@
 {-# LANGUAGE MultiParamTypeClasses, GeneralizedNewtypeDeriving #-}
 {-# LANGUAGE RankNTypes #-}
 {-# LANGUAGE UndecidableInstances #-}
+{-# LANGUAGE DerivingStrategies #-}
+{-# LANGUAGE StandaloneDeriving #-}
 
 module Database.Export (
 	ExportHandle,
diff --git a/Database/Fsck.hs b/Database/Fsck.hs
index 09f9222be..88416f8a6 100644
--- a/Database/Fsck.hs
+++ b/Database/Fsck.hs
@@ -10,6 +10,8 @@
 {-# LANGUAGE MultiParamTypeClasses, GeneralizedNewtypeDeriving #-}
 {-# LANGUAGE RankNTypes #-}
 {-# LANGUAGE UndecidableInstances #-}
+{-# LANGUAGE DerivingStrategies #-}
+{-# LANGUAGE StandaloneDeriving #-}
 
 module Database.Fsck (
 	FsckHandle,
diff --git a/Database/Keys/SQL.hs b/Database/Keys/SQL.hs
index 99606bbad..77029cc80 100644
--- a/Database/Keys/SQL.hs
+++ b/Database/Keys/SQL.hs
@@ -10,6 +10,8 @@
 {-# LANGUAGE MultiParamTypeClasses, GeneralizedNewtypeDeriving #-}
 {-# LANGUAGE RankNTypes, ScopedTypeVariables #-}
 {-# LANGUAGE UndecidableInstances #-}
+{-# LANGUAGE DerivingStrategies #-}
+{-# LANGUAGE StandaloneDeriving #-}
 
 module Database.Keys.SQL where
 
diff --git a/doc/bugs/brew_install_git-annex_failed/comment_3_627876a558898bb9f622b80dbacee051._comment b/doc/bugs/brew_install_git-annex_failed/comment_3_627876a558898bb9f622b80dbacee051._comment
new file mode 100644
index 000000000..373cb3e66
--- /dev/null
+++ b/doc/bugs/brew_install_git-annex_failed/comment_3_627876a558898bb9f622b80dbacee051._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2020-02-04T15:56:00Z"
+ content="""
+I think I've fixed this in master now, but have not been able to test the fix
+yet since I don't have the bandwidth to upgrade.
+"""]]

diff --git a/doc/bugs/brew_install_git-annex_failed/comment_2_a398db56168954d43620620104215b14._comment b/doc/bugs/brew_install_git-annex_failed/comment_2_a398db56168954d43620620104215b14._comment
new file mode 100644
index 000000000..d6931cda0
--- /dev/null
+++ b/doc/bugs/brew_install_git-annex_failed/comment_2_a398db56168954d43620620104215b14._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="nrg@bd619d1ebf16e6324c546adea8be8fe1cc2b4325"
+ nickname="nrg"
+ avatar="http://cdn.libravatar.org/avatar/428b6c95b52769cf9eecdd351018eacb"
+ subject="Change introduced by persistent-sqlite and persistent-template"
+ date="2020-02-04T15:09:59Z"
+ content="""
+The change was introduced [here](https://github.com/yesodweb/persistent/commit/6ca1c2401f228293c64ae05e6109d4936b98c4b9).
+"""]]

diff --git a/doc/todo/union_mounting/comment_5_58c38383a7ac2df843772960fa10204f._comment b/doc/todo/union_mounting/comment_5_58c38383a7ac2df843772960fa10204f._comment
new file mode 100644
index 000000000..8f253a793
--- /dev/null
+++ b/doc/todo/union_mounting/comment_5_58c38383a7ac2df843772960fa10204f._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="https://christian.amsuess.com/chrysn"
+ nickname="chrysn"
+ avatar="http://christian.amsuess.com/avatar/c6c0d57d63ac88f3541522c4b21198c3c7169a665a2f2d733b4f78670322ffdc"
+ subject="union mounting and hidemissing"
+ date="2020-02-04T09:01:52Z"
+ content="""
+One easy way to achieve this with git-annex as is would be actual operating-system union mounting. This'll work as long as all (but the lowest / most costly) checkouts [have their missing files hidden](https://git-annex.branchable.com/tips/hiding_missing_files/). Just be sure not to call `git-annex` on the resulting directory (and if there's any danger of it, you might want to consider whiteing out the git configuration in an additional top layer), but only inside one of the supplying repositories.
+"""]]

diff --git a/doc/todo/union_mounting/comment_4_2f02fe00a84bf94b7c8e437d8b80293f._comment b/doc/todo/union_mounting/comment_4_2f02fe00a84bf94b7c8e437d8b80293f._comment
new file mode 100644
index 000000000..009355299
--- /dev/null
+++ b/doc/todo/union_mounting/comment_4_2f02fe00a84bf94b7c8e437d8b80293f._comment
@@ -0,0 +1,67 @@
+[[!comment format=mdwn
+ username="chkno@50332f55d5ef2f4b7c6bec5253b853a8f2dc770e"
+ nickname="chkno"
+ avatar="http://cdn.libravatar.org/avatar/8194377c81da838dda761a5d93b9c25c"
+ subject="Interim shell script"
+ date="2020-02-04T07:26:10Z"
+ content="""
+Until this feature is available in git annex proper, here is a small shell script that uses [lndir](https://gitlab.freedesktop.org/xorg/util/lndir) to create a merged view of the .git/annex/objects areas of multiple git-annex repositories.
+
+* [union-link-annexes](https://chkno.net/union-link-annexes)
+
+Demo:
+
+    $ git init repo1
+    $ cd repo1
+    $ git annex init repo1
+    $ echo from1 > from1
+    $ echo both > both
+    $ git annex add from1 both
+    $ git commit -m .
+
+    $ cd ..
+    $ git clone repo1 repo2
+    $ cd repo2
+    $ echo from2 > from2
+    $ git annex add from2
+    $ git annex copy --from origin both
+    $ git annex sync
+    $ git annex list
+    here
+    |origin
+    ||
+    XX both
+    _X from1
+    X_ from2
+
+    $ cd ../repo1
+    $ git annex sync
+    $ cd ..
+
+
+    $ union-link-annexes merged repo1 repo2
+
+
+    $ grep . repo1/*
+    repo1/both:both
+    repo1/from1:from1
+    grep: repo1/from2: No such file or directory
+
+    $ grep . repo2/*
+    repo2/both:both
+    grep: repo2/from1: No such file or directory
+    repo2/from2:from2
+
+    $ grep . merged/*
+    merged/both:both
+    merged/from1:from1
+    merged/from2:from2
+
+    $ find merged -not -type d -printf '%p -> %l\n'
+    merged/both -> .git/annex/objects/XV/zk/SHA256E-s5--f6d...
+    merged/from1 -> .git/annex/objects/vf/8W/SHA256E-s6--16e...
+    merged/from2 -> .git/annex/objects/3M/P2/SHA256E-s6--21e...
+    merged/.git/annex/objects/vf/8W/SHA256E-s6--16e... -> ../../../../../../../repo1/.git/annex/objects/vf/8W/SHA256E-s6--16e...
+    merged/.git/annex/objects/XV/zk/SHA256E-s5--f6d... -> ../../../../../../../repo1/.git/annex/objects/XV/zk/SHA256E-s5--f6d...
+    merged/.git/annex/objects/3M/P2/SHA256E-s6--21e... -> ../../../../../../../repo2/.git/annex/objects/3M/P2/SHA256E-s6--21e...
+"""]]

diff --git a/doc/todo/union_mounting/comment_4_3d215c18adb694a32d21be4aecc9ec74._comment b/doc/todo/union_mounting/comment_4_3d215c18adb694a32d21be4aecc9ec74._comment
deleted file mode 100644
index 121fc35b0..000000000
--- a/doc/todo/union_mounting/comment_4_3d215c18adb694a32d21be4aecc9ec74._comment
+++ /dev/null
@@ -1,72 +0,0 @@
-[[!comment format=mdwn
- username="chkno@50332f55d5ef2f4b7c6bec5253b853a8f2dc770e"
- nickname="chkno"
- avatar="http://cdn.libravatar.org/avatar/8194377c81da838dda761a5d93b9c25c"
- subject="Interim shell scripts"
- date="2020-02-04T06:43:02Z"
- content="""
-Until this feature is available in git annex proper, here are some small shell scripts that use [lndir](https://gitlab.freedesktop.org/xorg/util/lndir) to create a merged view of the .git/annex/objects areas of multiple git-annex repositories.
-
-* [union-link-annexes](https://chkno.net/union-link-annexes) (supports absolute paths only)
-* [union-link-annexes-with-sharp-edges](https://chkno.net/union-link-annexes-with-sharp-edges) (for relative paths when needed)
-
-Demo:
-
-    $ mkdir demo
-    $ cd demo
-
-    $ git init repo1
-    $ cd repo1
-    $ git annex init repo1
-    $ echo from1 > from1
-    $ echo both > both
-    $ git annex add from1 both
-    $ git commit -m .
-
-    $ cd ..
-    $ git clone repo1 repo2
-    $ cd repo2
-    $ echo from2 > from2
-    $ git annex add from2
-    $ git annex copy --from origin both
-    $ git annex sync
-    $ git annex list
-    here
-    |origin
-    ||
-    XX both
-    _X from1
-    X_ from2
-
-    $ cd ../repo1
-    $ git annex sync
-    $ cd ..
-
-
-    $ union-link-annexes merged \"$PWD\"/repo1 \"$PWD\"/repo2
-
-
-    $ grep . repo1/*
-    repo1/both:both
-    repo1/from1:from1
-    grep: repo1/from2: No such file or directory
-
-    $ grep . repo2/*
-    repo2/both:both
-    grep: repo2/from1: No such file or directory
-    repo2/from2:from2
-
-    $ grep . merged/*
-    merged/both:both
-    merged/from1:from1
-    merged/from2:from2
-
-    $ find merged -not -type d -printf '%p -> %l\n'
-    merged/both -> .git/annex/objects/XV/zk/SHA256E-s5--f6d...
-    merged/from1 -> .git/annex/objects/vf/8W/SHA256E-s6--16e...
-    merged/from2 -> .git/annex/objects/3M/P2/SHA256E-s6--21e...
-    merged/.git/annex/objects/vf/8W/SHA256E-s6--16e... -> ~/demo/repo1/.git/annex/objects/vf/8W/SHA256E-s6--16e...
-    merged/.git/annex/objects/XV/zk/SHA256E-s5--f6d... -> ~/demo/repo1/.git/annex/objects/XV/zk/SHA256E-s5--f6d...
-    merged/.git/annex/objects/3M/P2/SHA256E-s6--21e... -> ~/demo/repo2/.git/annex/objects/3M/P2/SHA256E-s6--21e...
-
-"""]]

diff --git a/doc/todo/union_mounting/comment_4_3d215c18adb694a32d21be4aecc9ec74._comment b/doc/todo/union_mounting/comment_4_3d215c18adb694a32d21be4aecc9ec74._comment
new file mode 100644
index 000000000..121fc35b0
--- /dev/null
+++ b/doc/todo/union_mounting/comment_4_3d215c18adb694a32d21be4aecc9ec74._comment
@@ -0,0 +1,72 @@
+[[!comment format=mdwn
+ username="chkno@50332f55d5ef2f4b7c6bec5253b853a8f2dc770e"
+ nickname="chkno"
+ avatar="http://cdn.libravatar.org/avatar/8194377c81da838dda761a5d93b9c25c"
+ subject="Interim shell scripts"
+ date="2020-02-04T06:43:02Z"
+ content="""
+Until this feature is available in git annex proper, here are some small shell scripts that use [lndir](https://gitlab.freedesktop.org/xorg/util/lndir) to create a merged view of the .git/annex/objects areas of multiple git-annex repositories.
+
+* [union-link-annexes](https://chkno.net/union-link-annexes) (supports absolute paths only)
+* [union-link-annexes-with-sharp-edges](https://chkno.net/union-link-annexes-with-sharp-edges) (for relative paths when needed)
+
+Demo:
+
+    $ mkdir demo
+    $ cd demo
+
+    $ git init repo1
+    $ cd repo1
+    $ git annex init repo1
+    $ echo from1 > from1
+    $ echo both > both
+    $ git annex add from1 both
+    $ git commit -m .
+
+    $ cd ..
+    $ git clone repo1 repo2
+    $ cd repo2
+    $ echo from2 > from2
+    $ git annex add from2
+    $ git annex copy --from origin both
+    $ git annex sync
+    $ git annex list
+    here
+    |origin
+    ||
+    XX both
+    _X from1
+    X_ from2
+
+    $ cd ../repo1
+    $ git annex sync
+    $ cd ..
+
+
+    $ union-link-annexes merged \"$PWD\"/repo1 \"$PWD\"/repo2
+
+
+    $ grep . repo1/*
+    repo1/both:both
+    repo1/from1:from1
+    grep: repo1/from2: No such file or directory
+
+    $ grep . repo2/*
+    repo2/both:both
+    grep: repo2/from1: No such file or directory
+    repo2/from2:from2
+
+    $ grep . merged/*
+    merged/both:both
+    merged/from1:from1
+    merged/from2:from2
+
+    $ find merged -not -type d -printf '%p -> %l\n'
+    merged/both -> .git/annex/objects/XV/zk/SHA256E-s5--f6d...
+    merged/from1 -> .git/annex/objects/vf/8W/SHA256E-s6--16e...
+    merged/from2 -> .git/annex/objects/3M/P2/SHA256E-s6--21e...
+    merged/.git/annex/objects/vf/8W/SHA256E-s6--16e... -> ~/demo/repo1/.git/annex/objects/vf/8W/SHA256E-s6--16e...
+    merged/.git/annex/objects/XV/zk/SHA256E-s5--f6d... -> ~/demo/repo1/.git/annex/objects/XV/zk/SHA256E-s5--f6d...
+    merged/.git/annex/objects/3M/P2/SHA256E-s6--21e... -> ~/demo/repo2/.git/annex/objects/3M/P2/SHA256E-s6--21e...
+
+"""]]

diff --git a/doc/todo/transitive_transfers/comment_6_ddef2f127a49c2eb8a15b5848756d888._comment b/doc/todo/transitive_transfers/comment_6_ddef2f127a49c2eb8a15b5848756d888._comment
new file mode 100644
index 000000000..323dcbae9
--- /dev/null
+++ b/doc/todo/transitive_transfers/comment_6_ddef2f127a49c2eb8a15b5848756d888._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="annex2384@290036d126d86bcec28ee2f2ead549de1f59e90e"
+ nickname="annex2384"
+ avatar="http://cdn.libravatar.org/avatar/ad36fdc55abd8b9913b774fcd0177709"
+ subject="Similar use case"
+ date="2020-02-04T03:48:39Z"
+ content="""
+I have a similar use case, wanting to sync files to my music player from a machine that doesn't store a local copy of my music collection. I'm using a directory special remote with exporttree=yes since the player uses a FAT filesystem. Spooling locally would be absolutely fine with me; I just don't want to fetch any content that's already on the player. I suppose I could so something clever with the preferred content expression to accomplish this, but it seems like it might be complicated. For example, I think I could put the laptop and player each in a \"playersync\" group, with the player additionally in a \"player\" group, set the groupwanted expression on the playersync gorup to the files I want on the player, set the player's wanted to groupwanted and the laptop's wanted to \"groupwanted and not inallgroup=player\". But that seems pretty convoluted.
+"""]]

diff --git a/doc/forum/git-annex-sync_without_syncing_master/comment_2_585648a04a02760a1f16394c00728d79._comment b/doc/forum/git-annex-sync_without_syncing_master/comment_2_585648a04a02760a1f16394c00728d79._comment
new file mode 100644
index 000000000..4c93dd0f4
--- /dev/null
+++ b/doc/forum/git-annex-sync_without_syncing_master/comment_2_585648a04a02760a1f16394c00728d79._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="jafpoU"
+ avatar="http://cdn.libravatar.org/avatar/b1016484e481ea844c1fe42ace53e88f"
+ subject="comment 2"
+ date="2020-02-04T03:35:48Z"
+ content="""
+Thank you!
+
+Just to confirm then, `git-annex-merge` will
+
+1. union merge any ref with basename `git-annex` onto `git-annex`
+2. union merge `synced/$branch` onto `$branch` where `$branch` is the checked out branch
+
+?
+
+My goal is for all remotes to have a consistent view of where the annexed files are, without auto-merging any normal branches.
+
+Is the process you described above the easiest way to achieve this?
+"""]]

diff --git a/doc/bugs/WSL1__58___git-annex-add_fails_in_DrvFs_filesystem/comment_1_6b54cc0a268885570170620222b774d7._comment b/doc/bugs/WSL1__58___git-annex-add_fails_in_DrvFs_filesystem/comment_1_6b54cc0a268885570170620222b774d7._comment
new file mode 100644
index 000000000..3677a6ec5
--- /dev/null
+++ b/doc/bugs/WSL1__58___git-annex-add_fails_in_DrvFs_filesystem/comment_1_6b54cc0a268885570170620222b774d7._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="annex2384@290036d126d86bcec28ee2f2ead549de1f59e90e"
+ nickname="annex2384"
+ avatar="http://cdn.libravatar.org/avatar/ad36fdc55abd8b9913b774fcd0177709"
+ subject="Using -o metadata?"
+ date="2020-02-04T03:22:45Z"
+ content="""
+I'm having the same issue, though I can add files if I set annex.addunlocked=true.
+"""]]

diff --git a/doc/bugs/Incorrect_install_dir_for_fish_completion/comment_2_7607d3170194f8ad46e0c0178b3ea317._comment b/doc/bugs/Incorrect_install_dir_for_fish_completion/comment_2_7607d3170194f8ad46e0c0178b3ea317._comment
new file mode 100644
index 000000000..87dfd3d2f
--- /dev/null
+++ b/doc/bugs/Incorrect_install_dir_for_fish_completion/comment_2_7607d3170194f8ad46e0c0178b3ea317._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="eschwartz@5abb721e66990e478c7d1caf96beb4f9794eb168"
+ nickname="eschwartz"
+ avatar="http://cdn.libravatar.org/avatar/16ec8475b4e3507f8d1a71101c16b208"
+ subject="Partial fix only."
+ date="2020-02-03T23:47:35Z"
+ content="""
+Looks like the install -d was changed to create the new directory, but the actual file write got left left out of the commit.
+"""]]

diff --git a/doc/bugs/Incorrect_install_dir_for_fish_completion/comment_1_c5601e6da07e39a0c23d29ee0a728970._comment b/doc/bugs/Incorrect_install_dir_for_fish_completion/comment_1_c5601e6da07e39a0c23d29ee0a728970._comment
new file mode 100644
index 000000000..6de076e59
--- /dev/null
+++ b/doc/bugs/Incorrect_install_dir_for_fish_completion/comment_1_c5601e6da07e39a0c23d29ee0a728970._comment
@@ -0,0 +1,32 @@
+[[!comment format=mdwn
+ username="Chel"
+ avatar="http://cdn.libravatar.org/avatar/a42feb5169f70b3edf7f7611f7e3640c"
+ subject="comment 1"
+ date="2020-02-03T23:34:02Z"
+ content="""
+I've got an error from `make install` on version 7.20200202.7:
+
+~~~
+./git-annex --fish-completion-script git-annex 2>/dev/null \
+	> dest/usr/local/share/fish/completions/git-annex.fish
+make: *** [Makefile:87: install-completions] Error 2
+~~~
+
+I think there should be:
+
+[[!format  diff \"\"\"
+diff --git a/Makefile b/Makefile
+index eb3a34e6a..722921e00 100644
+--- a/Makefile
++++ b/Makefile
+@@ -86,7 +86,7 @@ install-completions: build
+                > $(DESTDIR)$(ZSH_COMPLETIONS_PATH)/_git-annex
+        install -d $(DESTDIR)$(PREFIX)/$(SHAREDIR)/fish/vendor_completions.d
+        ./git-annex --fish-completion-script git-annex 2>/dev/null \
+-               > $(DESTDIR)$(PREFIX)/$(SHAREDIR)/fish/completions/git-annex.fish
++               > $(DESTDIR)$(PREFIX)/$(SHAREDIR)/fish/vendor_completions.d/git-annex.fish
+ 
+ test: git-annex git-annex-shell
+        ./git-annex test
+\"\"\"]]
+"""]]

diff --git a/doc/bugs/brew_install_git-annex_failed/comment_1_57b2c2c989311b4db01aca8d07802207._comment b/doc/bugs/brew_install_git-annex_failed/comment_1_57b2c2c989311b4db01aca8d07802207._comment
new file mode 100644
index 000000000..f8e923f11
--- /dev/null
+++ b/doc/bugs/brew_install_git-annex_failed/comment_1_57b2c2c989311b4db01aca8d07802207._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="nrg@bd619d1ebf16e6324c546adea8be8fe1cc2b4325"
+ nickname="nrg"
+ avatar="http://cdn.libravatar.org/avatar/428b6c95b52769cf9eecdd351018eacb"
+ subject="Confirmed with macOS 10.14.6 building git-annex-7.20200202.7"
+ date="2020-02-03T23:10:22Z"
+ content="""
+The issue is also seen [here](https://github.com/Homebrew/homebrew-core/pull/49731).
+"""]]

diff --git a/doc/forum/git-annex-sync_without_syncing_master/comment_1_8ed0014e53a7ab49d76c072de074adda._comment b/doc/forum/git-annex-sync_without_syncing_master/comment_1_8ed0014e53a7ab49d76c072de074adda._comment
new file mode 100644
index 000000000..c870f76d0
--- /dev/null
+++ b/doc/forum/git-annex-sync_without_syncing_master/comment_1_8ed0014e53a7ab49d76c072de074adda._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="Chel"
+ avatar="http://cdn.libravatar.org/avatar/a42feb5169f70b3edf7f7611f7e3640c"
+ subject="comment 1"
+ date="2020-02-03T22:36:59Z"
+ content="""
+If I am not mistaken, you need to:
+
+1) manually fetch `git-annex` from everywhere,
+
+2) not have the `synced/master` branch (or it should be an ancestor of `master`),
+
+3) use [[git-annex-merge]] or `git annex sync --no-pull --no-push` (maybe just `--no-pull` is enough),
+
+4) manually push `git-annex` back to every other repository.
+
+Other remarks:
+
+- You can use `git annex sync --cleanup` to delete all `synced/*` branches.
+- Or you can check out another branch and run `git annex sync` — it will fetch all branches, but merge only the current.
+- I don't fully understand how `synced/git-annex` works, so maybe the real answer is more complex.
+"""]]

diff --git a/doc/bugs/on_some_remotes_failing_to_detect_annex_spits_out_message_to_stderr_and_empty_lines_to_stderr__44___ignores_--json-error-messages/comment_1_a7ad806ceb76f13ff8fdcce62bc0ed8a._comment b/doc/bugs/on_some_remotes_failing_to_detect_annex_spits_out_message_to_stderr_and_empty_lines_to_stderr__44___ignores_--json-error-messages/comment_1_a7ad806ceb76f13ff8fdcce62bc0ed8a._comment
index 2cbbcac88..666d6a54e 100644
--- a/doc/bugs/on_some_remotes_failing_to_detect_annex_spits_out_message_to_stderr_and_empty_lines_to_stderr__44___ignores_--json-error-messages/comment_1_a7ad806ceb76f13ff8fdcce62bc0ed8a._comment
+++ b/doc/bugs/on_some_remotes_failing_to_detect_annex_spits_out_message_to_stderr_and_empty_lines_to_stderr__44___ignores_--json-error-messages/comment_1_a7ad806ceb76f13ff8fdcce62bc0ed8a._comment
@@ -3,39 +3,15 @@
  subject="""comment 1"""
  date="2020-01-22T15:11:05Z"
  content="""
-I've said this before, but I'll say it one more time: --json-error-messages
-is not a guarantee that every possible error message that may be output by
-git-annex in some exceptional circumstance will be formatted as json.
-
-In this case, while I happened to make it be captured in an unrelated
-change, there's actually no benefit to it being captured. If it were no
-longer captured tomorrow, I would not consider that a bug. This error
-message is not specific to a particular file in the repository, so if
+This error message is not specific to a particular file in the repository, so if
 git-annex get outputs it, it doesn't help for the error message to be
 wrapped up in json. The actual purpose of --json-error messages is being
 able to correlate a failure to eg, get a particular file with an error
 message related to that action. Not in avoiding all possible stderr.
 
-----
-
-The extra newlines output to stdout are there because the `warning` action
-does not know if something may have been output to stdout earlier without a
-terminating newline, and it wants to avoid an ugly interleave of stdout and
-stderr. While state could be maintained to keep track of that, the end
-result would be git-annex would become some milliseconds slower, and it
-does not seem worth the complexity or minor speed hit to cater to the case
-where stderr is /dev/nulled. Note that this doesn't happen when using
---json. Also, IIRC it's avoided when using concurrent output, which does
-pay the time/complexity overhead already to keep track of the state of the
-display to that extent. Anyway, I'm obviosuly not going to leave this bug
-report open for such a minor and tangential issue after the main issue in
-it is fixed, so it's kind of annoying to need to write this wall of text
-about it. May I suggest one bug report per distinct issue is a good way to
-avoid my current annoyed state?
+The actual bug here is that it dumps git config to stderr at all.
 
 ----
 
-Not wanting to sit down and write all this is why, the previous two or
-three times I opened this issue, I promptly closed the window rather than
-addressing any part of it.
+The extra newlines are output to stdout, so not a problem WRT stderr.
 """]]
diff --git a/doc/bugs/leaks_git_config_error_message_upon_inability_to_read_downloaded___34__config__34___file/comment_5_495820d777c889f88466d725c11895f9._comment b/doc/bugs/on_some_remotes_failing_to_detect_annex_spits_out_message_to_stderr_and_empty_lines_to_stderr__44___ignores_--json-error-messages/comment_2_495820d777c889f88466d725c11895f9._comment
similarity index 82%
rename from doc/bugs/leaks_git_config_error_message_upon_inability_to_read_downloaded___34__config__34___file/comment_5_495820d777c889f88466d725c11895f9._comment
rename to doc/bugs/on_some_remotes_failing_to_detect_annex_spits_out_message_to_stderr_and_empty_lines_to_stderr__44___ignores_--json-error-messages/comment_2_495820d777c889f88466d725c11895f9._comment
index a82a557c4..b68dcc0b2 100644
--- a/doc/bugs/leaks_git_config_error_message_upon_inability_to_read_downloaded___34__config__34___file/comment_5_495820d777c889f88466d725c11895f9._comment
+++ b/doc/bugs/on_some_remotes_failing_to_detect_annex_spits_out_message_to_stderr_and_empty_lines_to_stderr__44___ignores_--json-error-messages/comment_2_495820d777c889f88466d725c11895f9._comment
@@ -1,6 +1,6 @@
 [[!comment format=mdwn
  username="joey"
- subject="""comment 5"""
+ subject="""comment 2"""
  date="2020-01-22T17:04:09Z"
  content="""
 Error message has been improved.

diff --git a/doc/forum/git-annex-sync_without_syncing_master.mdwn b/doc/forum/git-annex-sync_without_syncing_master.mdwn
new file mode 100644
index 000000000..4e8f6e05f
--- /dev/null
+++ b/doc/forum/git-annex-sync_without_syncing_master.mdwn
@@ -0,0 +1,6 @@
+How do I run git-annex-sync without syncing master?
+
+i.e.
+
+* fetch and union merge the git-annex branch from every remote listed
+* push the updated git-annex branch to every remote listed

diff --git a/doc/news/version_7.20191024.mdwn b/doc/news/version_7.20191024.mdwn
deleted file mode 100644
index 8786301d5..000000000
--- a/doc/news/version_7.20191024.mdwn
+++ /dev/null
@@ -1,26 +0,0 @@
-News for git-annex 7.20191024:
-
-   When annex.largefiles is not configured, `git add` and `git commit -a`
-   add files to git, not to the annex. If you have gotten used to `git add`
-   adding all files to the annex, you can get that behavior back by running:
-   git config annex.largefiles anything
-
-git-annex 7.20191024 released with [[!toggle text="these changes"]]
-[[!toggleable text="""
-   * Changed git add/git commit -a default behavior back to what it was
-     before v7; they add file contents to git, not to the annex.
-     (However, if a file was annexed before, they will still add it to
-     the annex, to avoid footgun.)
-   * Configuring annex.largefiles overrides that; once git-annex has
-     been told which files are large git add/git commit -a will annex them.
-   * Added annex.gitaddtoannex configuration. Setting it to false prevents
-     git add from adding files to the annex even when annex.largefiles
-     is configured. (Unless the file was annexed before.)
-   * smudge: Made git add smarter about renamed annexed files. It can tell
-     when an annexed file was renamed, and will add it to the annex,
-     and not to git, unless annex.largefiles tells it to do otherwise.
-   * init: Fix a failure when used in a submodule on a crippled filesystem.
-   * sync: Fix crash when there are submodules and an adjusted branch is
-     checked out.
-   * enable-tor: Deal with pkexec changing to root's home directory
-     when running a command."""]]
\ No newline at end of file
diff --git a/doc/news/version_7.20200202.7.mdwn b/doc/news/version_7.20200202.7.mdwn
new file mode 100644
index 000000000..09c0f0b97
--- /dev/null
+++ b/doc/news/version_7.20200202.7.mdwn
@@ -0,0 +1,25 @@
+git-annex 7.20200202.7 released with [[!toggle text="these changes"]]
+[[!toggleable text="""
+   * add: --force-annex/--force-git options make it easier to override
+     annex.largefiles configuration (and potentially safer as it avoids
+     bugs like the smudge bug fixed in the last release).
+   * reinject --known: Fix bug that prevented it from working in a bare repo.
+   * Support being used in a git repository that uses sha256 rather than sha1.
+   * initremote, enableremote: Be stricter about rejecting invalid
+     configuration parameters for remotes, particularly things like foo=true
+     when foo=yes is expected.
+   * initremote, enableremote: Reject unknown configuration parameters
+     provided to these commands.
+   * initremote: Added --whatelse option, to show additional
+     configuration parameters you might want to set. Eg:
+     git annex initremote type=directory encryption=none --whatelse
+   * Added LISTCONFIGS to external special remote protocol. Special remote
+     programs that use GETCONFIG/SETCONFIG are recommended to implement it.
+   * init: Avoid an ugly error message when http remote has no git-annex
+     uuid configured.
+   * Support git remotes that need http basic auth to be accessed,
+     using git credential to get the password.
+   * Display a warning when concurrency is enabled but ssh connection caching
+     is not enabled or won't work due to a crippled filesystem.
+   * Makefile: Move the fish completion to the vendor\_completions.d directory.
+   * Fixed a test suite failure when run in the C locale."""]]
\ No newline at end of file

diff --git a/Key.hs b/Key.hs
index 8b8ca96b2..2c2f20cd9 100644
--- a/Key.hs
+++ b/Key.hs
@@ -1,6 +1,6 @@
 {- git-annex Keys
  -
- - Copyright 2011-2019 Joey Hess <id@joeyh.name>
+ - Copyright 2011-2020 Joey Hess <id@joeyh.name>
  -
  - Licensed under the GNU AGPL version 3 or higher.
  -}
@@ -28,6 +28,7 @@ module Key (
 	prop_isomorphic_key_encode
 ) where
 
+import Data.Char
 import qualified Data.Text as T
 import qualified Data.ByteString as S
 import qualified Data.Attoparsec.ByteString as A
@@ -79,11 +80,15 @@ instance Arbitrary KeyData where
 		<*> ((succ . abs <$>) <$> arbitrary) -- chunknum cannot be 0 or negative
 
 -- AssociatedFile cannot be empty, and cannot contain a NUL
--- (but can be Nothing)
+-- (but can be Nothing). 
 instance Arbitrary AssociatedFile where
-	arbitrary = (AssociatedFile . fmap toRawFilePath <$> arbitrary)
+  	arbitrary = (AssociatedFile . fmap conv <$> arbitrary)
 		`suchThat` (/= AssociatedFile (Just S.empty))
 		`suchThat` (\(AssociatedFile f) -> maybe True (S.notElem 0) f)
+	  where
+		-- Generating arbitrary unicode leads to encoding errors
+		-- when LANG=C, so limit to ascii.
+		conv = toRawFilePath . filter isAscii
 
 instance Arbitrary Key where
 	arbitrary = mkKey . const <$> arbitrary
diff --git a/doc/bugs/build_of_7.20191230+git152-gefb981388_fails_the_prop__95__read__95__write__95__transferinfo_test.mdwn b/doc/bugs/build_of_7.20191230+git152-gefb981388_fails_the_prop__95__read__95__write__95__transferinfo_test.mdwn
index bcfea264f..9ff3429c8 100644
--- a/doc/bugs/build_of_7.20191230+git152-gefb981388_fails_the_prop__95__read__95__write__95__transferinfo_test.mdwn
+++ b/doc/bugs/build_of_7.20191230+git152-gefb981388_fails_the_prop__95__read__95__write__95__transferinfo_test.mdwn
@@ -18,3 +18,5 @@ Full build logs are at http://neuro.debian.net/_files/_buildlogs/git-annex/7.201
 
 [[!meta author=yoh]]
 [[!tag projects/datalad]]
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/bugs/build_of_7.20191230+git152-gefb981388_fails_the_prop__95__read__95__write__95__transferinfo_test/comment_1_e9db58f71eedc99ccfd7a7a446843316._comment b/doc/bugs/build_of_7.20191230+git152-gefb981388_fails_the_prop__95__read__95__write__95__transferinfo_test/comment_1_e9db58f71eedc99ccfd7a7a446843316._comment
new file mode 100644
index 000000000..86f92e591
--- /dev/null
+++ b/doc/bugs/build_of_7.20191230+git152-gefb981388_fails_the_prop__95__read__95__write__95__transferinfo_test/comment_1_e9db58f71eedc99ccfd7a7a446843316._comment
@@ -0,0 +1,31 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2020-02-02T19:41:34Z"
+ content="""
+Minimal reproducer:
+
+	bash$ LANG=C ghci Utility/FileSystemEncoding.hs
+	ghci> useFileSystemEncoding
+	ghci> toRawFilePath "\611584"
+	"*** Exception: recoverEncode: invalid argument (invalid character)
+
+No such problem in a unicode locale.
+
+The problem does not, though, affect actually using git-annex in LANG=C
+with a filename with that in its name.
+
+Odd because the filesystem encoding is supposed to round-tip well,
+anything, but here encoding a string with it is failing internally.
+Maybe the thing is, it's not really round-tripping? QuickCheck arbitrary
+magics up a FilePath that contains that, so it's starting in the middle and
+trying to convert it out.
+
+[[!commit 70395659db9f662e61009d984fc9b0b2f24fdece]] introduced this while
+fixing another intermittent encoding test case failure.
+
+	ghci> Data.Char.generalCategory  '\611584'
+	NotAssigned
+
+I think it would make sense to filter out NotAssigned and PrivateUse.
+"""]]

diff --git a/doc/forum/Manually_moving_annex_objects_to_new_repo/comment_4_cdb9564e0be89e7c8217d3969d27b845._comment b/doc/forum/Manually_moving_annex_objects_to_new_repo/comment_4_cdb9564e0be89e7c8217d3969d27b845._comment
deleted file mode 100644
index 64eecab68..000000000
--- a/doc/forum/Manually_moving_annex_objects_to_new_repo/comment_4_cdb9564e0be89e7c8217d3969d27b845._comment
+++ /dev/null
@@ -1,8 +0,0 @@
-[[!comment format=mdwn
- username="erewhon"
- avatar="http://cdn.libravatar.org/avatar/b9bd5ad7176ebe149d0f051dcfe0a63e"
- subject="Thank you"
- date="2020-02-02T18:45:24Z"
- content="""
-Thank you both for the suggestions. I am going to give the approach using the local cache a try.
-"""]]

diff --git a/doc/forum/Manually_moving_annex_objects_to_new_repo/comment_4_cdb9564e0be89e7c8217d3969d27b845._comment b/doc/forum/Manually_moving_annex_objects_to_new_repo/comment_4_cdb9564e0be89e7c8217d3969d27b845._comment
new file mode 100644
index 000000000..64eecab68
--- /dev/null
+++ b/doc/forum/Manually_moving_annex_objects_to_new_repo/comment_4_cdb9564e0be89e7c8217d3969d27b845._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="erewhon"
+ avatar="http://cdn.libravatar.org/avatar/b9bd5ad7176ebe149d0f051dcfe0a63e"
+ subject="Thank you"
+ date="2020-02-02T18:45:24Z"
+ content="""
+Thank you both for the suggestions. I am going to give the approach using the local cache a try.
+"""]]

diff --git a/doc/forum/Manually_moving_annex_objects_to_new_repo/comment_3_8203d8e0444471b9360b679f49f67fac._comment b/doc/forum/Manually_moving_annex_objects_to_new_repo/comment_3_8203d8e0444471b9360b679f49f67fac._comment
new file mode 100644
index 000000000..e13fc5868
--- /dev/null
+++ b/doc/forum/Manually_moving_annex_objects_to_new_repo/comment_3_8203d8e0444471b9360b679f49f67fac._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="erewhon"
+ avatar="http://cdn.libravatar.org/avatar/b9bd5ad7176ebe149d0f051dcfe0a63e"
+ subject="Thank you"
+ date="2020-02-02T18:44:51Z"
+ content="""
+Thank you both for the suggestions. I am going to give the approach using the local cache a try.
+"""]]

diff --git a/doc/bugs/windows_autostart/comment_1_80a2561901554ddb45db719c086629b2._comment b/doc/bugs/windows_autostart/comment_1_80a2561901554ddb45db719c086629b2._comment
new file mode 100644
index 000000000..f529a22c8
--- /dev/null
+++ b/doc/bugs/windows_autostart/comment_1_80a2561901554ddb45db719c086629b2._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="jeanpmbox-456@7222359de8d1f37a7cf25a519e8faf90a9517b50"
+ nickname="jeanpmbox-456"
+ avatar="http://cdn.libravatar.org/avatar/164eb4254c5f83d95d3e0b810ff7aab9"
+ subject="comment 1"
+ date="2020-02-01T11:35:37Z"
+ content="""
+I finally saw thanks to the file `Build/NullSoftInstaller.hs` and to NirSoft Program WhatInStartup that the startup script is located in `%APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup`.
+
+It would be nice to have an option to activate this or not in the installation.
+"""]]

diff --git a/doc/todo/git-annex-migrate_using_git-replace/comment_1_6a317be851dfb72c4aaaf5786dd1a1ff._comment b/doc/todo/git-annex-migrate_using_git-replace/comment_1_6a317be851dfb72c4aaaf5786dd1a1ff._comment
new file mode 100644
index 000000000..2240298a3
--- /dev/null
+++ b/doc/todo/git-annex-migrate_using_git-replace/comment_1_6a317be851dfb72c4aaaf5786dd1a1ff._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="Chel"
+ avatar="http://cdn.libravatar.org/avatar/a42feb5169f70b3edf7f7611f7e3640c"
+ subject="comment 1"
+ date="2020-02-01T02:55:03Z"
+ content="""
+Very interesting idea! But some problems:
+
+- As mentioned, not only `.git/annex/<...>` blobs need to be replaces for every key, but also `/annex/<...>`
+and all `../.git/annex/<...>`, `../../.git/annex/<...>`, etc.
+
+- In big repositories it can create a giant amount of *refs/replace/* refs.
+I don't know how it affects the performance if they are stored in .git/packed-refs,
+but it can interfere with the normal operation on a repo.
+For example `git show-ref` will not work without ` | grep` or something.
+"""]]

diff --git a/doc/todo/alternate_keys_for_same_content/comment_6_ae8355ec917e7a7a240cdb88714c55d0._comment b/doc/todo/alternate_keys_for_same_content/comment_6_ae8355ec917e7a7a240cdb88714c55d0._comment
new file mode 100644
index 000000000..92d5ba48f
--- /dev/null
+++ b/doc/todo/alternate_keys_for_same_content/comment_6_ae8355ec917e7a7a240cdb88714c55d0._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="Chel"
+ avatar="http://cdn.libravatar.org/avatar/a42feb5169f70b3edf7f7611f7e3640c"
+ subject="comment 6"
+ date="2020-02-01T02:32:01Z"
+ content="""
+There is also `aaa/bbb/*.log.cid` in git-annex branch for \"per-remote content identifiers for keys\".
+It could be another place to store alternate keys, but it is per-remote, so... no.
+
+As for the metadata field `alt_keys` — it is another case of
+\"[setting a metadata field to a key](/todo/Bidirectional_metadata/#comment-788380998b25267c5b99c4a865277102)\"
+in [[Bidirectional metadata]].
+
+Also, there is an interesting idea of [[git-annex-migrate using git-replace]].
+
+By the way, as far as I know (maybe things have changed since then),
+ipfs has a similar problem of different identifiers for the same content.
+Because it encodes how things are stored. And hash functions can also be changed.
+"""]]

diff --git a/doc/todo/alternate_keys_for_same_content/comment_5_230d35bd623189818002901455964ca4._comment b/doc/todo/alternate_keys_for_same_content/comment_5_230d35bd623189818002901455964ca4._comment
new file mode 100644
index 000000000..4be01e425
--- /dev/null
+++ b/doc/todo/alternate_keys_for_same_content/comment_5_230d35bd623189818002901455964ca4._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="simpler proposal"
+ date="2020-01-31T21:46:57Z"
+ content="""
+So, to fully and properly implement what the title of this todo suggests -- \"alternate keys for same content\" -- might be hard.  But to simply enable adding checksums to WORM/URL keys, stored separately on the git-annex branch rather than encoded in the key's name, is simpler.  This would let some WORM/URL keys to be treated as checksum-based keys when getting contents from untrusted remotes or when checking integrity with `git-annex-fsck`.  But this isn't really \"alternate keys for same content\": the content would be stored under only the WORM/URL key under which it was initially recorded.  The corresponding MD5 key would not be recorded in [[location_tracking]] as present.
+
+Checking whether a WORM/URL key has an associated checksum could be sped up by keeping a Bloom filter representing the set of WORM/URL keys for which `alt_keys` is set.
+
+In the `addurl --fast` case for special remotes, where the remote can determine a file's checksum without downloading, a checksum-based key would be recorded to begin with, as happens with `addurl` without `--fast`.  Currently I do this by manually calling plumbing commands like `git-annex-setpresentkey`, but having `addurl` do it seems better.
+"""]]

diff --git a/doc/todo/alternate_keys_for_same_content/comment_4_a5fb6045595da0c490098e46f76db9b8._comment b/doc/todo/alternate_keys_for_same_content/comment_4_a5fb6045595da0c490098e46f76db9b8._comment
new file mode 100644
index 000000000..a37c5b622
--- /dev/null
+++ b/doc/todo/alternate_keys_for_same_content/comment_4_a5fb6045595da0c490098e46f76db9b8._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="comment 4"
+ date="2020-01-31T20:32:00Z"
+ content="""
+\"can be used to verify migrations\" -- my hope was to *avoid* migrations, i.e. to get the benefit you'd get from migrating to a checksum-based key, without doing the migration.
+"""]]

diff --git a/doc/todo/alternate_keys_for_same_content/comment_3_c99b23e878e37e205a3182d3b6d3f2b2._comment b/doc/todo/alternate_keys_for_same_content/comment_3_c99b23e878e37e205a3182d3b6d3f2b2._comment
new file mode 100644
index 000000000..857b25bc1
--- /dev/null
+++ b/doc/todo/alternate_keys_for_same_content/comment_3_c99b23e878e37e205a3182d3b6d3f2b2._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="https://christian.amsuess.com/chrysn"
+ nickname="chrysn"
+ avatar="http://christian.amsuess.com/avatar/c6c0d57d63ac88f3541522c4b21198c3c7169a665a2f2d733b4f78670322ffdc"
+ subject="Re: comment 1 "
+ date="2020-01-31T19:47:59Z"
+ content="""
+The proposed implementation may be inefficient, but the idea has merit.
+
+What if that information is stored in a place where it can be used to verify migrations?
+
+For example, when entering that the migrating remote dropped the data into `git-annex:aaa/bbb/SHA1-s1234--somehash.log`, somewhere near there a record could be added that this was migrated to SHA512-s1234--longerhash. When then all the other remotes are asked to drop that file, they can actually do that because they see that it has been migrated, can verify the migration and are free to drop the file.
+
+Even later, when a remote wants to get an old name (eg. because it checked out an old version of master), it can look up the key, find where it was migrated to, and make the data available under its own name (by copying, or maybe by placing a symlink pointing file from `.git/annex/objects/Aa/Bb/SHA1-s1234--somehash/SHA1-s1234--somehash` to the new.
+"""]]

diff --git a/doc/todo/alternate_keys_for_same_content/comment_2_0f464f4970e499371fcb65e0d06202cf._comment b/doc/todo/alternate_keys_for_same_content/comment_2_0f464f4970e499371fcb65e0d06202cf._comment
new file mode 100644
index 000000000..2eddbbf4d
--- /dev/null
+++ b/doc/todo/alternate_keys_for_same_content/comment_2_0f464f4970e499371fcb65e0d06202cf._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="alternate keys"
+ date="2020-01-31T19:23:35Z"
+ content="""
+\"every time something about a key is looked up in the git-annex branch, it would also need to look at the metadata to see if this alt_keys field is set\" -- not every time, just when checking if the key is checksum-based, and if content matches the checksum.  Also, isn't metadata [[cached in a database|design/caching_database]]?
+"""]]

diff --git a/doc/todo/consider_meow_backend.mdwn b/doc/todo/consider_meow_backend.mdwn
index aeb8a4f4b..f826b387a 100644
--- a/doc/todo/consider_meow_backend.mdwn
+++ b/doc/todo/consider_meow_backend.mdwn
@@ -34,5 +34,5 @@ be useful to speed up checks on larger files. The license is a
 I know it might sound like a conflict of interest, but I *swear* I am
 not bringing this up only as a oblique feline reference. ;) -- [[anarcat]]
 
-> Let's concentrate on xxhash or other new hashes that are getting general
+> Let's concentrate on [[xxhash|todo/add_xxHash_backend]] or other new hashes that are getting general
 > adoption, not niche hashes like meow. [[done]] --[[Joey]]

diff --git a/doc/todo/shorter_keys_through_better_encoding.mdwn b/doc/todo/shorter_keys_through_better_encoding.mdwn
index b665680a9..3b33d0cad 100644
--- a/doc/todo/shorter_keys_through_better_encoding.mdwn
+++ b/doc/todo/shorter_keys_through_better_encoding.mdwn
@@ -3,5 +3,5 @@ The link targets of annexed files are currently very long.   This creates proble
 
 Or, if you're tired of backend requests, maybe implement a scheme for external backends, like the one for external special remotes?  For external backend EXTNNN the user would put  a script git-annex-external-backend-NNN in the path; the script would support commands like calckey, examinekey .   Then I could also implement e.g. canonicalizing backends that strip away variable but semantically irrelevant information before computing the checksum.
 
-[[!meta title=avoid duplicating key twice in symlink to object file]]
+[[!meta title="avoid duplicating key twice in symlink to object file"]]
 [[!tag unlikely]]

diff --git a/doc/todo/confirmed.mdwn b/doc/todo/confirmed.mdwn
index b7686f11e..8df3805a1 100644
--- a/doc/todo/confirmed.mdwn
+++ b/doc/todo/confirmed.mdwn
@@ -1,8 +1,8 @@
 This tag is for todo items that have an agreed upon plan of action, but
 have not been implemented yet.
 
-[[!inline pages="./todo/* and !./todo/*/* and !./todo/done and !link(done) 
+[[!inline pages="todo/* and !todo/*/* and !todo/done and !link(todo/done) 
 and link(todo/confirmed)
-and !*/Discussion and !./todo/moreinfo and !./todo/confirmed
-and !./todo/needsthought and !./todo/unlikely" actions=yes postform=yes postformtext="Add a new todo titled:"
-show=0 feedlimit=10 archive=yes template=buglist]]
+and !*/Discussion and !todo/moreinfo and !todo/confirmed
+and !todo/needsthought and !todo/unlikely" show=0 feedlimit=10
+archive=yes template=buglist]]

diff --git a/doc/todo.mdwn b/doc/todo.mdwn
index 589434fae..2046d39d3 100644
--- a/doc/todo.mdwn
+++ b/doc/todo.mdwn
@@ -1,5 +1,5 @@
 This is git-annex's todo list. Link items to [[todo/done]] when done,
-or tags: [[todo/confirmed]] [[todo/moreinfo]] [[todo/needsthoughts]] [[todo/unlikely]] 
+or tags: [[todo/confirmed]] [[todo/moreinfo]] [[todo/needsthought]] [[todo/unlikely]] 
 
 [[!inline pages="./todo/* and !./todo/*/* and !./todo/done and !link(done) 
 and !*/Discussion and !./todo/moreinfo and !./todo/confirmed

diff --git a/doc/todo.mdwn b/doc/todo.mdwn
index 645ae41a7..589434fae 100644
--- a/doc/todo.mdwn
+++ b/doc/todo.mdwn
@@ -1,4 +1,5 @@
-This is git-annex's todo list. Link items to [[todo/done]] when done. A more complete [[design/roadmap/]] is also available.
+This is git-annex's todo list. Link items to [[todo/done]] when done,
+or tags: [[todo/confirmed]] [[todo/moreinfo]] [[todo/needsthoughts]] [[todo/unlikely]] 
 
 [[!inline pages="./todo/* and !./todo/*/* and !./todo/done and !link(done) 
 and !*/Discussion and !./todo/moreinfo and !./todo/confirmed
diff --git a/doc/todo/confirmed.mdwn b/doc/todo/confirmed.mdwn
index 8b59751e3..b7686f11e 100644
--- a/doc/todo/confirmed.mdwn
+++ b/doc/todo/confirmed.mdwn
@@ -1,2 +1,8 @@
 This tag is for todo items that have an agreed upon plan of action, but
 have not been implemented yet.
+
+[[!inline pages="./todo/* and !./todo/*/* and !./todo/done and !link(done) 
+and link(todo/confirmed)
+and !*/Discussion and !./todo/moreinfo and !./todo/confirmed
+and !./todo/needsthought and !./todo/unlikely" actions=yes postform=yes postformtext="Add a new todo titled:"
+show=0 feedlimit=10 archive=yes template=buglist]]

diff --git a/doc/todo/parallel_possibilities/comment_2_47499773db465e8b759d7c96cd7713a7._comment b/doc/todo/parallel_possibilities/comment_2_47499773db465e8b759d7c96cd7713a7._comment
new file mode 100644
index 000000000..ad2e5e9b2
--- /dev/null
+++ b/doc/todo/parallel_possibilities/comment_2_47499773db465e8b759d7c96cd7713a7._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2020-01-30T19:24:47Z"
+ content="""
+How would running parallel commands with xargs be better than the current
+-J?
+"""]]

diff --git a/doc/todo/S3_special_remote_support_for_DigitalOcean_Spaces.mdwn b/doc/bugs/S3_special_remote_support_for_DigitalOcean_Spaces.mdwn
similarity index 100%
rename from doc/todo/S3_special_remote_support_for_DigitalOcean_Spaces.mdwn
rename to doc/bugs/S3_special_remote_support_for_DigitalOcean_Spaces.mdwn
diff --git a/doc/todo/S3_special_remote_support_for_DigitalOcean_Spaces/comment_1_12fd9dfb47e157e1d38c5e88a543498b._comment b/doc/bugs/S3_special_remote_support_for_DigitalOcean_Spaces/comment_1_12fd9dfb47e157e1d38c5e88a543498b._comment
similarity index 100%
rename from doc/todo/S3_special_remote_support_for_DigitalOcean_Spaces/comment_1_12fd9dfb47e157e1d38c5e88a543498b._comment
rename to doc/bugs/S3_special_remote_support_for_DigitalOcean_Spaces/comment_1_12fd9dfb47e157e1d38c5e88a543498b._comment
diff --git a/doc/todo/git-annex-repair_claims_success_then_failure.mdwn b/doc/bugs/git-annex-repair_claims_success_then_failure.mdwn
similarity index 100%
rename from doc/todo/git-annex-repair_claims_success_then_failure.mdwn
rename to doc/bugs/git-annex-repair_claims_success_then_failure.mdwn
diff --git a/doc/todo/--get_option_for_diffdriver.mdwn b/doc/todo/--get_option_for_diffdriver.mdwn
index d6ad9a2b9..471814ae9 100644
--- a/doc/todo/--get_option_for_diffdriver.mdwn
+++ b/doc/todo/--get_option_for_diffdriver.mdwn
@@ -1 +1,3 @@
 since there is no generic 'fuse' mode, I would like to request to have `--get` (or `--auto-get`) option for diffdriver.  I am trying to compare files across two branches on a repo I just cloned.  I cannot download all the files  and downloading differing keys across branches for the same file is a bit painful.  So I felt that it would be super nice if git annex could auto get those files from somewhere (well -- original clone)
+
+[[!tag confirmed]]
diff --git a/doc/todo/Alternative_mode_control_for_import.mdwn b/doc/todo/Alternative_mode_control_for_import.mdwn
index 24bbd5ace..41a9b8bcb 100644
--- a/doc/todo/Alternative_mode_control_for_import.mdwn
+++ b/doc/todo/Alternative_mode_control_for_import.mdwn
@@ -15,3 +15,6 @@ Apologies for the brevity, I've already typed this out once..
     git annex import --mode=Ns $src        # (just creates symlinks for new)
     git annex import --mode=Nsd $src       # (invalid mode due to data loss)
     git annex import --mode=Nid $src       # (invalid or require --force)
+
+> Current thinking is in [[remove_legacy_import_directory_interface]].
+> This old todo is redundant, so [[wontfix|done]] --[[Joey]]
diff --git a/doc/todo/Bidirectional_metadata.mdwn b/doc/todo/Bidirectional_metadata.mdwn
index cdbdf614c..c455cf03c 100644
--- a/doc/todo/Bidirectional_metadata.mdwn
+++ b/doc/todo/Bidirectional_metadata.mdwn
@@ -19,3 +19,5 @@ There are other situations this is useful (and I use), for example, when I conve
     git annex metadata --parentchild original.svg compressed.png
 
 and this would set 'parent' and 'child' metadata respectively.
+
+[[!tag needsthought]]
diff --git a/doc/todo/Describe_a_file_in_function_of_another_file.mdwn b/doc/todo/Describe_a_file_in_function_of_another_file.mdwn
index 4df53b795..4993b3b3a 100644
--- a/doc/todo/Describe_a_file_in_function_of_another_file.mdwn
+++ b/doc/todo/Describe_a_file_in_function_of_another_file.mdwn
@@ -13,4 +13,5 @@ You may ask why it is useful? I have several usecases:
 Does git-annex provide such functionnality? If not, do you think it could be implementable?
 
 Thanks!
- 
+
+[[!tag unlikely]]
diff --git a/doc/todo/Invert_remote_selection.mdwn b/doc/todo/Invert_remote_selection.mdwn
index a091569f2..a30b23093 100644
--- a/doc/todo/Invert_remote_selection.mdwn
+++ b/doc/todo/Invert_remote_selection.mdwn
@@ -28,3 +28,5 @@ This problem comes up surprisingly often due to:
   5. Some repos being too large for a machine (e.g., repacking fails due to low memory), but which can still act like a dumb file-store.
 
 The problem gets worse when you have a lot of remotes or a lot of repos to manage (I have both). My impression is that this feature would require a syntax addition for git-annex-sync only. I like '!' because it behaves the same in GNU find and sh.
+
+[[!tag needsthought]]
diff --git a/doc/todo/Invert_remote_selection/comment_4_f5ab9eec7ed0f080c57dbb594deafd13._comment b/doc/todo/Invert_remote_selection/comment_4_f5ab9eec7ed0f080c57dbb594deafd13._comment
new file mode 100644
index 000000000..0e80fa227
--- /dev/null
+++ b/doc/todo/Invert_remote_selection/comment_4_f5ab9eec7ed0f080c57dbb594deafd13._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2020-01-30T19:13:25Z"
+ content="""
+git-annex sync does support remote groups, so that might also help with
+this use case without needing additional syntax?
+"""]]
diff --git a/doc/todo/MD5E_keys_without_file_size.mdwn b/doc/todo/MD5E_keys_without_file_size.mdwn
index ca88550db..12d50a9d9 100644
--- a/doc/todo/MD5E_keys_without_file_size.mdwn
+++ b/doc/todo/MD5E_keys_without_file_size.mdwn
@@ -1,3 +1,5 @@
 Would it be hard to support MD5E keys that omit the -sSIZE part, the way this is allowed for URL keys?  I have a use case where I have the MD5 hashes and filenames of files stored in the cloud, but not their sizes, and want to construct keys for these files to use with setpresentkey and registerurl.  I could construct URL keys, but then I lose the error-checking and have to set annex.security.allow-unverified-downloads .  Or maybe, extend URL keys to permit an -hMD5 hash to be part of the key?
 
 Another (and more generally useful) solution would be [[todo/alternate_keys_for_same_content/]].  Then can start with a URL-based key but then attach an MD5 to it as metadata, and have the key treated as a checksum-containing key, without needing to migrate the contents to a new key.
+
+[[!tag moreinfo]]
diff --git a/doc/todo/S3_export_redirecting_to_key-value_store.mdwn b/doc/todo/S3_export_redirecting_to_key-value_store.mdwn
index 2aab376bf..942e66a44 100644
--- a/doc/todo/S3_export_redirecting_to_key-value_store.mdwn
+++ b/doc/todo/S3_export_redirecting_to_key-value_store.mdwn
@@ -1,3 +1,5 @@
 S3 lets you [redirect](https://docs.aws.amazon.com/AmazonS3/latest/dev/how-to-page-redirect.html) requests for an object to another object, or to a URL.  This could be used to export a git branch, in the manner of [[`git-annex-export`|git-annex-export]], but with annexed objects redirecting to a key-value S3 remote in the same bucket.
 
 Related: [[todo/simpler__44___trusted_export_remotes]] ; [[forum/Using_hashdirlower_layout_for_S3_special_remote]].
+
+[[!tag needsthought unlikely]]
diff --git a/doc/todo/Wishlist__58___Parity_files_on_all_files.mdwn b/doc/todo/Wishlist__58___Parity_files_on_all_files.mdwn
index 01ebf8ce5..7e6d44aec 100644
--- a/doc/todo/Wishlist__58___Parity_files_on_all_files.mdwn
+++ b/doc/todo/Wishlist__58___Parity_files_on_all_files.mdwn
@@ -63,3 +63,5 @@ Thankfully, we already have a technology that can fill in elegantly here: parity
 
 
 This would also enhance the data-checking capabilities of git-annex, as data loss could be fixed and new parity files generated from the recovered files transparently, self-healing the archive.
+
+[[!tag unlikely]]
diff --git a/doc/todo/add_import_--to_command.mdwn b/doc/todo/add_import_--to_command.mdwn
index ed4c6066d..2e833e99e 100644
--- a/doc/todo/add_import_--to_command.mdwn
+++ b/doc/todo/add_import_--to_command.mdwn
@@ -4,3 +4,5 @@ I have a bunch of files I want to track with `git-annex` that are sitting in an
     git-annex import --to=s3-remote /mnt/usb-drive/myfiles
 
 The proposed `--to=remote` option would add the files to my repo as `import` normally does, but it wouldn't every keep the content in the repo, the only copy would now sit in `s3-remote`. As little disk space as possible would be staged temporarily in `~/my-laptop-repo`. Perhaps the easiest option would be to import a file normally, but them immediately do a `move` to `s3-remote`? But, ideally for larger files, we would want to stream them directly from `/mnt/usb-drive/myfiles` to `s3-remote` without ever staging them at `~/my-laptop-repo`.
+
+[[!tag unlikely needsthought]]
diff --git a/doc/todo/add_limit_to_matching_options.mdwn b/doc/todo/add_limit_to_matching_options.mdwn
index c009c87c4..7bcdce2a7 100644
--- a/doc/todo/add_limit_to_matching_options.mdwn
+++ b/doc/todo/add_limit_to_matching_options.mdwn
@@ -12,3 +12,5 @@ I often transfer files via mediums that have transfer limits, but I am eventuall
 
 
 Currently, I've been using tricks to select a subset of the files, such as a range of file-sizes.
+
+[[!tag needsthought]]
diff --git a/doc/todo/add_sftp_special_remote.mdwn b/doc/todo/add_sftp_special_remote.mdwn
index 690566688..b25f29411 100644
--- a/doc/todo/add_sftp_special_remote.mdwn
+++ b/doc/todo/add_sftp_special_remote.mdwn
@@ -21,3 +21,5 @@ repeatedly (though ssh connection caching helps some with that).
 > exposes this, when available. Some sftp servers can be locked down
 > so that the user can't run git-annex on them, so that could be the only
 > way to get diskreserve working for such a remote. --[[Joey]]
+
+[[!tag confirmed]]
diff --git a/doc/todo/add_tests_under_concurrency.mdwn b/doc/todo/add_tests_under_concurrency.mdwn
index 6421d3f3a..3363bd0c0 100644
--- a/doc/todo/add_tests_under_concurrency.mdwn
+++ b/doc/todo/add_tests_under_concurrency.mdwn
@@ -1 +1,3 @@
 To [[git-annex-test]] and [[git-annex-testremote]], add option to run tests under concurrency (-J).  Many possible bugs are unique to the concurrent case, and it's the case I often use.  While any bugs detected may be hard to reproduce, it's important to know _whether_ there are concurrency-related bugs.  Much of the trust in git-annex comes from its extensive test suite, but it's somewhat concerning to trust it with important data when the concurrency case is not tested at all.
+
+[[!tag unlikely]]
diff --git a/doc/todo/add_xxHash_backend.mdwn b/doc/todo/add_xxHash_backend.mdwn
index cf9143ea0..843304773 100644
--- a/doc/todo/add_xxHash_backend.mdwn
+++ b/doc/todo/add_xxHash_backend.mdwn
@@ -1 +1,3 @@
 From https://cyan4973.github.io/xxHash/ , xxHash seems much faster than md5 with comparable quality.  There's a Haskell implementation.
+
+[[!tag moreinfo]]
diff --git a/doc/todo/alternate_keys_for_same_content.mdwn b/doc/todo/alternate_keys_for_same_content.mdwn
index fcc4bf99b..81e93be62 100644
--- a/doc/todo/alternate_keys_for_same_content.mdwn
+++ b/doc/todo/alternate_keys_for_same_content.mdwn
@@ -9,3 +9,4 @@ Also, sometimes one can determine the MD5 from the URL without downloading the f
 or because an MD5 was computed by a workflow manager that produced the file (Cromwell does this).   The special remote's "CHECKURL" implementation could record an MD5E key in the
 alt_keys metadata field of the URL key.   Then 'addurl --fast' could check alt_keys, and store in git an MD5E key rather than a URL key, if available.
 
+[[!tag unlikely]]
diff --git a/doc/todo/alternate_keys_for_same_content/comment_1_7a7f287bcde5353072100294dd8edce6._comment b/doc/todo/alternate_keys_for_same_content/comment_1_7a7f287bcde5353072100294dd8edce6._comment
new file mode 100644
index 000000000..bb5460024
--- /dev/null
+++ b/doc/todo/alternate_keys_for_same_content/comment_1_7a7f287bcde5353072100294dd8edce6._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2020-01-30T18:36:17Z"
+ content="""
+This would mean that, every time something about a key is looked up in the
+git-annex branch, it would also need to look at the metadata to see if this
+`alt_keys` field is set.
+
+So it doubles the time of every single query of the git-annex branch.
+
+I don't think that's a good idea, querying the git-annex branch is already
+often a bottleneck to commands.
+"""]]
diff --git a/doc/todo/annex.thin_without_hardlinks.mdwn b/doc/todo/annex.thin_without_hardlinks.mdwn
index dd3047c78..f33b8db94 100644
--- a/doc/todo/annex.thin_without_hardlinks.mdwn
+++ b/doc/todo/annex.thin_without_hardlinks.mdwn
@@ -13,3 +13,5 @@ need a git hook run before checkout to rescue such files.
 Also some parts of git-annex's code, including `withObjectLoc`, assume
 that the .annex/objects is present, and so it would need to be changed
 to look at the work tree file. --[[Joey]]
+
+[[!tag needsthought]]
diff --git a/doc/todo/arm64_autobuilder.mdwn b/doc/todo/arm64_autobuilder.mdwn
index 22826d61b..4d2566575 100644
--- a/doc/todo/arm64_autobuilder.mdwn
+++ b/doc/todo/arm64_autobuilder.mdwn
@@ -11,3 +11,6 @@ autobuilder? --[[Joey]]
 
 Currently running release builds for arm64 on my phone, but it's not
 practical to run an autobuilder there. --[[Joey]]
+

(Diff truncated)

diff --git a/doc/todo/option_to_put_temp_files_on_a_RAM_disk/comment_4_8c6aa3f5aee359f2f161b6664cdb5c32._comment b/doc/todo/option_to_put_temp_files_on_a_RAM_disk/comment_4_8c6aa3f5aee359f2f161b6664cdb5c32._comment
index 8d38464e4..65f496130 100644
--- a/doc/todo/option_to_put_temp_files_on_a_RAM_disk/comment_4_8c6aa3f5aee359f2f161b6664cdb5c32._comment
+++ b/doc/todo/option_to_put_temp_files_on_a_RAM_disk/comment_4_8c6aa3f5aee359f2f161b6664cdb5c32._comment
@@ -3,11 +3,20 @@
  subject="""comment 4"""
  date="2020-01-30T16:44:52Z"
  content="""
-When git-annex downloads chunks, it uses a single file and seeks forward to
-the next chunk boundry when resuming, for example.
+When git-annex downloads chunks, it downloads one chunk at a time
+(no parallelisation downloads of chunks of the same key) to either a temp
+file or a memory buffer, decrypts if necessary, and then appends the
+chunk to the destination file.
 
-I agree with chrysn's analysis on all points.
+Since chunks are often stored entirely in ram, the chunk size is typically
+a small fraction of ram. It seems unlikely to me that the kernel would
+often decide to unncessarily flush a small write to a temp file out to disk
+and drop it from the cache when the very next operation after writing the
+file is reading it back in.
+
+chrysn's analysis seems right.
 
 Also, this smells of premature optimisation, and tying it to features that
-have not even been agreed on, let alone implemented or profiled, is weird.
+have not even been agreed on, let alone implemented, makes it kind of super
+low priority?
 """]]

diff --git a/doc/git-annex-reinject.mdwn b/doc/git-annex-reinject.mdwn
index e280a129b..cd91226c6 100644
--- a/doc/git-annex-reinject.mdwn
+++ b/doc/git-annex-reinject.mdwn
@@ -36,8 +36,13 @@ needing to specify the dest file.
 
   With this option, each specified src file is hashed using the default
   key-value backend (or the one specified with `--backend`), and if git-annex
-  has a record of the file having been in the annex before, the content is
-  reinjected.
+  has a record of the resulting key having been in the annex before, the
+  content is reinjected.
+
+  Note that, when using a key-value backend that includes the filename
+  extension in the key, this will only work if the src files have the same
+  extensions as the files with the same content that was originally added
+  to git-annex.
 
   Note that this will reinject old versions of files that have been
   modified or deleted from the current git branch.
diff --git a/doc/todo/git-annex-reinject_--known_should_not_fail_when_the_file_extension_is_different.mdwn b/doc/todo/git-annex-reinject_--known_should_not_fail_when_the_file_extension_is_different.mdwn
index c84177fe5..e0fbed78d 100644
--- a/doc/todo/git-annex-reinject_--known_should_not_fail_when_the_file_extension_is_different.mdwn
+++ b/doc/todo/git-annex-reinject_--known_should_not_fail_when_the_file_extension_is_different.mdwn
@@ -5,3 +5,5 @@ I think it would be better if `git annex reinject --known` would ignore the file
 This problem does not affect `git annex reinject` without `--known`.
 
 --spwhitton
+
+> mentioned this on the git-annex reinject man page; [[done]] --[[Joey]]

diff --git a/doc/todo/option_to_put_temp_files_on_a_RAM_disk/comment_4_8c6aa3f5aee359f2f161b6664cdb5c32._comment b/doc/todo/option_to_put_temp_files_on_a_RAM_disk/comment_4_8c6aa3f5aee359f2f161b6664cdb5c32._comment
new file mode 100644
index 000000000..8d38464e4
--- /dev/null
+++ b/doc/todo/option_to_put_temp_files_on_a_RAM_disk/comment_4_8c6aa3f5aee359f2f161b6664cdb5c32._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2020-01-30T16:44:52Z"
+ content="""
+When git-annex downloads chunks, it uses a single file and seeks forward to
+the next chunk boundry when resuming, for example.
+
+I agree with chrysn's analysis on all points.
+
+Also, this smells of premature optimisation, and tying it to features that
+have not even been agreed on, let alone implemented or profiled, is weird.
+"""]]