diff --git a/doc/bugs/__34__git_annex_adjust__34___does_not_respect_utf8_in_the_commit_author_field.mdwn b/doc/bugs/__34__git_annex_adjust__34___does_not_respect_utf8_in_the_commit_author_field.mdwn
new file mode 100644
index 000000000..25d73f568
--- /dev/null
+++ b/doc/bugs/__34__git_annex_adjust__34___does_not_respect_utf8_in_the_commit_author_field.mdwn
@@ -0,0 +1,9 @@
+### Please describe the problem.
+
+### What steps will reproduce the problem?
+
+I ran `git annex adjust --unlock` in a repo. `git-annex` did its job and added a commit with the description "git-annex adjusted branch". The author field does not seem to respect utf8, though. I get: "Author:     Félix <felix@example.com>" while I have "Author:     Félix <felix@example.com>" for all the other (manual) commits.
+
+### What version of git-annex are you using? On what operating system?
+
+Current Debian sid version: 7.20181205

diff --git a/doc/bugs/__34__git_update-index_--refresh_bigfile__34___fails_with___34__fatal__58___Out_of_memory__44___realloc_failed__34__/comment_2_13bd85f768c192afe2d7d5339a5250ac._comment b/doc/bugs/__34__git_update-index_--refresh_bigfile__34___fails_with___34__fatal__58___Out_of_memory__44___realloc_failed__34__/comment_2_13bd85f768c192afe2d7d5339a5250ac._comment
new file mode 100644
index 000000000..428a16d68
--- /dev/null
+++ b/doc/bugs/__34__git_update-index_--refresh_bigfile__34___fails_with___34__fatal__58___Out_of_memory__44___realloc_failed__34__/comment_2_13bd85f768c192afe2d7d5339a5250ac._comment
@@ -0,0 +1,83 @@
+[[!comment format=mdwn
+ username="gueux"
+ avatar="http://cdn.libravatar.org/avatar/47e44a21505727b2d6bb5d88f0468f34"
+ subject="comment 2"
+ date="2018-12-11T21:23:38Z"
+ content="""
+[[!format sh \"\"\"
+$ GIT_TRACE=1 strace -ff -e execve git update-index --refresh SERIES/bigfile.avi
+execve(\"/usr/bin/git\", [\"git\", \"update-index\", \"--refresh\", \"SERIES/bigfile.avi\"...], 0x7ffea5449570 /* 131 vars */) = 0
+22:19:30.019621 git.c:418               trace: built-in: git update-index --refresh 'SERIES/bigfile.avi'
+strace: Process 21256 attached
+strace: Process 21258 attached
+strace: Process 21260 attached
+strace: Process 21252 attached
+strace: Process 21253 attached
+strace: Process 21255 attached
+strace: Process 21257 attached
+strace: Process 21254 attached
+strace: Process 21259 attached
+[pid 21255] +++ exited with 0 +++
+[pid 21256] +++ exited with 0 +++
+[pid 21259] +++ exited with 0 +++
+[pid 21260] +++ exited with 0 +++
+[pid 21254] +++ exited with 0 +++
+[pid 21257] +++ exited with 0 +++
+[pid 21252] +++ exited with 0 +++
+[pid 21253] +++ exited with 0 +++
+[pid 21258] +++ exited with 0 +++
+strace: Process 21279 attached
+22:19:32.576855 run-command.c:643       trace: run_command: 'git-annex smudge --clean '\''CLIPS/otherfile.txt'\'''
+strace: Process 21280 attached
+[pid 21280] execve(\"/bin/sh\", [\"/bin/sh\", \"-c\", \"git-annex smudge --clean 'CLIPS/\"..., \"git-annex smudge --clean 'CLIPS/\"...], 0x7f47b4001f90 /* 133 vars */) = 0
+strace: Process 21281 attached
+[pid 21281] execve(\"/usr/bin/git-annex\", [\"git-annex\", \"smudge\", \"--clean\", \"CLIPS/otherfile.txt\"...], 0x5557f2cfdef8 /* 133 vars */) = 0
+strace: Process 21282 attached
+strace: Process 21283 attached
+strace: Process 21284 attached
+strace: Process 21285 attached
+[pid 21285] execve(\"/usr/lib/git-core/git\", [\"git\", \"config\", \"--null\", \"--list\"], 0x7ffc19e1be20 /* 133 vars */) = 0
+strace: Process 21286 attached
+22:19:32.761868 git.c:418               trace: built-in: git config --null --list
+[pid 21285] +++ exited with 0 +++
+[pid 21281] --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=21285, si_uid=1000, si_status=0, si_utime=0, si_stime=0} ---
+strace: Process 21287 attached
+[pid 21287] execve(\"/usr/lib/git-core/git\", [\"git\", \"--git-dir=.git\", \"--work-tree=.\", \"--literal-pathspecs\", \"cat-file\", \"--batch\"], 0x7ffc19e1be20 /* 132 vars */) = 0
+22:19:32.842280 git.c:418               trace: built-in: git cat-file --batch
+strace: Process 21288 attached
+[pid 21288] execve(\"/usr/lib/git-core/git\", [\"git\", \"--git-dir=.git\", \"--work-tree=.\", \"--literal-pathspecs\", \"cat-file\", \"--batch-check=%(objectname) %(ob\"...], 0x7ffc19e1be20 /* 132 vars */) = 0
+22:19:32.854004 git.c:418               trace: built-in: git cat-file '--batch-check=%(objectname) %(objecttype) %(objectsize)'
+strace: Process 21289 attached
+[pid 21289] execve(\"/usr/lib/git-core/git\", [\"git\", \"--git-dir=.git\", \"--work-tree=.\", \"--literal-pathspecs\", \"check-attr\", \"-z\", \"--stdin\", \"annex.backend\", \"annex.numcopies\", \"annex.largefiles\", \"--\"], 0x7ffc19e1be20 /* 132 vars */) = 0
+strace: Process 21290 attached
+[pid 21290] execve(\"/usr/lib/git-core/git\", [\"git\", \"--version\"], 0x7ffc19e1be20 /* 132 vars */) = 0
+22:19:32.934952 git.c:418               trace: built-in: git version
+22:19:32.935300 git.c:418               trace: built-in: git check-attr -z --stdin annex.backend annex.numcopies annex.largefiles --
+[pid 21290] +++ exited with 0 +++
+[pid 21281] --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=21290, si_uid=1000, si_status=0, si_utime=0, si_stime=0} ---
+strace: Process 21291 attached
+[pid 21287] +++ exited with 0 +++
+[pid 21281] --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=21287, si_uid=1000, si_status=0, si_utime=0, si_stime=0} ---
+[pid 21288] +++ exited with 0 +++
+[pid 21281] --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=21288, si_uid=1000, si_status=0, si_utime=0, si_stime=0} ---
+[pid 21289] +++ exited with 0 +++
+[pid 21281] --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=21289, si_uid=1000, si_status=0, si_utime=0, si_stime=0} ---
+[pid 21283] +++ exited with 0 +++
+[pid 21284] +++ exited with 0 +++
+[pid 21286] +++ exited with 0 +++
+[pid 21291] +++ exited with 0 +++
+[pid 21282] +++ exited with 0 +++
+[pid 21281] +++ exited with 0 +++
+[pid 21280] --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=21281, si_uid=1000, si_status=0, si_utime=2, si_stime=1} ---
+[pid 21280] +++ exited with 0 +++
+[pid 21251] --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=21280, si_uid=1000, si_status=0, si_utime=0, si_stime=0} ---
+[pid 21279] +++ exited with 0 +++
+fatal: Out of memory, realloc failed
+strace: Process 21292 attached
+[pid 21292] +++ exited with 128 +++
++++ exited with 128 +++
+
+
+
+\"\"\"]]
+"""]]

diff --git a/doc/special_remotes/tor.mdwn b/doc/special_remotes/tor.mdwn
index 12d3dfedf..bb07bd3a8 100644
--- a/doc/special_remotes/tor.mdwn
+++ b/doc/special_remotes/tor.mdwn
@@ -5,6 +5,6 @@ located.
 A git remote using tor has an url that looks like
 `tor-annex::2lssjzicvsxkdc2v.onion:19984`
 
-To set this up, use [[git-annex-enabletor]] and [[git-annex-p2p]],
+To set this up, use [[git-annex-enable-tor]] and [[git-annex-p2p]],
 and run [[git-annex-remotedaemon]] to serve the Tor hidden service.
 It's explained in detail in [[tips/peer_to_peer_network_with_tor]].

diff --git a/doc/bugs/__34__git_update-index_--refresh_bigfile__34___fails_with___34__fatal__58___Out_of_memory__44___realloc_failed__34__/comment_1_990498b543812acb1adf206d8d7d24eb._comment b/doc/bugs/__34__git_update-index_--refresh_bigfile__34___fails_with___34__fatal__58___Out_of_memory__44___realloc_failed__34__/comment_1_990498b543812acb1adf206d8d7d24eb._comment
new file mode 100644
index 000000000..423d85a0f
--- /dev/null
+++ b/doc/bugs/__34__git_update-index_--refresh_bigfile__34___fails_with___34__fatal__58___Out_of_memory__44___realloc_failed__34__/comment_1_990498b543812acb1adf206d8d7d24eb._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2018-12-11T20:40:36Z"
+ content="""
+It's strange that git runs the clean filter on CLIPS/otherfile.txt and not
+on the file it was asked to. But that is probably a red herring. Git gets
+past that extraneouss file and on to bigfile.avi before it crashes.
+
+The strace has a clone() and doesn't follow what happens in the child
+process. I'm not clear what that child process is doing, although it seems
+to involve the bigfile.avi that git is trying to mmap all into memory.
+It would be good to strace -f and check what gets exec()ed.
+"""]]

diff --git a/doc/devblog/day_557__upgrade_bugfixes.mdwn b/doc/devblog/day_557__upgrade_bugfixes.mdwn
new file mode 100644
index 000000000..04b7fb2b6
--- /dev/null
+++ b/doc/devblog/day_557__upgrade_bugfixes.mdwn
@@ -0,0 +1,10 @@
+Fixed several bugs involving upgrade to v7 when the git repository
+already v7 contained unlocked files. The worst of those involved direct
+mode and caused the whole file content to get checked into git. While
+that's a fairly unusual case, it's an ugly enough bug that I rushed out a
+release to fix it.
+
+Also, LWN has posted a
+[comparison of git-annex and git LFS](https://lwn.net/Articles/774125/).
+
+Today's work was sponsored by Trenton Cronholm [on Patreon](https://patreon.com/joeyh/).

diff --git a/doc/news/version_6.20181011.mdwn b/doc/news/version_6.20181011.mdwn
deleted file mode 100644
index 2e5bdadcd..000000000
--- a/doc/news/version_6.20181011.mdwn
+++ /dev/null
@@ -1,20 +0,0 @@
-git-annex 6.20181011 released with [[!toggle text="these changes"]]
-[[!toggleable text="""
-   * sync: Warn when a remote's export is not updated to the current
-     tree because export tracking is not configured.
-   * Improve display when git config download from a http remote fails.
-   * Added annex.jobs setting, which is like using the -J option.
-   * Fix reversion in support of annex.web-options.
-   * rmurl: Fix a case where removing the last url left git-annex thinking
-     content was still present in the web special remote.
-   * SETURLPRESENT, SETURIPRESENT, SETURLMISSING, and SETURIMISSING
-     used to update the presence information of the external special remote
-     that called them; this was not documented behavior and is no longer done.
-   * export: Fix false positive in export conflict detection, that occurred
-     when the same tree was exported by multiple clones.
-   * Fix potential crash in exporttree database due to failure to honor
-     uniqueness constraint.
-   * Fix crash when exporttree is set to a bad value.
-   * Linux standalone: Avoid using bundled cp before envionment is fully set up.
-   * Added arm64 Linux standalone build.
-   * Improved termux installation process."""]]
\ No newline at end of file
diff --git a/doc/news/version_7.20181211.mdwn b/doc/news/version_7.20181211.mdwn
new file mode 100644
index 000000000..7df15ef0b
--- /dev/null
+++ b/doc/news/version_7.20181211.mdwn
@@ -0,0 +1,23 @@
+git-annex 7.20181211 released with [[!toggle text="these changes"]]
+[[!toggleable text="""
+   * S3: Improve diagnostics when a remote is configured with exporttree and
+     versioning, but no S3 version id has been recorded for a key.
+   * findref: Support file matching options: --include, --exclude,
+     --want-get, --want-drop, --largerthan, --smallerthan, --accessedwithin
+   * Commands supporting --branch now apply file matching options --include,
+     --exclude, --want-get, --want-drop to filenames from the branch.
+     Previously, combining --branch with those would fail to match anything.
+   * add, import, findref: Support --time-limit.
+   * Add --branch option to git-annex find and mildly deprecate findref in
+     favor of it.
+   * webdav: When initializing, avoid trying to make a directory at the top of
+     the webdav server, which could never accomplish anything and failed on
+     nextcloud servers. (Reversion introduced in version 6.20170925.)
+   * Fix a case where upgrade to v7 caused git to think that unlocked files
+     were modified.
+   * Fix bug upgrading from direct mode to v7: when files in the repository
+     were already committed as v7 unlocked files elsewhere, and the
+     content was present in the direct mode repository, the annexed files
+     got their full content checked into git.
+   * Fix bug that caused v7 unlocked files in a direct mode repository
+     to get locked when committing."""]]
\ No newline at end of file

diff --git a/doc/bugs/__34__git_update-index_--refresh_bigfile__34___fails_with___34__fatal__58___Out_of_memory__44___realloc_failed__34__/comment_1_ea24c8553afcf5317bea3ca9a67ff1bc._comment b/doc/bugs/__34__git_update-index_--refresh_bigfile__34___fails_with___34__fatal__58___Out_of_memory__44___realloc_failed__34__/comment_1_ea24c8553afcf5317bea3ca9a67ff1bc._comment
deleted file mode 100644
index d5321247a..000000000
--- a/doc/bugs/__34__git_update-index_--refresh_bigfile__34___fails_with___34__fatal__58___Out_of_memory__44___realloc_failed__34__/comment_1_ea24c8553afcf5317bea3ca9a67ff1bc._comment
+++ /dev/null
@@ -1,34 +0,0 @@
-[[!comment format=mdwn
- username="gueux"
- avatar="http://cdn.libravatar.org/avatar/47e44a21505727b2d6bb5d88f0468f34"
- subject="strace"
- date="2018-12-11T18:36:50Z"
- content="""
-
-```
-...
-lstat(\"SERIES/bigfile.avi\", {st_mode=S_IFREG|0644, st_size=7130113113, ...}) = 0
-openat(AT_FDCWD, \"SERIES/bigfile.avi\", O_RDONLY) = 4
-openat(AT_FDCWD, \"SERIES/.gitattributes\", O_RDONLY) = -1 ENOENT (No such file or directory)
-mmap(NULL, 7130113113, PROT_READ, MAP_PRIVATE, 4, 0) = 0x7f338b031000
-pipe([5, 6])                            = 0
-fcntl(6, F_GETFD)                       = 0
-fcntl(6, F_SETFD, FD_CLOEXEC)           = 0
-clone(child_stack=0x7f35477fdfb0, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, parent_tidptr=0x7f35477fe9d0, tls=0x7f35477fe700, child_tidptr=0x7f35477fe9d0) = 7442
-mmap(NULL, 7130116096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = -1 ENOMEM (Cannot allocate memory)
-brk(0x556c98800000)                     = 0x556aef81c000
-mmap(NULL, 7130251264, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = -1 ENOMEM (Cannot allocate memory)
-mmap(NULL, 7130116096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = -1 ENOMEM (Cannot allocate memory)
-mmap(NULL, 7130116096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = -1 ENOMEM (Cannot allocate memory)
-mmap(NULL, 7130116096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = -1 ENOMEM (Cannot allocate memory)
-brk(0x556c98800000)                     = 0x556aef81c000
-mmap(NULL, 7130251264, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = -1 ENOMEM (Cannot allocate memory)
-write(2, \"fatal: Out of memory, realloc fa\"..., 37fatal: Out of memory, realloc failed
-) = 37
-getpid()                                = 7130
-close(3)                                = 0
-unlink(\"/home/myrepo/.git/index.lock\") = 0
-exit_group(128)                         = ?
-+++ exited with 128 +++
-```
-"""]]

diff --git a/doc/bugs/__34__git_update-index_--refresh_bigfile__34___fails_with___34__fatal__58___Out_of_memory__44___realloc_failed__34__.mdwn b/doc/bugs/__34__git_update-index_--refresh_bigfile__34___fails_with___34__fatal__58___Out_of_memory__44___realloc_failed__34__.mdwn
index 7119348b9..2a64bb92a 100644
--- a/doc/bugs/__34__git_update-index_--refresh_bigfile__34___fails_with___34__fatal__58___Out_of_memory__44___realloc_failed__34__.mdwn
+++ b/doc/bugs/__34__git_update-index_--refresh_bigfile__34___fails_with___34__fatal__58___Out_of_memory__44___realloc_failed__34__.mdwn
@@ -29,6 +29,34 @@ $ GIT_TRACE=1 git update-index --refresh SERIES/bigfile.avi
 SERIES/bigfile.avi: needs update
 fatal: Out of memory, realloc failed
 
+$ GIT_TRACE=1 strace git update-index --refresh SERIES/bigfile.avi
+lstat("SERIES", {st_mode=S_IFDIR|0755, st_size=754, ...}) = 0
+lstat("SERIES/bigfile.avi", {st_mode=S_IFREG|0644, st_size=7130113113, ...}) = 0
+write(1, "SERIES/bigfile.avi"..., 105SERIES/bigfile.avi: needs update
+) = 105
+lstat("SERIES/bigfile.avi", {st_mode=S_IFREG|0644, st_size=7130113113, ...}) = 0
+openat(AT_FDCWD, "SERIES/bigfile.avi", O_RDONLY) = 4
+openat(AT_FDCWD, "SERIES/.gitattributes", O_RDONLY) = -1 ENOENT (No such file or directory)
+mmap(NULL, 7130113113, PROT_READ, MAP_PRIVATE, 4, 0) = 0x7f338b031000
+pipe([5, 6])                            = 0
+fcntl(6, F_GETFD)                       = 0
+fcntl(6, F_SETFD, FD_CLOEXEC)           = 0
+clone(child_stack=0x7f35477fdfb0, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, parent_tidptr=0x7f35477fe9d0, tls=0x7f35477fe700, child_tidptr=0x7f35477fe9d0) = 7442
+mmap(NULL, 7130116096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = -1 ENOMEM (Cannot allocate memory)
+brk(0x556c98800000)                     = 0x556aef81c000
+mmap(NULL, 7130251264, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = -1 ENOMEM (Cannot allocate memory)
+mmap(NULL, 7130116096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = -1 ENOMEM (Cannot allocate memory)
+mmap(NULL, 7130116096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = -1 ENOMEM (Cannot allocate memory)
+mmap(NULL, 7130116096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = -1 ENOMEM (Cannot allocate memory)
+brk(0x556c98800000)                     = 0x556aef81c000
+mmap(NULL, 7130251264, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = -1 ENOMEM (Cannot allocate memory)
+write(2, "fatal: Out of memory, realloc fa"..., 37fatal: Out of memory, realloc failed
+) = 37
+getpid()                                = 7130
+close(3)                                = 0
+unlink("/mnt/video/video/.git/index.lock") = 0
+exit_group(128)                         = ?
++++ exited with 128 +++
 
 # End of transcript or log.
 """]]

diff --git a/doc/bugs/__34__git_update-index_--refresh_bigfile__34___fails_with___34__fatal__58___Out_of_memory__44___realloc_failed__34__/comment_1_ea24c8553afcf5317bea3ca9a67ff1bc._comment b/doc/bugs/__34__git_update-index_--refresh_bigfile__34___fails_with___34__fatal__58___Out_of_memory__44___realloc_failed__34__/comment_1_ea24c8553afcf5317bea3ca9a67ff1bc._comment
new file mode 100644
index 000000000..d5321247a
--- /dev/null
+++ b/doc/bugs/__34__git_update-index_--refresh_bigfile__34___fails_with___34__fatal__58___Out_of_memory__44___realloc_failed__34__/comment_1_ea24c8553afcf5317bea3ca9a67ff1bc._comment
@@ -0,0 +1,34 @@
+[[!comment format=mdwn
+ username="gueux"
+ avatar="http://cdn.libravatar.org/avatar/47e44a21505727b2d6bb5d88f0468f34"
+ subject="strace"
+ date="2018-12-11T18:36:50Z"
+ content="""
+
+```
+...
+lstat(\"SERIES/bigfile.avi\", {st_mode=S_IFREG|0644, st_size=7130113113, ...}) = 0
+openat(AT_FDCWD, \"SERIES/bigfile.avi\", O_RDONLY) = 4
+openat(AT_FDCWD, \"SERIES/.gitattributes\", O_RDONLY) = -1 ENOENT (No such file or directory)
+mmap(NULL, 7130113113, PROT_READ, MAP_PRIVATE, 4, 0) = 0x7f338b031000
+pipe([5, 6])                            = 0
+fcntl(6, F_GETFD)                       = 0
+fcntl(6, F_SETFD, FD_CLOEXEC)           = 0
+clone(child_stack=0x7f35477fdfb0, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, parent_tidptr=0x7f35477fe9d0, tls=0x7f35477fe700, child_tidptr=0x7f35477fe9d0) = 7442
+mmap(NULL, 7130116096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = -1 ENOMEM (Cannot allocate memory)
+brk(0x556c98800000)                     = 0x556aef81c000
+mmap(NULL, 7130251264, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = -1 ENOMEM (Cannot allocate memory)
+mmap(NULL, 7130116096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = -1 ENOMEM (Cannot allocate memory)
+mmap(NULL, 7130116096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = -1 ENOMEM (Cannot allocate memory)
+mmap(NULL, 7130116096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = -1 ENOMEM (Cannot allocate memory)
+brk(0x556c98800000)                     = 0x556aef81c000
+mmap(NULL, 7130251264, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = -1 ENOMEM (Cannot allocate memory)
+write(2, \"fatal: Out of memory, realloc fa\"..., 37fatal: Out of memory, realloc failed
+) = 37
+getpid()                                = 7130
+close(3)                                = 0
+unlink(\"/home/myrepo/.git/index.lock\") = 0
+exit_group(128)                         = ?
++++ exited with 128 +++
+```
+"""]]

diff --git a/doc/bugs/__34__git_update-index_--refresh_bigfile__34___fails_with___34__fatal__58___Out_of_memory__44___realloc_failed__34__.mdwn b/doc/bugs/__34__git_update-index_--refresh_bigfile__34___fails_with___34__fatal__58___Out_of_memory__44___realloc_failed__34__.mdwn
new file mode 100644
index 000000000..7119348b9
--- /dev/null
+++ b/doc/bugs/__34__git_update-index_--refresh_bigfile__34___fails_with___34__fatal__58___Out_of_memory__44___realloc_failed__34__.mdwn
@@ -0,0 +1,39 @@
+### Please describe the problem.
+
+`git update-index --refresh bigfile` fails with `fatal: Out of memory, realloc failed`
+
+### What steps will reproduce the problem?
+
+Have sizeOf bigfile > sizeOf memory?
+
+
+### What version of git-annex are you using? On what operating system?
+
+git-annex version: 7.20181205
+Debian sid
+
+### 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
+
+$ GIT_TRACE=1 git update-index --refresh SERIES/bigfile.avi
+19:08:14.507885 git.c:418               trace: built-in: git update-index --refresh 'SERIES/bigfile.avi'
+19:08:14.536105 run-command.c:643       trace: run_command: 'git-annex smudge --clean '\''CLIPS/otherfile.txt'\'''
+19:08:14.560898 git.c:418               trace: built-in: git config --null --list
+19:08:14.568523 git.c:418               trace: built-in: git cat-file --batch
+19:08:14.575319 git.c:418               trace: built-in: git cat-file '--batch-check=%(objectname) %(objecttype) %(objectsize)'
+19:08:14.585333 git.c:418               trace: built-in: git check-attr -z --stdin annex.backend annex.numcopies annex.largefiles --
+19:08:14.588845 git.c:418               trace: built-in: git version
+SERIES/bigfile.avi: needs update
+fatal: Out of memory, realloc failed
+
+
+# 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)
+
+Sure, I love it :)
+

diff --git a/Annex/Direct.hs b/Annex/Direct.hs
index 5ca9ec14a..c6c9b50fa 100644
--- a/Annex/Direct.hs
+++ b/Annex/Direct.hs
@@ -61,7 +61,10 @@ stageDirect = do
 		shakey <- catKey sha
 		mstat <- liftIO $ catchMaybeIO $ getSymbolicLinkStatus file
 		mcache <- liftIO $ maybe (pure Nothing) (toInodeCache delta file) mstat
-		filekey <- isAnnexLink file
+		filekey <- isAnnexLink file >>= \case
+			Just k -> return (Just k)
+			-- v7 unlocked pointer file
+			Nothing -> liftIO (isPointerFile file)
 		case (shakey, filekey, mstat, mcache) of
 			(_, Just key, _, _)
 				| shakey == filekey -> noop
diff --git a/CHANGELOG b/CHANGELOG
index a3978dc36..1c10d0372 100644
--- a/CHANGELOG
+++ b/CHANGELOG
@@ -15,6 +15,12 @@ git-annex (7.20181206) UNRELEASED; urgency=medium
     nextcloud servers. (Reversion introduced in version 6.20170925.)
   * Fix a case where upgrade to v7 caused git to think that unlocked files
     were modified.
+  * Fix bug upgrading from direct mode to v7: when files in the repository
+    were already committed as v7 unlocked files elsewhere, and the
+    content was present in the direct mode repository, the annexed files
+    got their full content checked into git.
+  * Fix bug that caused v7 unlocked files in a direct mode repository
+    to get locked when committing.
 
  -- Joey Hess <id@joeyh.name>  Thu, 06 Dec 2018 13:39:16 -0400
 
diff --git a/Upgrade/V5.hs b/Upgrade/V5.hs
index 999890150..383bc1db0 100644
--- a/Upgrade/V5.hs
+++ b/Upgrade/V5.hs
@@ -33,7 +33,6 @@ upgrade :: Bool -> Annex Bool
 upgrade automatic = do
 	unless automatic $
 		showAction "v5 to v6"
-	scanUnlockedFiles
 	whenM isDirect $ do
 		{- Direct mode makes the same tradeoff of using less disk
 		 - space, with less preservation of old versions of files
@@ -62,6 +61,7 @@ upgrade automatic = do
 		 - contents too, don't use git checkout to check out the
 		 - adjust branch. Instead, update HEAD manually. -}
 		inRepo $ setHeadRef b
+	scanUnlockedFiles
 	configureSmudgeFilter
 	-- Inode sentinal file was only used in direct mode and when
 	-- locking down files as they were added. In v6, it's used more
diff --git a/doc/bugs/direct_mode_to_v7_upgrade_bug.mdwn b/doc/bugs/direct_mode_to_v7_upgrade_bug.mdwn
index fa2ca7fda..ff03aa87f 100644
--- a/doc/bugs/direct_mode_to_v7_upgrade_bug.mdwn
+++ b/doc/bugs/direct_mode_to_v7_upgrade_bug.mdwn
@@ -9,4 +9,10 @@ Then, the upgrade to v7 from direct mode makes a commit
 "commit before upgrade to annex.version 6" which converts the pointer
 files into the full file content.
 
+Also, `git annex sync` in the direct mode repo before the upgrade
+converted the v7 unlocked files back to locked files. (While also a bug,
+this helped mask the other bug..)
+
+Both [[fixed|done]] now. 
+
 --[[Joey]]

diff --git a/doc/bugs/direct_mode_to_v7_upgrade_bug.mdwn b/doc/bugs/direct_mode_to_v7_upgrade_bug.mdwn
new file mode 100644
index 000000000..fa2ca7fda
--- /dev/null
+++ b/doc/bugs/direct_mode_to_v7_upgrade_bug.mdwn
@@ -0,0 +1,12 @@
+Upgrade from a direct mode repo to a v7 repo can cause annexed files to
+get checked into git, in an edge case.
+
+The annexed files need to be already v7 unlocked files, and their content
+needs to be present in the direct mode repo. Of course this is an unusual
+situation.
+
+Then, the upgrade to v7 from direct mode makes a commit 
+"commit before upgrade to annex.version 6" which converts the pointer
+files into the full file content.
+
+--[[Joey]]

diff --git a/doc/bugs/why_are_all_those_files_modified.mdwn b/doc/bugs/why_are_all_those_files_modified.mdwn
index c0a455188..fefeeebb1 100644
--- a/doc/bugs/why_are_all_those_files_modified.mdwn
+++ b/doc/bugs/why_are_all_those_files_modified.mdwn
@@ -18,3 +18,5 @@ Strangely, git doesn't see which changes are present here:
     $ 
 
 Workaround: `git checkout .` - but I don't understand why that is happening in the first place... Is that a bug? -- [[anarcat]]
+
+> update: yes, and it was [[fixed|done]] by joeyh.

diff --git a/doc/forum/why_are_all_those_files_modified.mdwn b/doc/bugs/why_are_all_those_files_modified.mdwn
similarity index 100%
rename from doc/forum/why_are_all_those_files_modified.mdwn
rename to doc/bugs/why_are_all_those_files_modified.mdwn
diff --git a/doc/forum/why_are_all_those_files_modified/comment_1_2a504fe76dc1715fc8989eeee603c8ab._comment b/doc/bugs/why_are_all_those_files_modified/comment_1_2a504fe76dc1715fc8989eeee603c8ab._comment
similarity index 100%
rename from doc/forum/why_are_all_those_files_modified/comment_1_2a504fe76dc1715fc8989eeee603c8ab._comment
rename to doc/bugs/why_are_all_those_files_modified/comment_1_2a504fe76dc1715fc8989eeee603c8ab._comment
diff --git a/doc/forum/why_are_all_those_files_modified/comment_2_0774937b43a9bc592f2c1160a0155b49._comment b/doc/bugs/why_are_all_those_files_modified/comment_2_0774937b43a9bc592f2c1160a0155b49._comment
similarity index 100%
rename from doc/forum/why_are_all_those_files_modified/comment_2_0774937b43a9bc592f2c1160a0155b49._comment
rename to doc/bugs/why_are_all_those_files_modified/comment_2_0774937b43a9bc592f2c1160a0155b49._comment
diff --git a/doc/forum/why_are_all_those_files_modified/comment_3_b5deb8580c5874c50b85fd1c29ed30b3._comment b/doc/bugs/why_are_all_those_files_modified/comment_3_b5deb8580c5874c50b85fd1c29ed30b3._comment
similarity index 100%
rename from doc/forum/why_are_all_those_files_modified/comment_3_b5deb8580c5874c50b85fd1c29ed30b3._comment
rename to doc/bugs/why_are_all_those_files_modified/comment_3_b5deb8580c5874c50b85fd1c29ed30b3._comment
diff --git a/doc/forum/why_are_all_those_files_modified/comment_4_0d8c289f0f2bbff9158dc1eb6ab05863._comment b/doc/bugs/why_are_all_those_files_modified/comment_4_0d8c289f0f2bbff9158dc1eb6ab05863._comment
similarity index 100%
rename from doc/forum/why_are_all_those_files_modified/comment_4_0d8c289f0f2bbff9158dc1eb6ab05863._comment
rename to doc/bugs/why_are_all_those_files_modified/comment_4_0d8c289f0f2bbff9158dc1eb6ab05863._comment
diff --git a/doc/forum/why_are_all_those_files_modified/comment_5_ade6edafc859f53845fef5ba0c92fb1b._comment b/doc/bugs/why_are_all_those_files_modified/comment_5_ade6edafc859f53845fef5ba0c92fb1b._comment
similarity index 100%
rename from doc/forum/why_are_all_those_files_modified/comment_5_ade6edafc859f53845fef5ba0c92fb1b._comment
rename to doc/bugs/why_are_all_those_files_modified/comment_5_ade6edafc859f53845fef5ba0c92fb1b._comment
diff --git a/doc/forum/why_are_all_those_files_modified/comment_6_65a5c2ca20f1efbf94e2b1d5309ddecc._comment b/doc/bugs/why_are_all_those_files_modified/comment_6_65a5c2ca20f1efbf94e2b1d5309ddecc._comment
similarity index 100%
rename from doc/forum/why_are_all_those_files_modified/comment_6_65a5c2ca20f1efbf94e2b1d5309ddecc._comment
rename to doc/bugs/why_are_all_those_files_modified/comment_6_65a5c2ca20f1efbf94e2b1d5309ddecc._comment

diff --git a/doc/forum/why_are_all_those_files_modified/comment_6_65a5c2ca20f1efbf94e2b1d5309ddecc._comment b/doc/forum/why_are_all_those_files_modified/comment_6_65a5c2ca20f1efbf94e2b1d5309ddecc._comment
new file mode 100644
index 000000000..165556cab
--- /dev/null
+++ b/doc/forum/why_are_all_those_files_modified/comment_6_65a5c2ca20f1efbf94e2b1d5309ddecc._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="anarcat"
+ avatar="http://cdn.libravatar.org/avatar/4ad594c1e13211c1ad9edb81ce5110b7"
+ subject="possibly"
+ date="2018-12-11T17:06:19Z"
+ content="""
+> Does that sequence match what you were doing? I didn't reproduce the problem when just upgrading the v5 and then getting the unlocked files into it.
+
+I don't *exactly* remember, unfortunately, but that seems likely. It matches my previous comment, which indicates I upgraded to the backport *after* filing the bug report anyways.
+
+> Seems that the upgrade to v7 process, after scanning for and populating unlocked files, needs to update git's index. I thought it did, but perhaps I forgot or that is not working.
+
+Makes sense! :)
+"""]]

diff --git a/Annex/WorkTree.hs b/Annex/WorkTree.hs
index 89d80c0ca..84ee39f4c 100644
--- a/Annex/WorkTree.hs
+++ b/Annex/WorkTree.hs
@@ -14,6 +14,8 @@ import Annex.Version
 import Annex.Content
 import Annex.ReplaceFile
 import Annex.CurrentBranch
+import Annex.InodeSentinal
+import Utility.InodeCache
 import Config
 import Git.FilePath
 import qualified Git.Ref
@@ -84,9 +86,13 @@ scanUnlockedFiles = whenM (isJust <$> inRepo Git.Branch.current) $ do
 		whenM (inAnnex k) $ do
 			f <- fromRepo $ fromTopFilePath tf
 			destmode <- liftIO $ catchMaybeIO $ fileMode <$> getFileStatus f
-			replaceFile f $ \tmp ->
+			ic <- replaceFile f $ \tmp ->
 				linkFromAnnex k tmp destmode >>= \case
-					LinkAnnexOk -> return ()
-					LinkAnnexNoop -> return ()
-					LinkAnnexFailed -> liftIO $
+					LinkAnnexOk -> 
+						withTSDelta (liftIO . genInodeCache tmp)
+					LinkAnnexNoop -> return Nothing
+					LinkAnnexFailed -> liftIO $ do
 						writePointerFile tmp k destmode
+						return Nothing
+			liftIO $ print ic
+			maybe noop (restagePointerFile (Restage True) f) ic
diff --git a/CHANGELOG b/CHANGELOG
index 5a6c05cf8..a3978dc36 100644
--- a/CHANGELOG
+++ b/CHANGELOG
@@ -13,6 +13,8 @@ git-annex (7.20181206) UNRELEASED; urgency=medium
   * webdav: When initializing, avoid trying to make a directory at the top of
     the webdav server, which could never accomplish anything and failed on
     nextcloud servers. (Reversion introduced in version 6.20170925.)
+  * Fix a case where upgrade to v7 caused git to think that unlocked files
+    were modified.
 
  -- Joey Hess <id@joeyh.name>  Thu, 06 Dec 2018 13:39:16 -0400
 
diff --git a/doc/forum/why_are_all_those_files_modified/comment_5_ade6edafc859f53845fef5ba0c92fb1b._comment b/doc/forum/why_are_all_those_files_modified/comment_5_ade6edafc859f53845fef5ba0c92fb1b._comment
new file mode 100644
index 000000000..7c4ef1305
--- /dev/null
+++ b/doc/forum/why_are_all_those_files_modified/comment_5_ade6edafc859f53845fef5ba0c92fb1b._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2018-12-11T17:03:38Z"
+ content="""
+Fixed the problem I described.
+"""]]

diff --git a/doc/bugs/Unable_to_addurl_file__58____47____47____47___on_Windows.mdwn b/doc/bugs/Unable_to_addurl_file__58____47____47____47___on_Windows.mdwn
index 17c654892..8a482fb47 100644
--- a/doc/bugs/Unable_to_addurl_file__58____47____47____47___on_Windows.mdwn
+++ b/doc/bugs/Unable_to_addurl_file__58____47____47____47___on_Windows.mdwn
@@ -1,9 +1,9 @@
 ### Please describe the problem.
 
-Unable to addurl to a file:/// on Windows
+Unable to addurl to a `file:///` on Windows
 
-1. doesn't understand file:///
-2. with file:// blows with permission denied:
+1. doesn't understand `file:///C:/`
+2. with `file://C:/` blows with permission denied:
 
 [[!format sh """
 C:\...pData\Local\Temp\1\datalad_temp_testrepo_tmphjl88>git annex addurl --file buga file:///C:/123
@@ -61,3 +61,5 @@ More information about this appveyor server could be obtained from [datalad wtf]
 
 Awhile back we [had related discussion](https://git-annex.branchable.com/bugs/git-annex_drop_fails_to_access_file__58____47____47____47___target_URL_on_Windows/) but at least `addurl` seemed to work then.
 
+
+[[!meta author=yoh]]

diff --git a/doc/bugs/cannot_talk_with_nextcloud_server.mdwn b/doc/bugs/cannot_talk_with_nextcloud_server.mdwn
index 7d0c18e9b..84f184165 100644
--- a/doc/bugs/cannot_talk_with_nextcloud_server.mdwn
+++ b/doc/bugs/cannot_talk_with_nextcloud_server.mdwn
@@ -127,7 +127,7 @@ Incidentally, the [[tips/owncloudannex]] remote also [fails](https://github.com/
 
 ### 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 use git-annex every day! I hope to write a glowing review for LWN soon. ;) Cheers and hi joey! :)
+I use git-annex every day! I hope to write a glowing review for LWN soon. ;) Cheers and hi joey! :) -- [[anarcat]]
 
 > So the problem is code was changed a while ago to `mkColRecursive "/"`
 > which causes this wacky attempt to mkcol at the top of the server not

diff --git a/doc/bugs/Unable_to_addurl_file__58____47____47____47___on_Windows.mdwn b/doc/bugs/Unable_to_addurl_file__58____47____47____47___on_Windows.mdwn
new file mode 100644
index 000000000..17c654892
--- /dev/null
+++ b/doc/bugs/Unable_to_addurl_file__58____47____47____47___on_Windows.mdwn
@@ -0,0 +1,63 @@
+### Please describe the problem.
+
+Unable to addurl to a file:/// on Windows
+
+1. doesn't understand file:///
+2. with file:// blows with permission denied:
+
+[[!format sh """
+C:\...pData\Local\Temp\1\datalad_temp_testrepo_tmphjl88>git annex addurl --file buga file:///C:/123
+addurl file:///C:/123
+download failed: /C:/123: openBinaryFile: invalid argument (Invalid argument)
+failed
+git-annex: addurl: 1 failed
+
+C:\...pData\Local\Temp\1\datalad_temp_testrepo_tmphjl88>git annex addurl --file buga file://C:/123
+addurl file://C:/123
+(to buga)
+git-annex: .git\annex\tmp\URL-s6--file&c%%C&c%123: renameFile:renamePath:MoveFileEx "\\\\?\\C:\\Users\\appveyor\\
+AppData\\Local\\Temp\\1\\datalad_temp_testrepo_tmphjl88\\.git\\annex\\tmp\\URL-s6--file&c%%C&c%123" Just "\\\\?\\
+C:\\Users\\appveyor\\AppData\\Local\\Temp\\1\\datalad_temp_testrepo_tmphjl88\\buga": permission denied (The proce
+ss cannot access the file because it is being used by another process.)
+failed
+git-annex: addurl: 1 failed
+
+"""]]
+
+here is some relevant details (and showing curl handling both file:// and file:///):
+[[!format sh """
+C:\...pData\Local\Temp\1\datalad_temp_testrepo_tmphjl88>git status
+On branch adjusted/master(unlocked)
+nothing to commit, working tree clean
+
+C:\...pData\Local\Temp\1\datalad_temp_testrepo_tmphjl88>git annex version
+git-annex version: 7.20181205-g51d6f38b1
+build flags: Assistant Webapp Pairing S3(multipartupload)(storageclasses) WebDAV TorrentParser Feeds Testsuite
+dependency versions: aws-0.17.1 bloomfilter-2.0.1.0 cryptonite-0.23 DAV-1.3.1 feed-0.3.12.0 ghc-8.0.2 http-client
+-0.5.7.1 persistent-sqlite-2.6.2 torrent-10000.1.1 uuid-1.3.13 yesod-1.4.5
+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 BLAKE2B51
+2E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2S256E BLAKE2S256 BLAKE2S
+160E 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 hook external
+operating system: mingw32 i386
+supported repository versions: 5 7
+upgrade supported from repository versions: 2 3 4 5 6
+local repository version: 7
+
+C:\...pData\Local\Temp\1\datalad_temp_testrepo_tmphjl88>git status
+On branch adjusted/master(unlocked)
+nothing to commit, working tree clean
+
+C:\...pData\Local\Temp\1\datalad_temp_testrepo_tmphjl88>curl file://C:/123
+124
+
+C:\...pData\Local\Temp\1\datalad_temp_testrepo_tmphjl88>curl file:///C:/123
+124
+"""]]
+
+More information about this appveyor server could be obtained from [datalad wtf](http://paste.debian.net/1055359/) output
+
+Awhile back we [had related discussion](https://git-annex.branchable.com/bugs/git-annex_drop_fails_to_access_file__58____47____47____47___target_URL_on_Windows/) but at least `addurl` seemed to work then.
+

diff --git a/doc/forum/why_are_all_those_files_modified/comment_4_0d8c289f0f2bbff9158dc1eb6ab05863._comment b/doc/forum/why_are_all_those_files_modified/comment_4_0d8c289f0f2bbff9158dc1eb6ab05863._comment
new file mode 100644
index 000000000..247a5a25d
--- /dev/null
+++ b/doc/forum/why_are_all_those_files_modified/comment_4_0d8c289f0f2bbff9158dc1eb6ab05863._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2018-12-11T16:27:27Z"
+ content="""
+I reproduced as follows:
+
+* Have a v7 repository, and unlock a couple of files.
+* Clone to a v5 repository.
+* Get the files into the v5 repository. (git annex get won't work on the
+  unlocked files, but you can get --all or copy from the v7 to the v5 or
+  whatever)
+* Upgrade the v5 repository to v7.
+
+Does that sequence match what you were doing? I didn't reproduce the
+problem when just upgrading the v5 and then getting the unlocked files into it.
+
+Seems that the upgrade to v7 process, after scanning for and populating
+unlocked files, needs to update git's index. I thought it did, but perhaps
+I forgot or that is not working.
+"""]]

diff --git a/doc/forum/android_installation/comment_2_3c2a1e7542993528250ad72079894364._comment b/doc/forum/android_installation/comment_2_3c2a1e7542993528250ad72079894364._comment
new file mode 100644
index 000000000..d6090ba16
--- /dev/null
+++ b/doc/forum/android_installation/comment_2_3c2a1e7542993528250ad72079894364._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="tritigr"
+ avatar="http://cdn.libravatar.org/avatar/b48e7ad14f74123cd33968fc1b747cb5"
+ subject="comment 2"
+ date="2018-12-10T21:28:59Z"
+ content="""
+Hi Joey,
+
+thanks for helping.
+Unfortunately, installation with arm64 fails with something that 64bit executables are not supported.
+using \"armel\" installation seems ok, (\"git-annex is sucessfully installed; installation complete\")
+
+but then \"git annex webapp\" gives
+git: 'annex' is not a git command
+
+using \"arm\" (without the \"el\") gives Error 404 on downloading, so I guess you really meant \"armel\" (32 bits)
+
+Til
+"""]]

diff --git a/debian/control b/debian/control
index 66a667122..9790a1e33 100644
--- a/debian/control
+++ b/debian/control
@@ -89,7 +89,7 @@ Build-Depends:
 	gpg-agent,
 Maintainer: Richard Hartmann <richih@debian.org>
 Standards-Version: 3.9.8
-Vcs-Git: git://git.kitenet.net/git-annex
+Vcs-Git: git://git.joeyh.name/git-annex
 Homepage: http://git-annex.branchable.com/
 XS-Testsuite: autopkgtest
 
diff --git a/doc/bugs/gitweb_link_is_wrong_on_download_page.mdwn b/doc/bugs/gitweb_link_is_wrong_on_download_page.mdwn
index ff2397d6f..d76812d73 100644
--- a/doc/bugs/gitweb_link_is_wrong_on_download_page.mdwn
+++ b/doc/bugs/gitweb_link_is_wrong_on_download_page.mdwn
@@ -1 +1,3 @@
 link [gitweb](https://git.kitenet.net/?p=git-annex.git;a=summary) on [http://git-annex.branchable.com/download/](http://git-annex.branchable.com/download/) leads to cgit error Invalid request
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/download.mdwn b/doc/download.mdwn
index cda592589..e2a88daef 100644
--- a/doc/download.mdwn
+++ b/doc/download.mdwn
@@ -1,28 +1,27 @@
 The main git repository for git-annex is `git://git-annex.branchable.com/`
+[[gitweb](http://source.git-annex.branchable.com/?p=source.git;a=summary)]
 
 (You can push changes to this wiki from that anonymous git checkout.)
 
 Other mirrors of the git repository:
 
-* `git://git.kitenet.net/git-annex` [[gitweb](http://git.kitenet.net/?p=git-annex.git;a=summary)]
+* `git://git.joey.name/git-annex` or `https://git.joeyh.name/git/git-annex.git` [[gitweb](https://git.joeyh.name/index.cgi/git-annex.git/)]
 
 Releases of git-annex are uploaded
 [to hackage](http://hackage.haskell.org/package/git-annex). Note that the
 tarball there is not the complete git-annex source tree, but only a subset
-to make `cabal install` work. Use git to checkout the full source tree.
+to make cabal/stack install work. Use git to checkout the full source tree.
 
 Some operating systems include git-annex in easily prepackaged form and
 others need some manual work. See [[install]] for details.
 
 ## git branches
 
-The git repository has some branches:
+The git repository has some branches, including:
 
 * `ghc7.0` is a by now very out of date branch that can be built with
   ghc 7.0.
 * `debian-*-backport` contains the latest backport of git-annex.
-* `tweak-fetch` adds support for the git tweak-fetch hook, which has
-  been proposed and implemented but not yet accepted into git.
 * `setup` contains configuration for this website
 
 ----

diff --git a/CHANGELOG b/CHANGELOG
index f79708af1..5a6c05cf8 100644
--- a/CHANGELOG
+++ b/CHANGELOG
@@ -10,6 +10,9 @@ git-annex (7.20181206) UNRELEASED; urgency=medium
   * add, import, findref: Support --time-limit.
   * Add --branch option to git-annex find and mildly deprecate findref in
     favor of it.
+  * webdav: When initializing, avoid trying to make a directory at the top of
+    the webdav server, which could never accomplish anything and failed on
+    nextcloud servers. (Reversion introduced in version 6.20170925.)
 
  -- Joey Hess <id@joeyh.name>  Thu, 06 Dec 2018 13:39:16 -0400
 
diff --git a/Remote/WebDAV.hs b/Remote/WebDAV.hs
index 566ce69bd..22e20fec6 100644
--- a/Remote/WebDAV.hs
+++ b/Remote/WebDAV.hs
@@ -274,7 +274,6 @@ testDav url (Just (u, p)) = do
 	test $ liftIO $ evalDAVT url $ do
 		prepDAV user pass
 		makeParentDirs
-		void $ mkColRecursive "/"
 		inLocation (tmpLocation "test") $ do
 			putContentM (Nothing, L8.fromString "test")
 			delContentM
diff --git a/doc/bugs/cannot_talk_with_nextcloud_server.mdwn b/doc/bugs/cannot_talk_with_nextcloud_server.mdwn
index a84eca593..7d0c18e9b 100644
--- a/doc/bugs/cannot_talk_with_nextcloud_server.mdwn
+++ b/doc/bugs/cannot_talk_with_nextcloud_server.mdwn
@@ -128,3 +128,7 @@ Incidentally, the [[tips/owncloudannex]] remote also [fails](https://github.com/
 ### 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 use git-annex every day! I hope to write a glowing review for LWN soon. ;) Cheers and hi joey! :)
+
+> So the problem is code was changed a while ago to `mkColRecursive "/"`
+> which causes this wacky attempt to mkcol at the top of the server not
+> underneath the path of the url. [[fixed|done]] --[[Joey]]

diff --git a/doc/bugs/gitweb_link_is_wrong_on_download_page.mdwn b/doc/bugs/gitweb_link_is_wrong_on_download_page.mdwn
index 46a260a84..ff2397d6f 100644
--- a/doc/bugs/gitweb_link_is_wrong_on_download_page.mdwn
+++ b/doc/bugs/gitweb_link_is_wrong_on_download_page.mdwn
@@ -1 +1 @@
-link [[gitweb]](https://git.kitenet.net/?p=git-annex.git;a=summary) on [http://git-annex.branchable.com/download/](http://git-annex.branchable.com/download/) leads to cgit error Invalid request
+link [gitweb](https://git.kitenet.net/?p=git-annex.git;a=summary) on [http://git-annex.branchable.com/download/](http://git-annex.branchable.com/download/) leads to cgit error Invalid request

diff --git a/doc/bugs/gitweb_link_is_wrong_on_download_page.mdwn b/doc/bugs/gitweb_link_is_wrong_on_download_page.mdwn
new file mode 100644
index 000000000..46a260a84
--- /dev/null
+++ b/doc/bugs/gitweb_link_is_wrong_on_download_page.mdwn
@@ -0,0 +1 @@
+link [[gitweb]](https://git.kitenet.net/?p=git-annex.git;a=summary) on [http://git-annex.branchable.com/download/](http://git-annex.branchable.com/download/) leads to cgit error Invalid request

diff --git a/doc/forum/assistant_to_have_synced_folders/comment_13_9b8631b1fb4c9992203efc2d29cfae8d._comment b/doc/forum/assistant_to_have_synced_folders/comment_13_9b8631b1fb4c9992203efc2d29cfae8d._comment
new file mode 100644
index 000000000..f7d048788
--- /dev/null
+++ b/doc/forum/assistant_to_have_synced_folders/comment_13_9b8631b1fb4c9992203efc2d29cfae8d._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="xsteadfastx"
+ avatar="http://cdn.libravatar.org/avatar/a07e2adf7ff40bdd4c3fe20ededc0a4e"
+ subject="comment 13"
+ date="2018-12-10T10:41:05Z"
+ content="""
+this is brilliant. thank you. i gave up and thought its something about my setup or something :) 
+"""]]

diff --git a/doc/devblog/day_556__snow_day.mdwn b/doc/devblog/day_556__snow_day.mdwn
new file mode 100644
index 000000000..e2d199649
--- /dev/null
+++ b/doc/devblog/day_556__snow_day.mdwn
@@ -0,0 +1,6 @@
+Snowed in and without internet until now, I've been working on the backlog.
+This included adding `git annex find --branch` and adding support
+for combining options like `--include`, `--largerthan` etc with
+`--branch`.
+
+Today's work was sponsored by Jake Vosloo [on Patreon](https://patreon.com/joeyh/).

diff --git a/CHANGELOG b/CHANGELOG
index 96ede489f..f79708af1 100644
--- a/CHANGELOG
+++ b/CHANGELOG
@@ -8,6 +8,8 @@ git-annex (7.20181206) UNRELEASED; urgency=medium
     --exclude, --want-get, --want-drop to filenames from the branch.
     Previously, combining --branch with those would fail to match anything.
   * add, import, findref: Support --time-limit.
+  * Add --branch option to git-annex find and mildly deprecate findref in
+    favor of it.
 
  -- Joey Hess <id@joeyh.name>  Thu, 06 Dec 2018 13:39:16 -0400
 
diff --git a/CmdLine/GitAnnex/Options.hs b/CmdLine/GitAnnex/Options.hs
index 253574bf6..4f9978258 100644
--- a/CmdLine/GitAnnex/Options.hs
+++ b/CmdLine/GitAnnex/Options.hs
@@ -174,10 +174,7 @@ data KeyOptions
 
 parseKeyOptions :: Parser KeyOptions
 parseKeyOptions = parseAllOption
-	<|> WantBranchKeys <$> some (option (str >>= pure . Ref)
-		( long "branch" <> metavar paramRef
-		<> help "operate on files in the specified branch or treeish"
-		))
+	<|> parseBranchKeysOption
 	<|> flag' WantUnusedKeys
 		( long "unused" <> short 'U'
 		<> help "operate on files found by last run of git-annex unused"
@@ -187,6 +184,13 @@ parseKeyOptions = parseAllOption
 		<> help "operate on specified key"
 		))
 
+parseBranchKeysOption :: Parser KeyOptions
+parseBranchKeysOption =
+	WantBranchKeys <$> some (option (str >>= pure . Ref)
+		( long "branch" <> metavar paramRef
+		<> help "operate on files in the specified branch or treeish"
+		))
+
 parseFailedTransfersOption :: Parser KeyOptions
 parseFailedTransfersOption = flag' WantFailedTransfers
 	( long "failed"
diff --git a/CmdLine/Seek.hs b/CmdLine/Seek.hs
index 8b65532dc..efb373fb4 100644
--- a/CmdLine/Seek.hs
+++ b/CmdLine/Seek.hs
@@ -79,22 +79,6 @@ withFilesNotInGit skipdotfiles a l
 	go fs = seekActions $ prepFiltered a $
 		return $ concat $ segmentPaths (map (\(WorkTreeItem f) -> f) l) fs
 
-withFilesInRefs :: ((FilePath, Key) -> CommandSeek) -> [Git.Ref] -> CommandSeek
-withFilesInRefs a = mapM_ go
-  where
-	go r = do	
-		matcher <- Limit.getMatcher
-		(l, cleanup) <- inRepo $ LsTree.lsTree r
-		forM_ l $ \ti -> do
-			let f = getTopFilePath $ LsTree.file ti
-			catKey (LsTree.sha ti) >>= \case
-				Nothing -> noop
-				Just k -> 
-					let i = MatchingKey k (AssociatedFile (Just f))
-					in whenM (matcher i) $
-						a (f, k)
-		liftIO $ void cleanup
-
 withPathContents :: ((FilePath, FilePath) -> CommandSeek) -> CmdParams -> CommandSeek
 withPathContents a params = do
 	matcher <- Limit.getMatcher
diff --git a/Command/Find.hs b/Command/Find.hs
index 46b8d9803..9c7b82016 100644
--- a/Command/Find.hs
+++ b/Command/Find.hs
@@ -1,6 +1,6 @@
 {- git-annex command
  -
- - Copyright 2010-2012 Joey Hess <id@joeyh.name>
+ - Copyright 2010-2018 Joey Hess <id@joeyh.name>
  -
  - Licensed under the GNU GPL version 3 or higher.
  -}
@@ -14,6 +14,8 @@ import Command
 import Annex.Content
 import Limit
 import Types.Key
+import Types.ActionItem
+import Git.FilePath
 import qualified Utility.Format
 import Utility.DataUnits
 
@@ -28,6 +30,7 @@ mkCommand = noCommit . noMessages . withGlobalOptions [jsonOptions]
 data FindOptions = FindOptions
 	{ findThese :: CmdParams
 	, formatOption :: Maybe Utility.Format.Format
+	, keyOptions :: Maybe KeyOptions
 	, batchOption :: BatchMode
 	}
 
@@ -35,6 +38,7 @@ optParser :: CmdParamsDesc -> Parser FindOptions
 optParser desc = FindOptions
 	<$> cmdParams desc
 	<*> optional parseFormatOption
+	<*> optional parseBranchKeysOption
 	<*> parseBatchOption
 
 parseFormatOption :: Parser Utility.Format.Format
@@ -50,7 +54,9 @@ parseFormatOption =
 
 seek :: FindOptions -> CommandSeek
 seek o = case batchOption o of
-	NoBatch -> withFilesInGit (commandAction . go)
+	NoBatch -> withKeyOptions (keyOptions o) False
+		(commandAction . startKeys o)
+		(withFilesInGit (commandAction . go))
 		=<< workTreeItems (findThese o)
 	Batch fmt -> batchFilesMatching fmt go
   where
@@ -66,6 +72,11 @@ start o file key = ifM (limited <||> inAnnex key)
 	, stop
 	)
 
+startKeys :: FindOptions -> (Key, ActionItem) -> CommandStart
+startKeys o (key, ActionItemBranchFilePath (BranchFilePath _ topf)) = 
+	start o (getTopFilePath topf) key
+startKeys _ _ = stop
+
 showFormatted :: Maybe Utility.Format.Format -> String -> [(String, String)] -> Annex ()
 showFormatted format unformatted vars =
 	unlessM (showFullJSON $ JSONChunk vars) $
diff --git a/Command/FindRef.hs b/Command/FindRef.hs
index 42ffbad87..f09ed4b9e 100644
--- a/Command/FindRef.hs
+++ b/Command/FindRef.hs
@@ -1,6 +1,6 @@
 {- git-annex command
  -
- - Copyright 2014 Joey Hess <id@joeyh.name>
+ - Copyright 2014-2018 Joey Hess <id@joeyh.name>
  -
  - Licensed under the GNU GPL version 3 or higher.
  -}
@@ -14,9 +14,14 @@ import qualified Git
 cmd :: Command
 cmd = withGlobalOptions [annexedMatchingOptions] $ Find.mkCommand $ 
 	command "findref" SectionPlumbing
-		"lists files in a git ref"
+		"lists files in a git ref (deprecated)"
 		paramRef (seek <$$> Find.optParser)
 
 seek :: Find.FindOptions -> CommandSeek
-seek o = (commandAction . uncurry (Find.start o))
-	`withFilesInRefs` (map Git.Ref $ Find.findThese o)
+seek o = Find.seek o'
+  where
+	o' = o 
+		{ Find.keyOptions = Just $ WantBranchKeys $
+			map Git.Ref (Find.findThese o)
+		, Find.findThese = []
+		}
diff --git a/doc/git-annex-find.mdwn b/doc/git-annex-find.mdwn
index 6e5a31975..cbd59b5ad 100644
--- a/doc/git-annex-find.mdwn
+++ b/doc/git-annex-find.mdwn
@@ -26,6 +26,10 @@ finds files in the current directory and its subdirectories.
 
   To list annexed files whose content is not present, specify `--not --in=here`
 
+* `--branch=ref`
+
+  List files in the specified branch or treeish.
+
 * `--print0`
 
   Output filenames terminated with nulls, for use with `xargs -0`
diff --git a/doc/git-annex-findref.mdwn b/doc/git-annex-findref.mdwn
index ce07e0ee4..6406e404b 100644
--- a/doc/git-annex-findref.mdwn
+++ b/doc/git-annex-findref.mdwn
@@ -1,6 +1,6 @@
 # NAME
 
-git-annex findref - lists files in a git ref
+git-annex findref - lists files in a git ref (deprecated)
 
 # SYNOPSIS
 
@@ -8,9 +8,9 @@ git annex findref `[ref]`
 
 # DESCRIPTION
 
-This is very similar to the `git-annex find` command, but instead of
-finding files in the current work tree, it finds files in the
-specified git ref.
+This is the same as `git annex find` with the --branch option, and you're
+encouraged to use that instead unless you need to support older versions of
+git-annex.
 
 # OPTIONS
 

(Diff truncated)

diff --git a/Annex/FileMatcher.hs b/Annex/FileMatcher.hs
index 44565e321..330539abb 100644
--- a/Annex/FileMatcher.hs
+++ b/Annex/FileMatcher.hs
@@ -60,7 +60,7 @@ checkMatcher matcher mkey afile notpresent notconfigured d
 	| isEmpty matcher = notconfigured
 	| otherwise = case (mkey, afile) of
 		(_, AssociatedFile (Just file)) -> go =<< fileMatchInfo file
-		(Just key, _) -> go (MatchingKey key)
+		(Just key, _) -> go (MatchingKey key afile)
 		_ -> d
   where
 	go mi = matchMrun matcher $ \a -> a notpresent mi
diff --git a/CHANGELOG b/CHANGELOG
index bd8f1cb59..96ede489f 100644
--- a/CHANGELOG
+++ b/CHANGELOG
@@ -2,6 +2,12 @@ git-annex (7.20181206) UNRELEASED; urgency=medium
 
   * S3: Improve diagnostics when a remote is configured with exporttree and
     versioning, but no S3 version id has been recorded for a key.
+  * findref: Support file matching options: --include, --exclude,
+    --want-get, --want-drop, --largerthan, --smallerthan, --accessedwithin
+  * Commands supporting --branch now apply file matching options --include,
+    --exclude, --want-get, --want-drop to filenames from the branch.
+    Previously, combining --branch with those would fail to match anything.
+  * add, import, findref: Support --time-limit.
 
  -- Joey Hess <id@joeyh.name>  Thu, 06 Dec 2018 13:39:16 -0400
 
diff --git a/CmdLine/GitAnnex/Options.hs b/CmdLine/GitAnnex/Options.hs
index c94350d71..253574bf6 100644
--- a/CmdLine/GitAnnex/Options.hs
+++ b/CmdLine/GitAnnex/Options.hs
@@ -211,18 +211,18 @@ parseKey = maybe (fail "invalid key") return . file2key
 -- Options to match properties of annexed files.
 annexedMatchingOptions :: [GlobalOption]
 annexedMatchingOptions = concat
-	[ nonWorkTreeMatchingOptions'
+	[ keyMatchingOptions'
 	, fileMatchingOptions'
 	, combiningOptions
 	, timeLimitOption
 	]
 
--- Matching options that don't need to examine work tree files.
-nonWorkTreeMatchingOptions :: [GlobalOption]
-nonWorkTreeMatchingOptions = nonWorkTreeMatchingOptions' ++ combiningOptions
+-- Matching options that can operate on keys as well as files.
+keyMatchingOptions :: [GlobalOption]
+keyMatchingOptions = keyMatchingOptions' ++ combiningOptions ++ timeLimitOption
 
-nonWorkTreeMatchingOptions' :: [GlobalOption]
-nonWorkTreeMatchingOptions' = 
+keyMatchingOptions' :: [GlobalOption]
+keyMatchingOptions' = 
 	[ globalSetter Limit.addIn $ strOption
 		( long "in" <> short 'i' <> metavar paramRemote
 		<> help "match files present in a remote"
@@ -285,7 +285,7 @@ nonWorkTreeMatchingOptions' =
 
 -- Options to match files which may not yet be annexed.
 fileMatchingOptions :: [GlobalOption]
-fileMatchingOptions = fileMatchingOptions' ++ combiningOptions
+fileMatchingOptions = fileMatchingOptions' ++ combiningOptions ++ timeLimitOption
 
 fileMatchingOptions' :: [GlobalOption]
 fileMatchingOptions' =
diff --git a/CmdLine/Seek.hs b/CmdLine/Seek.hs
index 47a52176c..8b65532dc 100644
--- a/CmdLine/Seek.hs
+++ b/CmdLine/Seek.hs
@@ -24,6 +24,7 @@ import qualified Limit
 import CmdLine.GitAnnex.Options
 import Logs.Location
 import Logs.Unused
+import Types.ActionItem
 import Types.Transfer
 import Logs.Transfer
 import Remote.List
@@ -84,12 +85,14 @@ withFilesInRefs a = mapM_ go
 	go r = do	
 		matcher <- Limit.getMatcher
 		(l, cleanup) <- inRepo $ LsTree.lsTree r
-		forM_ l $ \i -> do
-			let f = getTopFilePath $ LsTree.file i
-			catKey (LsTree.sha i) >>= \case
+		forM_ l $ \ti -> do
+			let f = getTopFilePath $ LsTree.file ti
+			catKey (LsTree.sha ti) >>= \case
 				Nothing -> noop
-				Just k -> whenM (matcher $ MatchingKey k) $
-					a (f, k)
+				Just k -> 
+					let i = MatchingKey k (AssociatedFile (Just f))
+					in whenM (matcher i) $
+						a (f, k)
 		liftIO $ void cleanup
 
 withPathContents :: ((FilePath, FilePath) -> CommandSeek) -> CmdParams -> CommandSeek
@@ -197,8 +200,12 @@ withKeyOptions ko auto keyaction = withKeyOptions' ko auto mkkeyaction
   where
 	mkkeyaction = do
 		matcher <- Limit.getMatcher
-		return $ \v ->
-			whenM (matcher $ MatchingKey $ fst v) $
+		return $ \v@(k, ai) ->
+			let i = case ai of
+				ActionItemBranchFilePath (BranchFilePath _ topf) ->
+					MatchingKey k (AssociatedFile $ Just $ getTopFilePath topf)
+				_ -> MatchingKey k (AssociatedFile Nothing)
+			in whenM (matcher i) $
 				keyaction v
 
 withKeyOptions' 
diff --git a/Command/FindRef.hs b/Command/FindRef.hs
index b829a070f..42ffbad87 100644
--- a/Command/FindRef.hs
+++ b/Command/FindRef.hs
@@ -12,7 +12,7 @@ import qualified Command.Find as Find
 import qualified Git
 
 cmd :: Command
-cmd = withGlobalOptions [nonWorkTreeMatchingOptions] $ Find.mkCommand $ 
+cmd = withGlobalOptions [annexedMatchingOptions] $ Find.mkCommand $ 
 	command "findref" SectionPlumbing
 		"lists files in a git ref"
 		paramRef (seek <$$> Find.optParser)
diff --git a/Limit.hs b/Limit.hs
index 93b32a89f..777eda0fb 100644
--- a/Limit.hs
+++ b/Limit.hs
@@ -94,16 +94,17 @@ matchGlobFile :: String -> MatchInfo -> Annex Bool
 matchGlobFile glob = go
   where
 	cglob = compileGlob glob CaseSensative -- memoized
-	go (MatchingKey _) = pure False
 	go (MatchingFile fi) = pure $ matchGlob cglob (matchFile fi)
 	go (MatchingInfo af _ _ _) = matchGlob cglob <$> getInfo af
+	go (MatchingKey _ (AssociatedFile Nothing)) = pure False
+	go (MatchingKey _ (AssociatedFile (Just af))) = pure $ matchGlob cglob af
 
 #ifdef WITH_MAGICMIME
 matchMagic :: Maybe Magic -> MkLimit Annex
 matchMagic (Just magic) glob = Right $ const go
   where
  	cglob = compileGlob glob CaseSensative -- memoized
-	go (MatchingKey _) = pure False
+	go (MatchingKey _ _) = pure False
 	go (MatchingFile fi) = liftIO $ catchBoolIO $
 		matchGlob cglob <$> magicFile magic (currFile fi)
 	go (MatchingInfo _ _ _ mimeval) = matchGlob cglob <$> getInfo mimeval
@@ -152,7 +153,8 @@ limitInDir :: FilePath -> MatchFiles Annex
 limitInDir dir = const go
   where
 	go (MatchingFile fi) = checkf $ matchFile fi
-	go (MatchingKey _) = return False
+	go (MatchingKey _ (AssociatedFile Nothing)) = return False
+	go (MatchingKey _ (AssociatedFile (Just af))) = checkf af
 	go (MatchingInfo af _ _ _) = checkf =<< getInfo af
 	checkf = return . elem dir . splitPath . takeDirectory
 
@@ -200,7 +202,7 @@ limitLackingCopies approx want = case readish want of
 			then approxNumCopies
 			else case mi of
 				MatchingFile fi -> getGlobalFileNumCopies $ matchFile fi
-				MatchingKey _ -> approxNumCopies
+				MatchingKey _ _ -> approxNumCopies
 				MatchingInfo _ _ _ _ -> approxNumCopies
 		us <- filter (`S.notMember` notpresent)
 			<$> (trustExclude UnTrusted =<< Remote.keyLocations key)
@@ -214,7 +216,7 @@ limitLackingCopies approx want = case readish want of
  -}
 limitUnused :: MatchFiles Annex
 limitUnused _ (MatchingFile _) = return False
-limitUnused _ (MatchingKey k) = S.member k <$> unusedKeys
+limitUnused _ (MatchingKey k _) = S.member k <$> unusedKeys
 limitUnused _ (MatchingInfo _ ak _ _) = do
 	k <- getInfo ak
 	S.member k <$> unusedKeys
@@ -277,7 +279,7 @@ limitSize vs s = case readSize dataUnits s of
 	Just sz -> Right $ go sz
   where
 	go sz _ (MatchingFile fi) = lookupFileKey fi >>= check fi sz
-	go sz _ (MatchingKey key) = checkkey sz key
+	go sz _ (MatchingKey key _) = checkkey sz key
 	go sz _ (MatchingInfo _ _ as _) =
 		getInfo as >>= \sz' -> return (Just sz' `vs` Just sz)
 	checkkey sz key = return $ keySize key `vs` Just sz
@@ -329,5 +331,5 @@ lookupFileKey = lookupFile . currFile
 
 checkKey :: (Key -> Annex Bool) -> MatchInfo -> Annex Bool
 checkKey a (MatchingFile fi) = lookupFileKey fi >>= maybe (return False) a
-checkKey a (MatchingKey k) = a k
+checkKey a (MatchingKey k _) = a k
 checkKey a (MatchingInfo _ ak _ _) = a =<< getInfo ak
diff --git a/Limit/Wanted.hs b/Limit/Wanted.hs
index a41398c10..281e34879 100644
--- a/Limit/Wanted.hs
+++ b/Limit/Wanted.hs

(Diff truncated)

diff --git a/doc/bugs/Importing__95__Commands__95__Destructive__95__by__95__default.mdwn b/doc/bugs/Importing__95__Commands__95__Destructive__95__by__95__default.mdwn
index 0fd8de1c5..d81e005f3 100644
--- a/doc/bugs/Importing__95__Commands__95__Destructive__95__by__95__default.mdwn
+++ b/doc/bugs/Importing__95__Commands__95__Destructive__95__by__95__default.mdwn
@@ -28,3 +28,6 @@ for me personally the ideal case would be a cp command for git annex that would
 in a cp style allowing to use options like `noclobber` and perhaps `reinject`
 
 it may be sensible to leave supporting this to the importtree feature
+
+> I think we've argued pretty well that the current behavior makes sense,
+> so [[done]] --[[Joey]]

diff --git a/doc/bugs/Old_dependencies_are_causing_pain_with_NixOS_18.09.mdwn b/doc/bugs/Old_dependencies_are_causing_pain_with_NixOS_18.09.mdwn
index 1a2aec569..0773f9976 100644
--- a/doc/bugs/Old_dependencies_are_causing_pain_with_NixOS_18.09.mdwn
+++ b/doc/bugs/Old_dependencies_are_causing_pain_with_NixOS_18.09.mdwn
@@ -4,3 +4,6 @@ More detail here: <https://github.com/NixOS/nixpkgs/issues/45686>
 
 ### What steps will reproduce the problem?
 Installing git-annex from the 18.09 nixpkgs release.
+
+> [[done]]; the esqueleto dep was dropped and deps are fairly current now.
+> --[[Joey]]

diff --git a/doc/forum/named_pipes_as_arguments/comment_1_0fff7a842609af3531d151425a94df0a._comment b/doc/forum/named_pipes_as_arguments/comment_1_0fff7a842609af3531d151425a94df0a._comment
new file mode 100644
index 000000000..2992745fc
--- /dev/null
+++ b/doc/forum/named_pipes_as_arguments/comment_1_0fff7a842609af3531d151425a94df0a._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2018-12-09T15:38:21Z"
+ content="""
+I doubt it?
+
+The two way filesnames are used with git-annex commands are
+
+1. The name of a file already checked in to the git repository,
+   here git-annex needs to stat the file so I doubt a named pipe would
+   work.
+2. A file not yet checked into git which is going to be added.
+   git-annex has to adjust permissions, move the file etc, as well as
+   reading its content so again a named pipe wouldn't work.
+"""]]

diff --git a/doc/forum/android_installation/comment_1_8908256ecd48d7b5207799aa02102d87._comment b/doc/forum/android_installation/comment_1_8908256ecd48d7b5207799aa02102d87._comment
new file mode 100644
index 000000000..2c1b95240
--- /dev/null
+++ b/doc/forum/android_installation/comment_1_8908256ecd48d7b5207799aa02102d87._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2018-12-09T15:25:24Z"
+ content="""
+The installer is running the command `uname -m` to find out what kind of
+processor your Android device has. It doesn't recognize "armv81"
+
+What you can try is to open the git-annex-install
+script in a text editor, and add a case under `uname -m` for
+"armv81". My guess is that this would work:
+
+	armv81) arch=arm64 ;;
+
+Or maybe this:
+
+	armv81) arch=arm ;;
+"""]]
diff --git a/doc/forum/conda-forge_build_problem/comment_1_22e01f5f110593796b539fc7630ccb3c._comment b/doc/forum/conda-forge_build_problem/comment_1_22e01f5f110593796b539fc7630ccb3c._comment
new file mode 100644
index 000000000..2887544a3
--- /dev/null
+++ b/doc/forum/conda-forge_build_problem/comment_1_22e01f5f110593796b539fc7630ccb3c._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2018-12-09T15:15:36Z"
+ content="""
+The way that stack works is the "resolver" value in stack.yaml
+points to a particular version of ghc and libraries that work with it.
+
+I don't think that stack allows overriding the version of ghc. What you can
+do is go to <http://stackage.org/> and find a snapshot that includes the
+ghc version you have available, and edit stack.yaml's "resolver" to use
+that. You may also need to pass --system-ghc to stack to make it use your
+installed ghc rather than trying to download it.
+
+Building with cabal, while more error prone, is another way to use whatever
+version of ghc you have installed already.
+"""]]
diff --git a/doc/forum/export_single_file/comment_3_0761201bf68e1086d263776eb953c1e1._comment b/doc/forum/export_single_file/comment_3_0761201bf68e1086d263776eb953c1e1._comment
new file mode 100644
index 000000000..5f9812f6e
--- /dev/null
+++ b/doc/forum/export_single_file/comment_3_0761201bf68e1086d263776eb953c1e1._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2018-12-09T15:22:09Z"
+ content="""
+`git annex export` only exports trees, but you can easily make a tree
+containing only a single file, and then export that. 
+
+For example:
+
+	mkdir exporttree
+	cp tests/tests1.mov exporttree
+	git annex add exporttree
+	git commit -m 'created export tree'
+	git annex export master:exporttree --to public
+
+If you don't want to commit that you can switch to a temporary branch
+and build the tree there. Or there are plenty of lower-level git commands
+to build trees.
+"""]]

diff --git a/doc/bugs/git_index_lock_/comment_1_84e1d17351619be933d7443c2045feec._comment b/doc/bugs/git_index_lock_/comment_1_84e1d17351619be933d7443c2045feec._comment
new file mode 100644
index 000000000..944858087
--- /dev/null
+++ b/doc/bugs/git_index_lock_/comment_1_84e1d17351619be933d7443c2045feec._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2018-12-09T15:05:20Z"
+ content="""
+This is the same as concurrent `git add` (with or without git-annex)
+failing due to git only allowing one writer to the index at a time.
+
+Since this is a fundamental limitation of git, I feel that git-annex should
+not try to work around it for things involving the worktree's index file,
+except for within the same command as it does for `git annex add -J`.
+
+`git annex fromkey` obviously does need to update the worktree's index
+file. I suggest you run it in --batch mode and serialize the changes to it
+that way.
+
+(git-annex does of course work around the problem for the git-annex branch's index
+file, but that's very different than the worktree index; it doesn't matter if
+one process stages and commits another process's git-annex branch changes).
+"""]]

diff --git a/doc/todo/add_tests_under_concurrency/comment_1_9879c63f9de342b6831d5794d8f6212e._comment b/doc/todo/add_tests_under_concurrency/comment_1_9879c63f9de342b6831d5794d8f6212e._comment
new file mode 100644
index 000000000..e332fda02
--- /dev/null
+++ b/doc/todo/add_tests_under_concurrency/comment_1_9879c63f9de342b6831d5794d8f6212e._comment
@@ -0,0 +1,24 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2018-12-09T14:47:59Z"
+ content="""
+As the test suite is constructed, there is a single origin repository
+shared by clones used for each test case, and there are test cases that do
+eg `git annex move --from origin ; git annex move --to origin` and so would break
+other tests cases using the same origin if they were run concurrently, without it
+being an actual concurrency bug in git-annex.
+
+So parallelizing the test suite would need each test case to have its own
+isolated set of test repos. But then concurrency bugs could not be found by
+the test suite; concurrency would only possibly make it run faster.
+
+Finding concurrency bugs seems to need the test repos to contain more
+files than the two or three they now do, so that a single test case can
+run some git-annex operation concurrently on several files at once.
+
+Also, if you look at the CHANGELOG, you'll find that concurrency bugs in
+git-annex beyond the UI level are fairly rare. And I can think of only one
+concurrency bug that ever caused even theoretical data loss; it involved 3
+repos in a triangle topology all dropping the same file at the same time.
+"""]]

diff --git a/doc/todo/assistant_should_detect_added_remotes/comment_2_2a282fcacad94b9590f5bc440ff6ea64._comment b/doc/todo/assistant_should_detect_added_remotes/comment_2_2a282fcacad94b9590f5bc440ff6ea64._comment
new file mode 100644
index 000000000..061a5f93f
--- /dev/null
+++ b/doc/todo/assistant_should_detect_added_remotes/comment_2_2a282fcacad94b9590f5bc440ff6ea64._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="andrew"
+ avatar="http://cdn.libravatar.org/avatar/acc0ece1eedf07dd9631e7d7d343c435"
+ subject="comment 2"
+ date="2018-12-08T17:09:27Z"
+ content="""
+Could the assistant put a file watch on `.git/config` to detect when new remotes are added/removed?
+
+I am pretty sure this user [assistant to have synced folders](http://git-annex.branchable.com/forum/assistant_to_have_synced_folders/) ran into this issue. They added two local remotes then hit the combine button, then looked for synced files. Assistant never started syncing, presumably for the reasons outlined in your comment. They did everything through the web gui so they really didn't have any expectation that they would need to manually restart all the assistant daemons after hitting the combine button.
+"""]]

diff --git a/doc/forum/assistant_to_have_synced_folders/comment_12_f38a88b82328ee2d2b411f3df5c3d043._comment b/doc/forum/assistant_to_have_synced_folders/comment_12_f38a88b82328ee2d2b411f3df5c3d043._comment
new file mode 100644
index 000000000..6c07f21d3
--- /dev/null
+++ b/doc/forum/assistant_to_have_synced_folders/comment_12_f38a88b82328ee2d2b411f3df5c3d043._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="andrew"
+ avatar="http://cdn.libravatar.org/avatar/acc0ece1eedf07dd9631e7d7d343c435"
+ subject="comment 12"
+ date="2018-12-08T16:56:11Z"
+ content="""
+Looking through your video, I think I have found at least one issue with the assistant. I logged in a todo here: <http://git-annex.branchable.com/todo/assistant_should_detect_added_remotes/>. It looks like assistant is not detecting your newly added remote (after hitting the combine button) which is why it wasn't syncing.
+"""]]

diff --git a/doc/todo/add_prefix_option_to_export/comment_7_5635d23fae7d9464605389b03af11565._comment b/doc/todo/add_prefix_option_to_export/comment_7_5635d23fae7d9464605389b03af11565._comment
new file mode 100644
index 000000000..1d77457df
--- /dev/null
+++ b/doc/todo/add_prefix_option_to_export/comment_7_5635d23fae7d9464605389b03af11565._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="andrew"
+ avatar="http://cdn.libravatar.org/avatar/acc0ece1eedf07dd9631e7d7d343c435"
+ subject="comment 7"
+ date="2018-12-08T16:46:34Z"
+ content="""
+Perfect thanks. Yes fine to mark as done.
+
+Thank you for adding additional information about exporttree to `git annex info remote` that will prove useful if I do go done that route at a future date.
+
+Yes, I do plan to lookup public URLs with `git annex whereis --json`.
+"""]]

diff --git a/doc/forum/How_to_remove_annex_on_osx__63__/comment_1_18fc46bdb5bc44916e355a9900e9c0d1._comment b/doc/forum/How_to_remove_annex_on_osx__63__/comment_1_18fc46bdb5bc44916e355a9900e9c0d1._comment
new file mode 100644
index 000000000..2f26998c4
--- /dev/null
+++ b/doc/forum/How_to_remove_annex_on_osx__63__/comment_1_18fc46bdb5bc44916e355a9900e9c0d1._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="andrew"
+ avatar="http://cdn.libravatar.org/avatar/acc0ece1eedf07dd9631e7d7d343c435"
+ subject="comment 1"
+ date="2018-12-08T16:43:07Z"
+ content="""
+`git-annex` for mac comes with a bundled version of git usually located at `/Applications/git-annex.app/Contents/MacOS/git`.  It looks like some application you are using found that location of git and decided to use it. When you deleted the git-annex.app directory your app could no longer find git there. **Are you getting this error message from the Github Desktop app?**
+
+Most likely you just need to install a standalone version of git (if you have never done that) from <https://git-scm.com/> or Homebrew if you are into that, or if you use Github Desktop just go to `Github Desktop > Install Command Line Tool…`. You could also check to make sure you don't have some hardcoded alias for git setup in `~/.bash_profile`, but that seems unlikely.
+"""]]

diff --git a/doc/todo/add_tests_under_concurrency.mdwn b/doc/todo/add_tests_under_concurrency.mdwn
new file mode 100644
index 000000000..6421d3f3a
--- /dev/null
+++ b/doc/todo/add_tests_under_concurrency.mdwn
@@ -0,0 +1 @@
+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.

diff --git a/doc/bugs/git_index_lock_.mdwn b/doc/bugs/git_index_lock_.mdwn
new file mode 100644
index 000000000..5ebe3cd6f
--- /dev/null
+++ b/doc/bugs/git_index_lock_.mdwn
@@ -0,0 +1,52 @@
+### Please describe the problem.
+Concurrent operations fail due to .git/index.lock being held.
+
+### What steps will reproduce the problem?
+git annex fromkey , under high concurrency .   Maybe more retries could be added, before failing?
+
+### What version of git-annex are you using? On what operating system?
+(master_env_py27_v28) [11:57 AM /data/ilya-work]$ git annex version
+git-annex version: 7.20181031-g43f0718
+build flags: Assistant Webapp Pairing S3(multipartupload)(storageclasses) WebDAV Inotify TorrentParser MagicMime Feeds Testsuite
+dependency versions: aws-0.17.1 bloomfilter-2.0.1.0 cryptonite-0.23 DAV-1.3.1 feed-0.3.12.0 ghc-8.0.2 http-client-0.5.7.0 persistent-s\
+qlite-2.6.2 torrent-10000.1.1 uuid-1.3.13 yesod-1.4.5
+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 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 hook external
+operating system: linux x86_64
+supported repository versions: 5 7
+upgrade supported from repository versions: 0 1 2 3 4 5 6
+local repository version: 5
+(master_env_py27_v28) [12:00 PM /data/ilya-work]$ uname -a
+Linux ip-172-31-80-119 4.14.77-70.82.amzn1.x86_64 #1 SMP Mon Dec 3 20:01:27 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
+(master_env_py27_v28) [12:00 PM /data/ilya-work]$
+-
+
+### 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
+
+2018-12-06 01:22:20,410 - workflow_utils:183:_run - INFO - running command: git annex fromkey --force MD5E-s19330--3541df84bcd805aa205\
+f9ffdca6cc21a.fasta pipelines/dxfailed/analysis-FKPG5480Z3yz3yG21G7F47z1/files/originalInput/stage-4.reference_genome_fasta/0/ref-ebov\
+-makona_C15.fasta cwd=/data/ilya-work
+fatal: Unable to create '/data/ilya-work/.git/index.lock': File exists.
+
+Another git process seems to be running in this repository, e.g.
+an editor opened by 'git commit'. Please make sure all processes
+are terminated then try again. If it still fails, a git process
+may have crashed in this repository earlier:
+remove the file manually to continue.
+git-annex: user error (xargs ["-0","git","--git-dir=.git","--work-tree=.","--literal-pathspecs","add","--"] exited 123)
+T
+
+
+# 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)
+
+It's become an indispensable tool.   E.g. I just used it to moved data from more-expensive to less-expensive storage, without needing to worry about getting it back when needed; this frees up not just disk space but mental space :)

diff --git a/doc/users/yarikoptic.mdwn b/doc/users/yarikoptic.mdwn
new file mode 100644
index 000000000..6a2e7dfb7
--- /dev/null
+++ b/doc/users/yarikoptic.mdwn
@@ -0,0 +1,11 @@
+Hi,
+
+I am Yaroslav Olegovich Halchenko, or just Yarik.  I also got my first MS degree in Laser and Optoelectronic Engineering, and that is how I became `yarikoptic`.
+
+Through the past two decades I have been pursuing a variety of problems in neuroimaging and neuroinformatics, to solve many of which we have provide many solutions to our scientific community (e.g. [NeuroDebian](http://neuro.debian.net), [PyMVPA](http://pymvpa.org), etc). git-annex became the ideological and technological core for our [DataLad](http://datalad.org) project to provide a data distribution for existing data resources, and a versatile management platform for all digital objects of science (code, data, computational environments, etc).  DataLad development was funded by NSF (USA) and BMBF (Germany), which allowed us to support development and maintenance of the core piece of git-annex for over 4 years now.
+
+To discover more, visit
+
+- [Center for Open Neuroscience](http://centerforopenneuroscience.org)
+- [yarikoptic@GitHub](https://github.com/yarikoptic)
+- [yarikoptic@Twitter](http://twitter.com/yarikoptic)

diff --git a/doc/forum/conda-forge_build_problem.mdwn b/doc/forum/conda-forge_build_problem.mdwn
new file mode 100644
index 000000000..81d0451a0
--- /dev/null
+++ b/doc/forum/conda-forge_build_problem.mdwn
@@ -0,0 +1,10 @@
+Attempt to build the conda-forge recipe for the latest git-annex version fails like this:
+https://circleci.com/gh/conda-forge/git-annex-feedstock/124?utm_campaign=vcs-integration-link&utm_medium=referral&utm_source=github-build-link
++ stack --local-bin-path /home/conda/feedstock_root/build_artifacts/git-annex_1544129313702/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_p/bin --extra-include-dirs /home/conda/feedstock_root/build_artifacts/git-annex_1544129313702/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_p/include --extra-lib-dirs /home/conda/feedstock_root/build_artifacts/git-annex_1544129313702/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_p/lib --stack-root /home/conda/feedstock_root/build_artifacts/git-annex_1544129313702/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_p/share/git-annex-7.20181205-0/stackroot setup
+Downloading lts-12.19 build plan ...
+Downloaded lts-12.19 build plan.
+No setup information found for ghc-8.4.4 on your platform.
+This probably means a GHC bindist has not yet been added for OS key 'linux64-gmp4'.
+Supported versions: ghc-7.8.4, ghc-7.10.2, ghc-7.10.3, ghc-8.0.1, ghc-8.0.2, ghc-8.2.1, ghc-8.2.2, ghc-8.4.2
+
+Is there a way to specify that ghc-8.4.2 is ok (if it is ok)?

diff --git a/doc/forum/__39__put__39___functionality_as_opposed_to___39__get__39__/comment_1_b2b7de0bf4494721b02280857474fd6c._comment b/doc/forum/__39__put__39___functionality_as_opposed_to___39__get__39__/comment_1_b2b7de0bf4494721b02280857474fd6c._comment
new file mode 100644
index 000000000..5baab08c7
--- /dev/null
+++ b/doc/forum/__39__put__39___functionality_as_opposed_to___39__get__39__/comment_1_b2b7de0bf4494721b02280857474fd6c._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="hobbes@b2cacef69071743c3a831e60511062f7e014e52f"
+ nickname="hobbes"
+ avatar="http://cdn.libravatar.org/avatar/44b70169c4d862b3619812c360aa8f1e"
+ subject="comment 1"
+ date="2018-12-06T15:21:38Z"
+ content="""
+I think you're looking for `git-annex copy` ?
+"""]]

diff --git a/doc/forum/__39__put__39___functionality_as_opposed_to___39__get__39__.mdwn b/doc/forum/__39__put__39___functionality_as_opposed_to___39__get__39__.mdwn
new file mode 100644
index 000000000..a528cb83d
--- /dev/null
+++ b/doc/forum/__39__put__39___functionality_as_opposed_to___39__get__39__.mdwn
@@ -0,0 +1,14 @@
+The git annex documentation gives an example of using get:
+
+# git annex sync laptop
+# git annex get .
+get my_cool_big_file (from laptop...) ok
+get iso/debian.iso (from laptop...) ok
+https://git-annex.branchable.com/walkthrough/#index5h2
+
+Is there a way to do the opposite, i.e. once synchronised with the remote repo called "laptop", directly put the actual file content directly into the "laptop"'s annex storage? E.g.
+
+# git annex sync laptop
+# git annex put .
+put my_cool_big_file (to laptop...) ok
+put iso/debian.iso (to laptop...) ok

diff --git a/doc/bugs/dropunused_does_nothing/comment_7_d64a42b91dc46fd56320b4c328b75b7b._comment b/doc/bugs/dropunused_does_nothing/comment_7_d64a42b91dc46fd56320b4c328b75b7b._comment
new file mode 100644
index 000000000..7d5af2f18
--- /dev/null
+++ b/doc/bugs/dropunused_does_nothing/comment_7_d64a42b91dc46fd56320b4c328b75b7b._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="xsteadfastx"
+ avatar="http://cdn.libravatar.org/avatar/a07e2adf7ff40bdd4c3fe20ededc0a4e"
+ subject="comment 7"
+ date="2018-12-06T09:09:48Z"
+ content="""
+thank you so much for your fix and overall awesome work!!!
+"""]]

diff --git a/doc/forum/How_to_remove_annex_on_osx__63__.mdwn b/doc/forum/How_to_remove_annex_on_osx__63__.mdwn
new file mode 100644
index 000000000..b142e3f21
--- /dev/null
+++ b/doc/forum/How_to_remove_annex_on_osx__63__.mdwn
@@ -0,0 +1,5 @@
+I tried to remove git annex and it seems to have completely broken my git. Anytime I try to clone it says:
+
+-bash: /Applications/git-annex.app/Contents/MacOS/git: No such file or directory
+
+How do I fix?

diff --git a/doc/bugs/upgrade_to_version_7_not_going_well__44___bup_remote_missing_its_uuid/comment_2_1f876aeaf770e6933f03de60c471eb8c._comment b/doc/bugs/upgrade_to_version_7_not_going_well__44___bup_remote_missing_its_uuid/comment_2_1f876aeaf770e6933f03de60c471eb8c._comment
new file mode 100644
index 000000000..2f23776b1
--- /dev/null
+++ b/doc/bugs/upgrade_to_version_7_not_going_well__44___bup_remote_missing_its_uuid/comment_2_1f876aeaf770e6933f03de60c471eb8c._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="StéphaneGL"
+ avatar="http://cdn.libravatar.org/avatar/a12e6e0852d5a1985b8684b17202561c"
+ subject="comment 2"
+ date="2018-12-05T22:58:57Z"
+ content="""
+Thanks for the prompt reply! Yes, you're right, it's the config file in the bup repo that was corrupted, for some reason. I hadn't thought running git-annex in the other repo would get the bup UUID from the bup's config file and not the local one. All works like a charm! Thanks again!
+"""]]

diff --git a/doc/news/version_7.20181205.mdwn b/doc/news/version_7.20181205.mdwn
new file mode 100644
index 000000000..1cc1648aa
--- /dev/null
+++ b/doc/news/version_7.20181205.mdwn
@@ -0,0 +1,19 @@
+git-annex 7.20181205 released with [[!toggle text="these changes"]]
+[[!toggleable text="""
+   * Make bittorrent special remote work w/o btshowmetainfo installed
+     when it was build with torrentparser.
+     Thanks, Robert Schütz
+   * When running youtube-dl to get a filename, pass --no-playlist.
+   * Fix build without concurrent-output.
+   * init: When a crippled filesystem causes an adjusted unlocked branch to
+     be used, set repo version to 7, which it neglected to do before.
+   * init: When on a crippled filesystem, and the git version is too old
+     to use an adjusted unlocked branch, fall back to using direct mode.
+   * info: When used with an exporttree remote, includes an "exportedtree"
+     info, which is the tree last exported to the remote. During an export
+     conflict, multiple values will be listed.
+   * dropunused: When an unused object file has gotten modified, eg due to
+     annex.thin being set, don't silently skip it, but display a warning
+     and let --force drop it.
+   * annex.cachecreds: New config to allow disabling of credentials caching
+     for special remotes."""]]
\ No newline at end of file

diff --git a/doc/forum/android_installation.mdwn b/doc/forum/android_installation.mdwn
new file mode 100644
index 000000000..448478e84
--- /dev/null
+++ b/doc/forum/android_installation.mdwn
@@ -0,0 +1,7 @@
+I tried to install using termux (from F-Droid).
+
+On running source git-annex-install i get
+ unknown architecture armv81, cannot install
+
+actually, I have no idea whats going on.
+

diff --git a/doc/todo/dockerized_external_special_remotes/comment_2_61a23adb5b871b178d3fb5a51602cf46._comment b/doc/todo/dockerized_external_special_remotes/comment_2_61a23adb5b871b178d3fb5a51602cf46._comment
new file mode 100644
index 000000000..07c942765
--- /dev/null
+++ b/doc/todo/dockerized_external_special_remotes/comment_2_61a23adb5b871b178d3fb5a51602cf46._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2018-12-05T16:24:17Z"
+ content="""
+Couldn't the docker image come with its own copy of git-annex?
+Not super space efficient, but it ensures that the special remote has
+access to a version of git-annex with the features it needs.
+"""]]
diff --git a/doc/todo/dockerized_external_special_remotes/comment_3_a044848ea54aebc2196376f9a59ccc70._comment b/doc/todo/dockerized_external_special_remotes/comment_3_a044848ea54aebc2196376f9a59ccc70._comment
new file mode 100644
index 000000000..914b27aa4
--- /dev/null
+++ b/doc/todo/dockerized_external_special_remotes/comment_3_a044848ea54aebc2196376f9a59ccc70._comment
@@ -0,0 +1,24 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2018-12-05T16:27:47Z"
+ content="""
+I think this could be a good idea, although I would not want to be forced
+to use docker as the only way to install an external special remote either.
+
+It seems that the minimum needed is a way to add a shell script to
+PATH with the name of the external special remote program, so git-annex can
+run it as usual. Or git-annex could invoke `docker run` itself, but I like
+having a shell script because it means git-annex doesn't need to know about
+docker and other containerization technologies.
+
+OTOH, I can see it would be nice if `git annex enableremote` could somehow
+get everything set up to use docker, and `git annex init` could fully set
+up autoenable=true special remotes.
+
+A balance could be for `git annex enableremote` to set up the shell script,
+perhaps in `.git/annex/externals/`. Store a few values like which docker
+image to use in the remote config, and generate the shell script from that.
+Then when a user needs to pass extra parameters to docker, or if they want
+to use rkt etc, they can just edit the shell script.
+"""]]

diff --git a/doc/upgrades.mdwn b/doc/upgrades.mdwn
index 54eecbaea..c5ef00207 100644
--- a/doc/upgrades.mdwn
+++ b/doc/upgrades.mdwn
@@ -44,10 +44,6 @@ The upgrade process needs to write to the repository. If the original
 repository cannot be written to (due to eg being on readonly media),
 the upgrade would need to be run in a copy of the repository.
 
-Some upgrades (most notably v6 and v7) require that all users of the
-repository upgrade simultaneously, otherwise files may become unreadable
-or unfetchable.
-
 The upgrade events, so far:
 
 ## v6 -> v7 (git-annex version 7.x)
@@ -59,14 +55,16 @@ Run `git-annex upgrade` to perform the upgrade.
 v6 repositories are automatically upgraded to v7.
 
 The only difference between v6 and v7 is that some additional git hooks
-were added in v7.
+were added in v7. See below for details about what's new in v6/v7.
 
 ## v5 -> v6 (git-annex version 6.x)
 
 A v6 git-annex repository can have some files locked while other files are
 unlocked, and all git and git-annex commands can be used on both locked and
-unlocked files. (Although for locked files to be accessible, the filesystem
-must support symbolic links.)
+unlocked files. It's a good idea to make sure that all users of the
+repository have upgraded git-annex and upgraded their repositories
+to the new version before starting to use this feature, since old
+versions of git-annex will ignore the new unlocked files.
 
 Direct mode repositories are upgraded to instead use the new 
 [[adjusted branches feature|git-annex-adjust]], which transparently unlocks
@@ -81,11 +79,9 @@ The behavior of some commands changes in an upgraded repository:
    	`git config annex.largefiles "largerthan=100kb and not (include=*.c or include=*.h)"`
 
 * `git annex unlock` and `git annex lock` change how the pointer to 
-  the annexed content is stored in git.
-
-If you commit the unlocked files change, this will impact all clones of the
-repository. This means all clones of the repository will need to run at least
-v6 to correctly synchronise.
+  the annexed content is stored in git. If you commit the change,
+  that will impact all clones of the repository. This means all clones of the
+  repository will need to run at least v6 to correctly synchronise.
 
 There is also a new `annex.thin` setting, which makes unlocked files in v6
 repositories be hard linked to their content, instead of a copy. This saves

diff --git a/doc/bugs/dropunused_does_nothing.mdwn b/doc/bugs/dropunused_does_nothing.mdwn
index c67e741ea..3e6f359da 100644
--- a/doc/bugs/dropunused_does_nothing.mdwn
+++ b/doc/bugs/dropunused_does_nothing.mdwn
@@ -128,3 +128,5 @@ i have recorded a asciinema: https://asciinema.org/a/O8ZjZp2TVO3mnuB4ZtmJxgceC
 ### 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)
 
 yeah. i try to use git-annex for just everything. lately im building a little script of using git-annex to save content from my blog. i love it alot :)
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/bugs/dropunused_does_nothing/comment_6_f2d5208352384443e027c78a64b1a0b1._comment b/doc/bugs/dropunused_does_nothing/comment_6_f2d5208352384443e027c78a64b1a0b1._comment
new file mode 100644
index 000000000..7f2ebd6bd
--- /dev/null
+++ b/doc/bugs/dropunused_does_nothing/comment_6_f2d5208352384443e027c78a64b1a0b1._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 6"""
+ date="2018-12-05T16:14:16Z"
+ content="""
+Thanks, what you describe matches the bug I've fixed.
+"""]]

diff --git a/doc/todo/borg_special_remote/comment_4_75611482f67e5d52f50d52fdb8c68e8b._comment b/doc/todo/borg_special_remote/comment_4_75611482f67e5d52f50d52fdb8c68e8b._comment
new file mode 100644
index 000000000..96f9b8ddd
--- /dev/null
+++ b/doc/todo/borg_special_remote/comment_4_75611482f67e5d52f50d52fdb8c68e8b._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="michael@ff03af62c7fd492c75066bda2fbf02370f5431f4"
+ nickname="michael"
+ avatar="http://cdn.libravatar.org/avatar/125bdfa8a2b91432c072615364bc3fa1"
+ subject="Borg vs. restic, some design considerations"
+ date="2018-12-05T14:36:45Z"
+ content="""
+As I have been looking for a new, de-duplicating, reliable backup system I read through the design documentations of [borg](https://borgbackup.readthedocs.io/en/stable/internals/data-structures.html#archives) and [restic](https://restic.readthedocs.io/en/latest/100_references.html#design). While the design of restic seems to be much simpler and actually quite straightforward, I decided for borg in the end due to its support for compression and the more efficient removal of single backups. Further, it [seems](https://blog.stickleback.dk/borg-or-restic/) the RAM usage is lower for borg.
+
+Here are some comments on both concerning the usability as git annex storage backend. Note that they are all based on my understanding of the design documents that describe how the data is stored in restic and borg. It is well possible that I have misunderstood something or some parts are just impossible due to implementation details. Further, I am quite sure that what I propose is not possible with the current external APIs of git annex and borg.
+
+For none of them, it seems to be a good idea to store individual archives (borg) or snapshots (restic) per file as both of them assume that the list of archives/snapshots is reasonably small, can be presented to the user as a single list and can be pruned based on certain rules about how many to keep per timespan (though that is per group of archives/snapshots). borg stores descriptions of all archives in a single item, the manifest (which means that when an archive is added, the whole list needs to be rewritten), restic stores each archive as a json document in a directory which might scale better but is probably still not a good idea. I think instead of storing individual files, git annex should store the whole set of exported files in a single archive/snapshot, i.e., store some kind of (virtual) directory structure in borg or restic that represents all items that shall be stored. Then, whenever git annex syncs with the borg/restic remote, a new archive/snapshot would be added. The user could then use the time-based pruning rules to remove old snapshots. This would also integrate well with using the same borg/restic repository for other backups, too. It might seem this would make the retrieval of a single file quite inefficient. Both borg and restic split a file into a list of chunks and store information where these chunks can be found. Therefore, it should be possible for a borg/restic special remote to just store this list of chunks for every annexed file. Then, to get a file, git annex would only need to ask for these chunks if it wants to get a single file. For restoring a lot of files, in particular with a non-local restic repository, this might be very inefficient though as restic might need to download a lot of data just to get these chunks - there just getting the whole last archive/snapshot might be more efficient (as far as I understood, then restic downloads each pack of chunks only once and directly writes all of them to the files that want them). Restic stores separate objects for every directory and this directory contains a list of subdirectories and files, where files contain a list of chunks. To add or remove files from a snapshot in restic, git annex would just need to execute the chunker for files not already present in the previous snapshot and could use the already stored chunk ids for the already present files. However, each snapshot would create a completely new directory. Without subdirectories, this would basically mean that the list of all files needs to be re-written for every snapshot. Subdirectories would help with that, but only if few subdirectories are modified. Due to the nature of hashing, this seems unlikely in the case of a git annex special remote (but of course this makes backups of unchanged directories very efficient). Borg doesn't have this directory  structure but instead just stores the metadata of every file in one large stream. This stream is chunked in parts consisting of around 128KiB and therefore, only parts where changes occurred need to be stored again. The list of these metadata chunks needs to be stored, nevertheless, but is much smaller. Again, everything that is needed for storing a file could be generated without having the actual source file if the chunk ids are present. In fact, this is what borg does with a file cache that stores for every file of the previous backup both properties like size, timestamp and inode id to identify modifications and a list of chunks. If borg finds the same file again, it just uses the stored chunk list. If the git annex borg special remote could also keep the order of all previously present files the same, this would result in re-using basically all metadata chunks - however, I don't know if borg assumes any order on the files. Note that borg needs to know which chunks are referenced in an archive as borg stores reference counts for all chunks to determine if a chunk is still needed, so just re-using the metadata chunks without reading their content is definitely not possible. Restic has no such reference counts, it needs to iterate over all trees to determine if a chunk can be deleted (which [seems](https://blog.stickleback.dk/borg-or-restic/) to be terribly slow). Nevertheless, both implementations of cleaning up chunks require that chunks are referenced in some file that is contained in some archive/snapshot.
+"""]]

diff --git a/doc/bugs/dropunused_does_nothing/comment_5_da289a4648ed1a976572cea3352ce15e._comment b/doc/bugs/dropunused_does_nothing/comment_5_da289a4648ed1a976572cea3352ce15e._comment
new file mode 100644
index 000000000..1dd3124c9
--- /dev/null
+++ b/doc/bugs/dropunused_does_nothing/comment_5_da289a4648ed1a976572cea3352ce15e._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="xsteadfastx"
+ avatar="http://cdn.libravatar.org/avatar/a07e2adf7ff40bdd4c3fe20ededc0a4e"
+ subject="comment 5"
+ date="2018-12-05T09:57:36Z"
+ content="""
+yes i have it set to thin. i forgot to tell. i edited the jpegs listed there and saved them under the same filename. that would explain why the checksums differ. but i thought a `git annex add .` would get it right. so this could be the bug you talk about?
+"""]]

diff --git a/doc/forum/why_are_all_those_files_modified/comment_3_b5deb8580c5874c50b85fd1c29ed30b3._comment b/doc/forum/why_are_all_those_files_modified/comment_3_b5deb8580c5874c50b85fd1c29ed30b3._comment
new file mode 100644
index 000000000..db0b61517
--- /dev/null
+++ b/doc/forum/why_are_all_those_files_modified/comment_3_b5deb8580c5874c50b85fd1c29ed30b3._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="anarcat"
+ avatar="http://cdn.libravatar.org/avatar/4ad594c1e13211c1ad9edb81ce5110b7"
+ subject="happened again"
+ date="2018-12-04T22:08:36Z"
+ content="""
+I just did a `git annex upgrade` with (again) 6.20180913-1~bpo9+1 and I am again seeing all files as modified (but diff is empty). No other command was running on the repository that I know of.
+"""]]

diff --git a/doc/forum/why_are_all_those_files_modified/comment_2_0774937b43a9bc592f2c1160a0155b49._comment b/doc/forum/why_are_all_those_files_modified/comment_2_0774937b43a9bc592f2c1160a0155b49._comment
new file mode 100644
index 000000000..9e8ec3a09
--- /dev/null
+++ b/doc/forum/why_are_all_those_files_modified/comment_2_0774937b43a9bc592f2c1160a0155b49._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="anarcat"
+ avatar="http://cdn.libravatar.org/avatar/4ad594c1e13211c1ad9edb81ce5110b7"
+ subject="comment 2"
+ date="2018-12-04T21:37:54Z"
+ content="""
+> If the file is locked, git-annex get has to modify it when it populates it.
+> 
+> git-annex is supposed to restage the file in order to update git's index. In a few cases where the index file is locked by something else, it is unable to do so and displays a warning, so perhaps that's what happened here.
+
+Hmm... I *think* I ran `git annex unlock` on `curie` here, so all files should be unlocked. I don't know what else could be locking the index file and didn't see a warning about it. I've seen a similar situation when upgrading other repositories in the past as well... 
+"""]]

diff --git a/doc/forum/why_are_all_those_files_modified/comment_1_2a504fe76dc1715fc8989eeee603c8ab._comment b/doc/forum/why_are_all_those_files_modified/comment_1_2a504fe76dc1715fc8989eeee603c8ab._comment
new file mode 100644
index 000000000..ccb11e5d1
--- /dev/null
+++ b/doc/forum/why_are_all_those_files_modified/comment_1_2a504fe76dc1715fc8989eeee603c8ab._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2018-12-04T21:27:30Z"
+ content="""
+If the file is locked, git-annex get has to modify it when it populates it.
+
+git-annex is supposed to restage the file in order to update git's index.
+In a few cases where the index file is locked by something else, it is 
+unable to do so and displays a warning, so perhaps that's what happened here.
+"""]]

diff --git a/doc/forum/why_are_all_those_files_modified.mdwn b/doc/forum/why_are_all_those_files_modified.mdwn
new file mode 100644
index 000000000..c0a455188
--- /dev/null
+++ b/doc/forum/why_are_all_those_files_modified.mdwn
@@ -0,0 +1,20 @@
+Following up on [[todo/clarify_that_v7_applies_to_all_clones]], the
+next step was to fetch all content from the central, still v5
+repository, which worked fine.
+
+But weirdly, some files showed up as modified:
+
+    $ git annex get
+    [...]
+    $ git status
+    ## master...origin/master
+     M calendrier/photos/DSCF0879.jpg
+     M calendrier/photos/DSCF1191.jpg
+
+Strangely, git doesn't see which changes are present here:
+
+    $ git diff
+    [... takes some time, but no output ...]
+    $ 
+
+Workaround: `git checkout .` - but I don't understand why that is happening in the first place... Is that a bug? -- [[anarcat]]

diff --git a/doc/todo/clarify_that_v7_applies_to_all_clones.mdwn b/doc/todo/clarify_that_v7_applies_to_all_clones.mdwn
index 1ae37d3b3..021d54512 100644
--- a/doc/todo/clarify_that_v7_applies_to_all_clones.mdwn
+++ b/doc/todo/clarify_that_v7_applies_to_all_clones.mdwn
@@ -42,3 +42,5 @@ Considering there's no backport of 7.x in Debian stretch, it makes the
 upgrade path rather delicate... Is there a way to "downgrade" that
 sneakernet repo? :) (Thankfully, the main server still runs v5 so the
 files are still accessible from stretch....) -- [[anarcat]]
+
+Updated the [[upgrades]] page, [[done]].

diff --git a/doc/upgrades.mdwn b/doc/upgrades.mdwn
index f8b7eac69..54eecbaea 100644
--- a/doc/upgrades.mdwn
+++ b/doc/upgrades.mdwn
@@ -44,6 +44,10 @@ The upgrade process needs to write to the repository. If the original
 repository cannot be written to (due to eg being on readonly media),
 the upgrade would need to be run in a copy of the repository.
 
+Some upgrades (most notably v6 and v7) require that all users of the
+repository upgrade simultaneously, otherwise files may become unreadable
+or unfetchable.
+
 The upgrade events, so far:
 
 ## v6 -> v7 (git-annex version 7.x)
@@ -79,6 +83,10 @@ The behavior of some commands changes in an upgraded repository:
 * `git annex unlock` and `git annex lock` change how the pointer to 
   the annexed content is stored in git.
 
+If you commit the unlocked files change, this will impact all clones of the
+repository. This means all clones of the repository will need to run at least
+v6 to correctly synchronise.
+
 There is also a new `annex.thin` setting, which makes unlocked files in v6
 repositories be hard linked to their content, instead of a copy. This saves
 disk space but means any modification of an unlocked file will lose the

diff --git a/doc/todo/clarify_that_v7_applies_to_all_clones/comment_1_62ef170f11f0b700a99c2749018fa234._comment b/doc/todo/clarify_that_v7_applies_to_all_clones/comment_1_62ef170f11f0b700a99c2749018fa234._comment
new file mode 100644
index 000000000..68b62235a
--- /dev/null
+++ b/doc/todo/clarify_that_v7_applies_to_all_clones/comment_1_62ef170f11f0b700a99c2749018fa234._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2018-12-04T20:53:49Z"
+ content="""
+You only need to upgrade to v7 when the repository has unlocked files
+committed to it. If a file contains a pointer to an annex object, it won't
+work with v5. There is not a good way for git-annex to detect when that is
+the case; such a file could be committed any time. Committing unlocked
+files and upgrading has to be coordinated amoung the users of the repository.
+"""]]

diff --git a/doc/todo/clarify_that_v7_applies_to_all_clones.mdwn b/doc/todo/clarify_that_v7_applies_to_all_clones.mdwn
new file mode 100644
index 000000000..1ae37d3b3
--- /dev/null
+++ b/doc/todo/clarify_that_v7_applies_to_all_clones.mdwn
@@ -0,0 +1,44 @@
+I am not sure this is the case, but from first-hand experience, it
+sure looks like you can't turn on v7 (or really v6, actually) on a
+single git worktree. For example, if I have my `pictures` repository
+on `curie` and turn on v7, `angela` will *also* need to run `git annex
+upgrade` on their worktree otherwise git-annex
+(e.g. 6.20180913-1~bpo9+1 on Debian stretch) will be really confused:
+
+    anarcat@angela:calendes$ less calendrier/calendes.pdf
+    /annex/objects/SHA256E-s117451415--8d7d8366094a63c54bef99b5cd2e2b5187092f834d8bf7002e1d5fdceb38a710.pdf
+    anarcat@angela:calendes$ git annex get calendrier/calendes.pdf
+    anarcat@angela:calendes$ git annex whereis calendrier/calendes.pdf
+    anarcat@angela:calendes$ # OMG WHERE ARE MY FILES! /me flails wildly
+
+:)
+
+It seems to me there should be a warning in the [[upgrades]] page
+about this. I would have done so myself, but I'm not sure (like in my
+last bug report) if I am doing things right.
+
+In this case, this repository was already present (v5, indirect mode)
+on both machines. I upgraded (using `git annex upgrade`) the
+repository on curie (7.20181121 Debian buster) which went well.
+
+(Then I messed around with that thumb drive, which led to
+[[bugs/v7_fails_to_fetch_files_on_FAT_filesystem]], but probably
+unrelated here.)
+
+Then i powered on my laptop (`angela`) and saw the above. I would have
+expected it to either upgrade automatically or warn me about the
+repository inconsistency. Of failing that, the upgrades page should at
+least warn us this is a "system-wide" (how do we call that?) change...
+
+The workaround is to run `git annex upgrade` on that other repo, of
+course, but if the source repo was also upgraded, it might be
+difficult to sync files, as you will see that warning:
+
+    $ git annex get
+    get calendrier/calendes.pdf (from sneakernet...) 
+    Repository version 7 is not supported. Upgrade git-annex.
+
+Considering there's no backport of 7.x in Debian stretch, it makes the
+upgrade path rather delicate... Is there a way to "downgrade" that
+sneakernet repo? :) (Thankfully, the main server still runs v5 so the
+files are still accessible from stretch....) -- [[anarcat]]

diff --git a/doc/todo/dockerized_external_special_remotes/comment_1_d1a0106951c070b56bc30a67c8804374._comment b/doc/todo/dockerized_external_special_remotes/comment_1_d1a0106951c070b56bc30a67c8804374._comment
new file mode 100644
index 000000000..5c10c0f4b
--- /dev/null
+++ b/doc/todo/dockerized_external_special_remotes/comment_1_d1a0106951c070b56bc30a67c8804374._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="comment 1"
+ date="2018-12-04T19:56:36Z"
+ content="""
+Some external special remotes need to run git-annex, for things not directly supported by the protocol; a dockerized remote implementation couldn't do that.  But maybe, the protocol could be extended with a command by which the remote asks git-annex to run a given git-annex command, and return paths to files containing the output and the exit code?
+"""]]

diff --git a/doc/bugs/Unable_to_setup_gcrypt_Remote_with_encryption__61__shared/comment_1_ada804190026c4f2bbe85101dfaa6cb2._comment b/doc/bugs/Unable_to_setup_gcrypt_Remote_with_encryption__61__shared/comment_1_ada804190026c4f2bbe85101dfaa6cb2._comment
new file mode 100644
index 000000000..3443536ea
--- /dev/null
+++ b/doc/bugs/Unable_to_setup_gcrypt_Remote_with_encryption__61__shared/comment_1_ada804190026c4f2bbe85101dfaa6cb2._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="lukasstraub2@bbbb2ef261a0994edda5f5f55999dfac5998d4e5"
+ nickname="lukasstraub2"
+ avatar="http://cdn.libravatar.org/avatar/c7c08e2efd29c692cc017c4a4ca3406b"
+ subject="Workaround"
+ date="2018-12-04T19:37:37Z"
+ content="""
+As a workaround, I can include a \"gnupg\" Directory in the Repo and point the GNUPGHOME environment Variable at it. Then I simply create a single Key there and add the gcrypt Repo with encryption=hybrid. Altough I have to add the following to the gpg.conf (in the gnupg Directory inside the Repo) to prevent gpg from writing to the directory afterwards:
+pinentry-mode loopback
+no-auto-check-trustdb
+no-random-seed-file
+no-permission-warning
+quiet
+
+"""]]

diff --git a/doc/todo/encrypt_only_the_credentials/comment_1_7c3911e8fbc981c7e1f32b1464ce4122._comment b/doc/todo/encrypt_only_the_credentials/comment_1_7c3911e8fbc981c7e1f32b1464ce4122._comment
index 608275208..cd11a687c 100644
--- a/doc/todo/encrypt_only_the_credentials/comment_1_7c3911e8fbc981c7e1f32b1464ce4122._comment
+++ b/doc/todo/encrypt_only_the_credentials/comment_1_7c3911e8fbc981c7e1f32b1464ce4122._comment
@@ -11,7 +11,7 @@ with one or more keyids.
 
 Note that the tahoe special remote supports embedcreds,
 but disallows setting any encryption (because tahoe handles that)
-so the encryptions can only be stored in the clear. It would make sense for
+so the creds can only be stored in the clear currently. It would make sense for
 tahoe to support encryption=onlycreds while disallowing other encryption
 methods.
 

diff --git a/doc/todo/encrypt_only_the_credentials/comment_3_6f0ba120ef655d5250fdf3db53464fe6._comment b/doc/todo/encrypt_only_the_credentials/comment_3_6f0ba120ef655d5250fdf3db53464fe6._comment
new file mode 100644
index 000000000..bed73a5f7
--- /dev/null
+++ b/doc/todo/encrypt_only_the_credentials/comment_3_6f0ba120ef655d5250fdf3db53464fe6._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2018-12-04T19:20:11Z"
+ content="""
+Yes, gpg-agent is why I'm not stressing the potential extra gpg use by that
+setting.
+"""]]

diff --git a/doc/todo/encrypting_URLs.mdwn b/doc/todo/encrypting_URLs.mdwn
index a733254bb..1b8fe9e10 100644
--- a/doc/todo/encrypting_URLs.mdwn
+++ b/doc/todo/encrypting_URLs.mdwn
@@ -3,7 +3,7 @@ E.g. record the URL as encryptedurl://key_id/[base64-encoded encryption of the o
 
 Many cloud services let you create a pre-signed URL for a non-public file.  Anyone with the URL can get the file, so the URL is "public" in that sense;
 but you only share the URL with intended recipient(s), not the public.  Or you might store files in a bucket that can be publicly read but not listed, and
-store files under paths like s3://mybucket/<randomstring>/myfile ; the URL is "public" but in practice it can't be guessed.
+store files under paths like s3://mybucket/randomstring/myfile ; the URL is "public" but in practice it can't be guessed.
 If the URLs could be stored encrypted in the git-annex branch, one could track such files using the ordinary web remote.  One could use an S3 export-tree
 remote to share a directory with specific recipient(s), without them needing either AWS credentials or git-annex.
 

diff --git a/doc/todo/encrypting_URLs.mdwn b/doc/todo/encrypting_URLs.mdwn
new file mode 100644
index 000000000..a733254bb
--- /dev/null
+++ b/doc/todo/encrypting_URLs.mdwn
@@ -0,0 +1,9 @@
+When recording a URL from which a key may be fetched, add an option to store that URL in encrypted form (encrypted to a given public key).
+E.g. record the URL as encryptedurl://key_id/[base64-encoded encryption of the original URL].
+
+Many cloud services let you create a pre-signed URL for a non-public file.  Anyone with the URL can get the file, so the URL is "public" in that sense;
+but you only share the URL with intended recipient(s), not the public.  Or you might store files in a bucket that can be publicly read but not listed, and
+store files under paths like s3://mybucket/<randomstring>/myfile ; the URL is "public" but in practice it can't be guessed.
+If the URLs could be stored encrypted in the git-annex branch, one could track such files using the ordinary web remote.  One could use an S3 export-tree
+remote to share a directory with specific recipient(s), without them needing either AWS credentials or git-annex.
+

diff --git a/doc/todo/encrypt_only_the_credentials/comment_2_76fdfa927562d33dfea9630b3b729220._comment b/doc/todo/encrypt_only_the_credentials/comment_2_76fdfa927562d33dfea9630b3b729220._comment
new file mode 100644
index 000000000..2a8d87bb3
--- /dev/null
+++ b/doc/todo/encrypt_only_the_credentials/comment_2_76fdfa927562d33dfea9630b3b729220._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ilya_Shlyakhter"
+ avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
+ subject="comment 2"
+ date="2018-12-04T18:40:01Z"
+ content="""
+thanks!  \"that would cause more gpg prompts\" -- wouldn't gpg-agent prevent that?
+"""]]

diff --git a/CHANGELOG b/CHANGELOG
index 11164036e..18e195587 100644
--- a/CHANGELOG
+++ b/CHANGELOG
@@ -15,6 +15,8 @@ git-annex (7.20181122) UNRELEASED; urgency=medium
   * dropunused: When an unused object file has gotten modified, eg due to
     annex.thin being set, don't silently skip it, but display a warning
     and let --force drop it.
+  * annex.cachecreds: New config to allow disabling of credentials caching
+    for special remotes.
 
  -- Joey Hess <id@joeyh.name>  Tue, 27 Nov 2018 12:29:27 -0400
 
diff --git a/Creds.hs b/Creds.hs
index 3450af484..bb602cf35 100644
--- a/Creds.hs
+++ b/Creds.hs
@@ -139,9 +139,11 @@ getEnvCredPair storage = liftM2 (,)
   where
 	(uenv, penv) = credPairEnvironment storage
 
+{- Writes a cred pair to local cache, unless prevented by configuration. -}
 writeCacheCredPair :: CredPair -> CredPairStorage -> Annex ()
-writeCacheCredPair credpair storage =
-	writeCreds (encodeCredPair credpair) (credPairFile storage)
+writeCacheCredPair credpair storage = 
+	whenM (annexCacheCreds <$> Annex.getGitConfig) $
+		writeCreds (encodeCredPair credpair) (credPairFile storage)
 
 readCacheCredPair :: CredPairStorage -> Annex (Maybe CredPair)
 readCacheCredPair storage = maybe Nothing decodeCredPair
diff --git a/Types/GitConfig.hs b/Types/GitConfig.hs
index 2dc922569..fb2eae457 100644
--- a/Types/GitConfig.hs
+++ b/Types/GitConfig.hs
@@ -102,6 +102,7 @@ data GitConfig = GitConfig
 	, annexAllowUnverifiedDownloads :: Bool
 	, annexMaxExtensionLength :: Maybe Int
 	, annexJobs :: Concurrency
+	, annexCacheCreds :: Bool
 	, coreSymlinks :: Bool
 	, coreSharedRepository :: SharedRepository
 	, receiveDenyCurrentBranch :: DenyCurrentBranch
@@ -177,6 +178,7 @@ extractGitConfig r = GitConfig
 		getmaybe (annex "security.allow-unverified-downloads")
 	, annexMaxExtensionLength = getmayberead (annex "maxextensionlength")
 	, annexJobs = maybe NonConcurrent Concurrent $ getmayberead (annex "jobs")
+	, annexCacheCreds = getbool (annex "cachecreds") True
 	, coreSymlinks = getbool "core.symlinks" True
 	, coreSharedRepository = getSharedRepository r
 	, receiveDenyCurrentBranch = getDenyCurrentBranch r
diff --git a/doc/encryption.mdwn b/doc/encryption.mdwn
index ddde431b1..c578ddedf 100644
--- a/doc/encryption.mdwn
+++ b/doc/encryption.mdwn
@@ -129,3 +129,16 @@ of the special remote with the option `mac=HMACSHA512`. The available
 MAC algorithms are HMACSHA1, HMACSHA224, HMACSHA256, HMACSHA384, and
 HMACSHA512. Note that it is not possible to change algorithm for a
 non-empty remote.
+
+## credentials storage
+
+Special remotes that need some form of credentials, such as a password,
+may support embedding the credentials in the git repository, using
+embedcreds=yes. See individual special remotes' documentation for details.
+When credentials are embedded in the repository, they're also encrypted using
+whatever encryption setting has been selected for the repository.
+
+Such credentials are also cached locally in a file only you can read,
+in `.git/annex/creds/`. If you prefer to not expose the credentials on disk
+in unencrypted form, you can disable this cache, by setting the
+`annex.cachecreds` config to `false`.
diff --git a/doc/git-annex.mdwn b/doc/git-annex.mdwn
index fff75e31f..a0c0f6e0f 100644
--- a/doc/git-annex.mdwn
+++ b/doc/git-annex.mdwn
@@ -1160,6 +1160,16 @@ Here are all the supported configuration settings.
   git-annex will wait up to this many seconds for the pid lock
   file to go away, and will then abort if it cannot continue. Default: 300
 
+* `annex.cachecreds`
+
+  When "true" (the default), git-annex will cache credentials used to
+  access special remotes in files in .git/annex/creds/
+  that only you can read. To disable that caching, set to "false",
+  and credentials will only be read from the environment, or if
+  they have been embedded in encrypted form in the git repository, will
+  be extracted and decrypted each time git-annex needs to access the
+  remote.
+
 * `remote.<name>.annex-cost`
 
   When determining which repository to
diff --git a/doc/todo/encrypt_only_the_credentials/comment_1_7c3911e8fbc981c7e1f32b1464ce4122._comment b/doc/todo/encrypt_only_the_credentials/comment_1_7c3911e8fbc981c7e1f32b1464ce4122._comment
new file mode 100644
index 000000000..608275208
--- /dev/null
+++ b/doc/todo/encrypt_only_the_credentials/comment_1_7c3911e8fbc981c7e1f32b1464ce4122._comment
@@ -0,0 +1,30 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2018-12-04T17:18:19Z"
+ content="""
+I agree it would make sense to have some way to embedcreds without
+encrypting content stored on the remote.
+
+I suppose one way to express it is as encryption=onlycreds embedcreds=yes
+with one or more keyids.
+
+Note that the tahoe special remote supports embedcreds,
+but disallows setting any encryption (because tahoe handles that)
+so the encryptions can only be stored in the clear. It would make sense for
+tahoe to support encryption=onlycreds while disallowing other encryption
+methods.
+
+----
+
+As for storing creds locally only in encrypted form, it would suffice to
+have an option that makes git-annex not write anything to
+.git/annex/creds/, so it would not use those files as a cache, and would
+pull the creds out of the repository and decrypt each time needed
+(or use environment varibles for creds when applicable.) In some cases
+that would cause more gpg prompts. I think that S3 and WebDAV special
+remotes only call getRemoteCredPair once per run, but external may
+call it repeatedly, and glacier calls it once per request.
+
+Implemented as annex.cachecreds.
+"""]]

diff --git a/doc/thanks/list b/doc/thanks/list
index d0a6f9cda..0c8702075 100644
--- a/doc/thanks/list
+++ b/doc/thanks/list
@@ -105,3 +105,4 @@ paul walmsley,
 John Lee, 
 Ilya Shlyakhter, 
 AlexS, 
+Boris, 

diff --git a/doc/forum/Permissions_error_with_ssh_key_authentication_to_remote/comment_1_39a096f92f0280db9502397b9fc55541._comment b/doc/forum/Permissions_error_with_ssh_key_authentication_to_remote/comment_1_39a096f92f0280db9502397b9fc55541._comment
new file mode 100644
index 000000000..945375bf9
--- /dev/null
+++ b/doc/forum/Permissions_error_with_ssh_key_authentication_to_remote/comment_1_39a096f92f0280db9502397b9fc55541._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2018-12-04T17:16:41Z"
+ content="""
+That does not look like a permissions error, I mean it could be one, but
+all you show is git-annex not being able to access the repository, which
+could be any kind of configuration problem.
+"""]]

diff --git a/doc/bugs/upgrade_to_version_7_not_going_well__44___bup_remote_missing_its_uuid.mdwn b/doc/bugs/upgrade_to_version_7_not_going_well__44___bup_remote_missing_its_uuid.mdwn
index 8ead8eee0..fdb47b1a6 100644
--- a/doc/bugs/upgrade_to_version_7_not_going_well__44___bup_remote_missing_its_uuid.mdwn
+++ b/doc/bugs/upgrade_to_version_7_not_going_well__44___bup_remote_missing_its_uuid.mdwn
@@ -76,3 +76,9 @@ upgrade supported from repository versions: 0 1 2 3 4 5 6
 ### 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 git-annex! has been helping me manage my files for years!
+
+> As far as I can see, this is either user error having removed the
+> annex.uuid config from the bup repo somehow, or something other than
+> git-annex did it, or perhaps the bup repo that was initialized for use
+> with this remote has since been replaced by another bup repo. No
+> indication that this is a bug in git-annex so [[done]]. --[[Joey]]

diff --git a/doc/bugs/upgrade_to_version_7_not_going_well__44___bup_remote_missing_its_uuid/comment_1_1a26474498c3683c4b1a7d41cd3f7ed2._comment b/doc/bugs/upgrade_to_version_7_not_going_well__44___bup_remote_missing_its_uuid/comment_1_1a26474498c3683c4b1a7d41cd3f7ed2._comment
new file mode 100644
index 000000000..fb3473bf7
--- /dev/null
+++ b/doc/bugs/upgrade_to_version_7_not_going_well__44___bup_remote_missing_its_uuid/comment_1_1a26474498c3683c4b1a7d41cd3f7ed2._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2018-12-04T16:59:53Z"
+ content="""
+I doubt this has anything to do with v7, it made no changes in this area.
+I've verified that git-annex's bup support is still working.
+
+git-annex embeds a uuid into a bup repository, so the annex-uuid listed in
+the git-annex repo's .git/config is only a cache of the last seen uuid. So
+it seems that, when git-annex tries to read the uuid from your bup
+repository, it's not finding anything.
+
+In your bup repository's git config file, there should be an annex.uuid
+setting. It seems that you've somehow lost that. There's no way git-annex
+would remove it. You can of course run 
+"git config annex.uuid 3af6c3c4-973a-481e-82d0-bfc15bff6f30" in the bup
+repository to add it back, if you're sure that the bup repository is the
+same one git-annex was using before.
+"""]]

diff --git a/doc/bugs/v7_fails_to_fetch_files_on_FAT_filesystem/comment_2_f2ee808b3ee2631f1a753fe0c8e2a001._comment b/doc/bugs/v7_fails_to_fetch_files_on_FAT_filesystem/comment_2_f2ee808b3ee2631f1a753fe0c8e2a001._comment
new file mode 100644
index 000000000..60007031a
--- /dev/null
+++ b/doc/bugs/v7_fails_to_fetch_files_on_FAT_filesystem/comment_2_f2ee808b3ee2631f1a753fe0c8e2a001._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="anarcat"
+ avatar="http://cdn.libravatar.org/avatar/4ad594c1e13211c1ad9edb81ce5110b7"
+ subject="thanks!"
+ date="2018-12-04T17:10:15Z"
+ content="""
+well, that was fast! we'll have to invent a new heisenbug-type of bug for you: the bug that's fixed *before* you report it. :) i'm glad I wasn't hallucinating this too...
+"""]]

diff --git a/doc/todo/add_prefix_option_to_export.mdwn b/doc/todo/add_prefix_option_to_export.mdwn
index cb34d2170..e219e41c6 100644
--- a/doc/todo/add_prefix_option_to_export.mdwn
+++ b/doc/todo/add_prefix_option_to_export.mdwn
@@ -5,3 +5,5 @@ Something like `git annex export master:some-videos --to myexport --prefix share
 I could then do another export using the same remote like `git annex export master:some-other-videos --to myexport --prefix share-with-bill` which wouldn't touch any of the videos I previously shared with john but would create a new export into a new `share-with-bill` directory.
 
 My goal with the prefix option is to setup an exporttree remote one time, but then be able to re-use this same remote multiple times to create independent publicly shared folders.
+
+> [[done]], seems we've decided against adding this --[[Joey]]
diff --git a/doc/todo/add_prefix_option_to_export/comment_6_e617a4b1d5833daa5287e168f6d41da1._comment b/doc/todo/add_prefix_option_to_export/comment_6_e617a4b1d5833daa5287e168f6d41da1._comment
new file mode 100644
index 000000000..1de8bccec
--- /dev/null
+++ b/doc/todo/add_prefix_option_to_export/comment_6_e617a4b1d5833daa5287e168f6d41da1._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 6"""
+ date="2018-12-04T16:58:12Z"
+ content="""
+I think that's a good, simple plan.
+"""]]

diff --git a/Annex/Content.hs b/Annex/Content.hs
index b9163ae44..ad0b22038 100644
--- a/Annex/Content.hs
+++ b/Annex/Content.hs
@@ -12,6 +12,7 @@ module Annex.Content (
 	inAnnex',
 	inAnnexSafe,
 	inAnnexCheck,
+	objectFileExists,
 	lockContentShared,
 	lockContentForRemoval,
 	ContentRemovalLock,
@@ -131,6 +132,11 @@ inAnnex' isgood bad check key = withObjectLoc key checkindirect checkdirect
 				)
 			else checkdirect locs
 
+{- Like inAnnex, checks if the object file for a key exists,
+ - but there are no guarantees it has the right content. -}
+objectFileExists :: Key -> Annex Bool
+objectFileExists key = calcRepo (gitAnnexLocation key) >>= liftIO . doesFileExist
+
 {- A safer check; the key's content must not only be present, but
  - is not in the process of being removed. -}
 inAnnexSafe :: Key -> Annex (Maybe Bool)
diff --git a/CHANGELOG b/CHANGELOG
index 2229ceff3..11164036e 100644
--- a/CHANGELOG
+++ b/CHANGELOG
@@ -12,6 +12,9 @@ git-annex (7.20181122) UNRELEASED; urgency=medium
   * info: When used with an exporttree remote, includes an "exportedtree"
     info, which is the tree last exported to the remote. During an export
     conflict, multiple values will be listed.
+  * dropunused: When an unused object file has gotten modified, eg due to
+    annex.thin being set, don't silently skip it, but display a warning
+    and let --force drop it.
 
  -- Joey Hess <id@joeyh.name>  Tue, 27 Nov 2018 12:29:27 -0400
 
diff --git a/Command/DropUnused.hs b/Command/DropUnused.hs
index c5a61d739..d5394c2ea 100644
--- a/Command/DropUnused.hs
+++ b/Command/DropUnused.hs
@@ -1,6 +1,6 @@
 {- git-annex command
  -
- - Copyright 2010,2012 Joey Hess <id@joeyh.name>
+ - Copyright 2010,2012,2018 Joey Hess <id@joeyh.name>
  -
  - Licensed under the GNU GPL version 3 or higher.
  -}
@@ -8,6 +8,7 @@
 module Command.DropUnused where
 
 import Command
+import qualified Annex
 import qualified Command.Drop
 import qualified Remote
 import qualified Git
@@ -48,9 +49,19 @@ perform from numcopies key = case from of
 		showAction $ "from " ++ Remote.name r
 		Command.Drop.performRemote key (AssociatedFile Nothing) numcopies r
 	Nothing -> ifM (inAnnex key)
-		( Command.Drop.performLocal key (AssociatedFile Nothing) numcopies []
-		, next (return True)
+		( droplocal
+		, ifM (objectFileExists key)
+			( ifM (Annex.getState Annex.force)
+				( droplocal
+				, do
+					warning "Annexed object has been modified and dropping it would probably lose the only copy. Run this command with --force if you want to drop it anyway."
+					next $ return False
+				)
+			, next $ return True
+			)
 		)
+  where
+	droplocal = Command.Drop.performLocal key (AssociatedFile Nothing) numcopies []
 
 performOther :: (Key -> Git.Repo -> FilePath) -> Key -> CommandPerform
 performOther filespec key = do
diff --git a/doc/bugs/dropunused_does_nothing/comment_3_8f80959997f6963728a8aee3765dc349._comment b/doc/bugs/dropunused_does_nothing/comment_3_8f80959997f6963728a8aee3765dc349._comment
new file mode 100644
index 000000000..2206573e7
--- /dev/null
+++ b/doc/bugs/dropunused_does_nothing/comment_3_8f80959997f6963728a8aee3765dc349._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2018-12-04T15:46:05Z"
+ content="""
+Indeed, the object seems to be there, but it looks like `dropunused`
+probably for some reason fails its `inAnnex` check and so skips it.
+
+Does `git config annex.thin` output true? If so, and if the object file you
+found does not checksum to the right value, `dropunused` would skip it.
+
+That seems to me to be a bug, it probably should delete even modified files
+in this case. But I don't know if it's the bug you're seeing.
+"""]]
diff --git a/doc/bugs/dropunused_does_nothing/comment_4_7e04e71d0eb03185148ab544bc24724c._comment b/doc/bugs/dropunused_does_nothing/comment_4_7e04e71d0eb03185148ab544bc24724c._comment
new file mode 100644
index 000000000..92ca25aff
--- /dev/null
+++ b/doc/bugs/dropunused_does_nothing/comment_4_7e04e71d0eb03185148ab544bc24724c._comment
@@ -0,0 +1,26 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2018-12-04T15:52:52Z"
+ content="""
+Test case for the annex.thin with modified file bug:
+
+	git annex init
+	git annex upgrade
+	git config annex.thin true
+	touch foo
+	git add foo
+	git commit -m add
+	echo foo >> foo
+	rm foo
+	git commit -m rm -a
+	git annex unused
+	git annex dropunused 1
+	git annex unused
+
+Now, dropunused is supposed to honor numcopies, and if an object file
+has been modified, that's probably the only existing copy of that object,
+and so dropunused should refuse to drop it by default. There ought to be a
+warning, and the user should be able to use --force to override and drop it
+anyway. I've implemented that now.
+"""]]

diff --git a/doc/bugs/v7_fails_to_fetch_files_on_FAT_filesystem.mdwn b/doc/bugs/v7_fails_to_fetch_files_on_FAT_filesystem.mdwn
index f06cc28e0..a0fb0f2e5 100644
--- a/doc/bugs/v7_fails_to_fetch_files_on_FAT_filesystem.mdwn
+++ b/doc/bugs/v7_fails_to_fetch_files_on_FAT_filesystem.mdwn
@@ -126,3 +126,5 @@ I am a faithful user of git-annex since almost the beginning, and it's
 serving me incredibly well. The new v7 mode seems awesome and I have
 high hopes it will solve a *ton* of workflow issues I have identified
 over time with git-annex. So congratulations on that awesome work! :)
+
+> [[fixed|done]] in master, I think. --[[Joey]]
diff --git a/doc/bugs/v7_fails_to_fetch_files_on_FAT_filesystem/comment_1_a940e8cfd427eb3396ac327970a93805._comment b/doc/bugs/v7_fails_to_fetch_files_on_FAT_filesystem/comment_1_a940e8cfd427eb3396ac327970a93805._comment
new file mode 100644
index 000000000..43963db97
--- /dev/null
+++ b/doc/bugs/v7_fails_to_fetch_files_on_FAT_filesystem/comment_1_a940e8cfd427eb3396ac327970a93805._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2018-12-04T16:16:42Z"
+ content="""
+Thing is, it should have auto-upgraded to v7 in that case, and a bug
+prevented it from doing so. Already fixed in
+[[!commit 865d5561035fec84749f8b2131110fab97cd3aa6]].
+"""]]

diff --git a/doc/bugs/dropunused_does_nothing/comment_2_1de1a1027f1b238134ff10f6a1bdef72._comment b/doc/bugs/dropunused_does_nothing/comment_2_1de1a1027f1b238134ff10f6a1bdef72._comment
new file mode 100644
index 000000000..50ed937d4
--- /dev/null
+++ b/doc/bugs/dropunused_does_nothing/comment_2_1de1a1027f1b238134ff10f6a1bdef72._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="xsteadfastx"
+ avatar="http://cdn.libravatar.org/avatar/a07e2adf7ff40bdd4c3fe20ededc0a4e"
+ subject="comment 2"
+ date="2018-12-04T09:46:46Z"
+ content="""
+    $ find ls .git/annex/objects | grep SHA256E-    s5480575--396855045e70ff04dd233f9fcf4e0b42cd25c73a0b0144de53c44bb3ed67972f.done.tif
+    find: ‘ls’: Datei oder Verzeichnis nicht gefunden
+    .git/annex/objects/jK/8x/SHA256E-s5480575--396855045e70ff04dd233f9fcf4e0b42cd25c73a0b0144de53c44bb3ed67972f.done.tif
+    .git/annex/objects/jK/8x/SHA256E-s5480575--396855045e70ff04dd233f9fcf4e0b42cd25c73a0b0144de53c44bb3ed67972f.done.tif/SHA256E-s5480575--396855045e70ff04dd233f9fcf4e0b42cd25c73a0b0144de53c44bb3ed67972f.done.tif
+
+it looks like the object is still there.
+"""]]

diff --git a/doc/bugs/v7_fails_to_fetch_files_on_FAT_filesystem.mdwn b/doc/bugs/v7_fails_to_fetch_files_on_FAT_filesystem.mdwn
index e03ace793..f06cc28e0 100644
--- a/doc/bugs/v7_fails_to_fetch_files_on_FAT_filesystem.mdwn
+++ b/doc/bugs/v7_fails_to_fetch_files_on_FAT_filesystem.mdwn
@@ -7,8 +7,7 @@ filesystem.
 
  1. mount external USB drive named `KINGSTON`
  2. `cd /media/anarcat/KINGSTON`
- 3. `git clone ~/git-annex-repo`
- 4. `git -C git-annex-repo annex info`
+ 3. `git clone ~/git-annex-repo` `git -C git-annex-repo annex info`
 
 ### What version of git-annex are you using? On what operating system?
 
@@ -112,6 +111,15 @@ for me to be able to just copy files that way now. :)
 
 How do I fetch those files anyways? -- [[anarcat]]
 
+> Ugh. Obviously, problem between keyboard and chair here. :( Turns
+> out the clone didn't create a v7 repository, and a simple `git annex
+> upgrade` on the clone fixed the problem. The `Entering an adjusted
+> branch` warning threw me off - I thought it was an indicator that
+> the `init` stage (correctly?) detected it should be in v7 mode. I
+> would have expected a v5 repo to be in classical `direct` mode here,
+> not this weird state where it's "partly v7". Maybe I misunderstood
+> something?
+
 ### 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 am a faithful user of git-annex since almost the beginning, and it's

diff --git a/doc/bugs/v7_fails_to_fetch_files_on_FAT_filesystem.mdwn b/doc/bugs/v7_fails_to_fetch_files_on_FAT_filesystem.mdwn
new file mode 100644
index 000000000..e03ace793
--- /dev/null
+++ b/doc/bugs/v7_fails_to_fetch_files_on_FAT_filesystem.mdwn
@@ -0,0 +1,120 @@
+### Please describe the problem.
+
+I cannot figure out how to fetch file from a new v7 clone on a FAT
+filesystem.
+
+### What steps will reproduce the problem?
+
+ 1. mount external USB drive named `KINGSTON`
+ 2. `cd /media/anarcat/KINGSTON`
+ 3. `git clone ~/git-annex-repo`
+ 4. `git -C git-annex-repo annex info`
+
+### What version of git-annex are you using? On what operating system?
+
+7.20181121 on Debian buster.
+
+### Please provide any additional information below.
+
+I have a small-ish repository (1.2GB) that I was hoping to more
+naturally clone onto an external USB stick. It took a surprisingly
+long time, so at first I thought it was actually fetching the files as
+well:
+
+    anarcat@curie:KINGSTON$ git clone ~/Pictures/calendes
+    Clonage dans 'calendes'...
+    fait.
+    Extraction des fichiers: 100% (174/174), fait.
+    "git clone ~/Pictures/calendes" took 4 mins 54 secs
+
+But no, the repository is actually quite small:
+
+    $ du -shL calendes
+    47M	calendes
+
+Okay, let's figure out what's on there:
+
+    anarcat@curie:calendes$ git annex info
+
+      Detected a filesystem without fifo support.
+
+      Disabling ssh connection caching.
+
+      Detected a crippled filesystem.
+    (merging origin/git-annex into git-annex...)
+    (recording state in git...)
+
+      Entering an adjusted branch where files are unlocked as this filesystem does not support locked files.
+
+    Basculement sur la branche 'adjusted/master(unlocked)'
+    repository mode: indirect
+    trusted repositories: 0
+    semitrusted repositories: 7
+    	00000000-0000-0000-0000-000000000001 -- web
+     	00000000-0000-0000-0000-000000000002 -- bittorrent
+     	012c0223-72a6-4215-92fc-d130420c74b4 -- anarcat@curie:/media/anarcat/KINGSTON/calendes [here]
+     	383d0375-492f-47a3-9ab0-5e98cb8dae7e -- anarcat@angela:~/Pictures/calendes
+     	39538a65-dfdf-461a-80a6-5bba368eac8d -- anarcat@curie:~/Pictures/calendes [origin]
+     	434fe592-63af-4a76-8ee0-25ae70c66dff -- anarcat@marcos:/var/www/calendes
+     	c7cdb1a3-a84f-49b1-a50d-95db16be7313 -- anarcat@marcos:~/Pictures/calendes
+    untrusted repositories: 0
+    transfers in progress: none
+    available local disk space: 15.41 gigabytes (+1 megabyte reserved)
+    local annex keys: 0
+    local annex size: 0 bytes
+    annexed files in working tree: 0
+    size of annexed files in working tree: 0 bytes
+    bloom filter size: 32 mebibytes (0% full)
+    backend usage:
+
+Hmm.. Okay, adjusted branches. Not sure how that works, but let's try
+it out:
+
+    anarcat@curie:calendes$ git annex get
+    anarcat@curie:calendes$ git annex get pictures/2018-01/DSCF1012.RAF
+    anarcat@curie:calendes$
+
+Hmm... That does nothing. Okay, reading back [[git-annex-adjust]], it
+says that `sync --content` should work:
+
+    anarcat@curie:calendes$ git annex sync --content
+    commit 
+    Sur la branche adjusted/master(unlocked)
+    rien à valider, la copie de travail est propre
+    ok
+    pull origin 
+    ok
+    push origin 
+    Énumération des objets: 8, fait.
+    Décompte des objets: 100% (8/8), fait.
+    Compression par delta en utilisant jusqu'à 4 fils d'exécution
+    Compression des objets: 100% (5/5), fait.
+    Écriture des objets: 100% (6/6), 714 bytes | 714.00 KiB/s, fait.
+    Total 6 (delta 2), réutilisés 1 (delta 0)
+    To /home/anarcat/Pictures/calendes
+       a0b9ba9..490f30e  master -> synced/master
+     * [new branch]      git-annex -> synced/git-annex
+    ok
+
+(Ah crap, I forgot `--no-push` and now I need to mark that thing as
+dead.)
+
+Okay, that didn't work either: the files are still missing from the
+USB key. I have also tried to `git annex copy --to KINGSTON` after
+setting up the remote: the copy goes fine, but the file is still
+absent, according to `git annex whereis` from the `KINGSTON` repo's
+perspective, and the file in the worktree is still just the pointer to
+the internal datastructures.
+
+At that point I gave up and copied the files directly using a file
+manager because, thankfully, the new v7 mode seems to work well enough
+for me to be able to just copy files that way now. :)
+
+How do I fetch those files anyways? -- [[anarcat]]
+
+### 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 am a faithful user of git-annex since almost the beginning, and it's
+serving me incredibly well. The new v7 mode seems awesome and I have
+high hopes it will solve a *ton* of workflow issues I have identified
+over time with git-annex. So congratulations on that awesome work! :)

diff --git a/doc/upgrades.mdwn b/doc/upgrades.mdwn
index c71b13230..f8b7eac69 100644
--- a/doc/upgrades.mdwn
+++ b/doc/upgrades.mdwn
@@ -89,6 +89,8 @@ same tradeoff.
 See [[tips/unlocked_files/]] for more details about locked files and thin
 mode.
 
+Run git-annex upgrade to perform this upgrade.
+
 ## v4 -> v5 (git-annex version 5.x)
 
 The upgrade from v4 to v5 is handled

diff --git a/doc/upgrades.mdwn b/doc/upgrades.mdwn
index 5669ed24a..c71b13230 100644
--- a/doc/upgrades.mdwn
+++ b/doc/upgrades.mdwn
@@ -49,6 +49,7 @@ The upgrade events, so far:
 ## v6 -> v7 (git-annex version 7.x)
 
 The upgrade from v5 to v7 is handled manually for now.
+
 Run `git-annex upgrade` to perform the upgrade.
 
 v6 repositories are automatically upgraded to v7.
@@ -61,7 +62,7 @@ were added in v7.
 A v6 git-annex repository can have some files locked while other files are
 unlocked, and all git and git-annex commands can be used on both locked and
 unlocked files. (Although for locked files to be accessible, the filesystem
-must support symbolic links..
+must support symbolic links.)
 
 Direct mode repositories are upgraded to instead use the new 
 [[adjusted branches feature|git-annex-adjust]], which transparently unlocks

diff --git a/doc/bugs/upgrade_to_version_7_not_going_well__44___bup_remote_missing_its_uuid.mdwn b/doc/bugs/upgrade_to_version_7_not_going_well__44___bup_remote_missing_its_uuid.mdwn
new file mode 100644
index 000000000..8ead8eee0
--- /dev/null
+++ b/doc/bugs/upgrade_to_version_7_not_going_well__44___bup_remote_missing_its_uuid.mdwn
@@ -0,0 +1,78 @@
+### Please describe the problem.
+
+A bup remote has lost its UUID, even though it is defined in git's `config` file.
+
+### What steps will reproduce the problem?
+
+`cat config` gives
+[[!format sh """
+[core]
+        repositoryformatversion = 0
+        filemode = true
+        bare = true
+        logallrefupdates = false
+        preloadIndex = true
+        untrackedCache = true
+[annex]
+        uuid = b67bfb7e-3ae1-4cb5-be1c-44cd07a6724b
+        version = 7
+[filter "annex"]
+        smudge = git-annex smudge %f
+        clean = git-annex smudge --clean %f
+[remote "holy-server-backup"]
+        annex-buprepo = /media/pi/DiStephBackup/backup
+        annex-uuid = 3af6c3c4-973a-481e-82d0-bfc15bff6f30
+        annex-sync = false
+[...]
+"""]]
+
+but `git annex info holy-server-backup` has forgotten the uuid (and the description), giving
+
+[[!format sh """
+uuid: 
+description: 
+remote: holy-server-backup
+trust: semitrusted
+cost: 110.0
+type: bup
+repo: /media/pi/DiStephBackup/backup
+encryption: none
+chunking: none
+[...]
+"""]]
+
+Unsurprisingly, commands such as `git annex get --all --from=holy-server-backup` complain with
+
+`git-annex: cannot determine uuid for holy-server-backup (perhaps you need to run "git annex sync"?)`
+
+This has happened after I started using version 7 upgraded from version 6 (with `git annex upgrade`). Before then it was working like a charm.
+And now I cannot revert to version 6...
+
+I'm not sure where version 7 is trying to get the UUID from, if not from the git config file, and why there started to be a discrepancy.
+
+
+### What version of git-annex are you using? On what operating system?
+
+git-annex version: 7.20181106-g352f88226, standalone
+
+[[!format sh """
+operating system: linux arm
+supported repository versions: 5 7
+upgrade supported from repository versions: 0 1 2 3 4 5 6
+"""]]
+
+
+
+### 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
+
+
+# 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)
+
+Yes, I love git-annex! has been helping me manage my files for years!

diff --git a/doc/bugs/Assertion___96__cnt___60_____40__sizeof___40____95__nl__95__value__95__type__95__LC__95__TIME__41_____47___sizeof___40____95__nl__95__value__95__type__95__LC__95__TIME__91__0__93____41____41____39___failed./comment_6_b387cdacf97c476284640195e9fd03c9._comment b/doc/bugs/Assertion___96__cnt___60_____40__sizeof___40____95__nl__95__value__95__type__95__LC__95__TIME__41_____47___sizeof___40____95__nl__95__value__95__type__95__LC__95__TIME__91__0__93____41____41____39___failed./comment_6_b387cdacf97c476284640195e9fd03c9._comment
new file mode 100644
index 000000000..cb8c24fdc
--- /dev/null
+++ b/doc/bugs/Assertion___96__cnt___60_____40__sizeof___40____95__nl__95__value__95__type__95__LC__95__TIME__41_____47___sizeof___40____95__nl__95__value__95__type__95__LC__95__TIME__91__0__93____41____41____39___failed./comment_6_b387cdacf97c476284640195e9fd03c9._comment
@@ -0,0 +1,23 @@
+[[!comment format=mdwn
+ username="StéphaneGL"
+ avatar="http://cdn.libravatar.org/avatar/a12e6e0852d5a1985b8684b17202561c"
+ subject="comment 6"
+ date="2018-12-03T18:22:10Z"
+ content="""
+I had the same error message when trying to run the standalone, version 7.20181106, on my raspberry pi. For some reason, the stand-alone version of git-annex handles and compiles its own locales in 
+
+`~/.cache/git-annex/locales/[SOME_DIRECTORY]/`
+
+For some unknown reason, the locale that git-annex compiled in that directory, namely en_GB.UTF-8 for me, was different from the one from my system, which is kept in `/usr/lib/locales/`.
+Every command that git-annex uses, even just rm, was systematically failing with error `cnt < (sizeof (_nl_value_type_LC_TIME) / sizeof (_nl_value_type_LC_TIME[0]))` after git-annex loaded its own locale instead of the system's (technically, after the runshell script exports LOCPATH=`~/.cache/git-annex/locales/[SOME_DIRECTORY]/`).
+
+Solution I found:
+I erased the version that git-annex compiled and instead placed a symbolic link `~/.cache/git-annex/locales/[SOME_DIRECTORY]/en_GB.UTF-8` towards my system's locale in `/usr/lib/locale/`.
+Then LC_TIME was correctly defined and I got rid of the error `cnt < (sizeof (_nl_value_type_LC_TIME) / sizeof (_nl_value_type_LC_TIME[0]))'
+
+Hope this helps.
+
+It looks like the runshell script is doing something incorrect with the compilation of locales, but I'm not sure what.
+
+
+"""]]

diff --git a/doc/bugs/Assertion___96__cnt___60_____40__sizeof___40____95__nl__95__value__95__type__95__LC__95__TIME__41_____47___sizeof___40____95__nl__95__value__95__type__95__LC__95__TIME__91__0__93____41____41____39___failed./comment_6_8bd5cd02255d8049b9ed5d9965128810._comment b/doc/bugs/Assertion___96__cnt___60_____40__sizeof___40____95__nl__95__value__95__type__95__LC__95__TIME__41_____47___sizeof___40____95__nl__95__value__95__type__95__LC__95__TIME__91__0__93____41____41____39___failed./comment_6_8bd5cd02255d8049b9ed5d9965128810._comment
deleted file mode 100644
index 46539cf3f..000000000
--- a/doc/bugs/Assertion___96__cnt___60_____40__sizeof___40____95__nl__95__value__95__type__95__LC__95__TIME__41_____47___sizeof___40____95__nl__95__value__95__type__95__LC__95__TIME__91__0__93____41____41____39___failed./comment_6_8bd5cd02255d8049b9ed5d9965128810._comment
+++ /dev/null
@@ -1,23 +0,0 @@
-[[!comment format=mdwn
- username="StéphaneGL"
- avatar="http://cdn.libravatar.org/avatar/a12e6e0852d5a1985b8684b17202561c"
- subject="comment 6"
- date="2018-12-03T18:20:28Z"
- content="""
-I had the same error message when trying to run the standalone, version 7.20181106, on my raspberry pi. For some reason, the stand-alone version of git-annex handles and compiles its own locales in 
-
-`~/.cache/git-annex/locales/[SOME_DIRECTORY]/`
-
-For some unknown reason, the locale that git-annex compiled in that directory, namely en_GB.UTF-8 for me, was different from the one from my system, which is kept in `/usr/lib/locale/`.
-Every command that git-annex uses, even just rm, was systematically failing with error `cnt < (sizeof (_nl_value_type_LC_TIME) / sizeof (_nl_value_type_LC_TIME[0]))` after git-annex loaded its own locale instead of the system's (technically, after the runshell script exports LOCPATH=`~/.cache/git-annex/locales/[SOME_DIRECTORY]/`).
-
-Solution I found:
-I erased the version that git-annex compiled and instead placed a symbolic link `~/.cache/git-annex/locales/[SOME_DIRECTORY]/en_GB.UTF-8` towards my system's locale in `/usr/lib/locale/`.
-Then LC_TIME was correctly defined and I got rid of the error `cnt < (sizeof (_nl_value_type_LC_TIME) / sizeof (_nl_value_type_LC_TIME[0]))'
-
-Hope this helps.
-
-It looks like the runshell script is doing something incorrect with the compilation of locales, but I'm not sure what.
-
-
-"""]]

diff --git a/doc/bugs/Assertion___96__cnt___60_____40__sizeof___40____95__nl__95__value__95__type__95__LC__95__TIME__41_____47___sizeof___40____95__nl__95__value__95__type__95__LC__95__TIME__91__0__93____41____41____39___failed./comment_6_8bd5cd02255d8049b9ed5d9965128810._comment b/doc/bugs/Assertion___96__cnt___60_____40__sizeof___40____95__nl__95__value__95__type__95__LC__95__TIME__41_____47___sizeof___40____95__nl__95__value__95__type__95__LC__95__TIME__91__0__93____41____41____39___failed./comment_6_8bd5cd02255d8049b9ed5d9965128810._comment
new file mode 100644
index 000000000..46539cf3f
--- /dev/null
+++ b/doc/bugs/Assertion___96__cnt___60_____40__sizeof___40____95__nl__95__value__95__type__95__LC__95__TIME__41_____47___sizeof___40____95__nl__95__value__95__type__95__LC__95__TIME__91__0__93____41____41____39___failed./comment_6_8bd5cd02255d8049b9ed5d9965128810._comment
@@ -0,0 +1,23 @@
+[[!comment format=mdwn
+ username="StéphaneGL"
+ avatar="http://cdn.libravatar.org/avatar/a12e6e0852d5a1985b8684b17202561c"
+ subject="comment 6"
+ date="2018-12-03T18:20:28Z"
+ content="""
+I had the same error message when trying to run the standalone, version 7.20181106, on my raspberry pi. For some reason, the stand-alone version of git-annex handles and compiles its own locales in 
+
+`~/.cache/git-annex/locales/[SOME_DIRECTORY]/`
+
+For some unknown reason, the locale that git-annex compiled in that directory, namely en_GB.UTF-8 for me, was different from the one from my system, which is kept in `/usr/lib/locale/`.
+Every command that git-annex uses, even just rm, was systematically failing with error `cnt < (sizeof (_nl_value_type_LC_TIME) / sizeof (_nl_value_type_LC_TIME[0]))` after git-annex loaded its own locale instead of the system's (technically, after the runshell script exports LOCPATH=`~/.cache/git-annex/locales/[SOME_DIRECTORY]/`).
+
+Solution I found:
+I erased the version that git-annex compiled and instead placed a symbolic link `~/.cache/git-annex/locales/[SOME_DIRECTORY]/en_GB.UTF-8` towards my system's locale in `/usr/lib/locale/`.
+Then LC_TIME was correctly defined and I got rid of the error `cnt < (sizeof (_nl_value_type_LC_TIME) / sizeof (_nl_value_type_LC_TIME[0]))'
+
+Hope this helps.
+
+It looks like the runshell script is doing something incorrect with the compilation of locales, but I'm not sure what.
+
+
+"""]]

diff --git a/CHANGELOG b/CHANGELOG
index 0b40a6410..2229ceff3 100644
--- a/CHANGELOG
+++ b/CHANGELOG
@@ -9,6 +9,9 @@ git-annex (7.20181122) UNRELEASED; urgency=medium
     be used, set repo version to 7, which it neglected to do before.
   * init: When on a crippled filesystem, and the git version is too old
     to use an adjusted unlocked branch, fall back to using direct mode.
+  * info: When used with an exporttree remote, includes an "exportedtree"
+    info, which is the tree last exported to the remote. During an export
+    conflict, multiple values will be listed.
 
  -- Joey Hess <id@joeyh.name>  Tue, 27 Nov 2018 12:29:27 -0400
 
diff --git a/Remote/Helper/Export.hs b/Remote/Helper/Export.hs
index b1da45a7c..699c33103 100644
--- a/Remote/Helper/Export.hs
+++ b/Remote/Helper/Export.hs
@@ -18,6 +18,8 @@ import Remote.Helper.Encryptable (isEncrypted)
 import Database.Export
 import Annex.Export
 import Config
+import Git.Types (fromRef)
+import Logs.Export
 
 import qualified Data.Map as M
 import Control.Concurrent.STM
@@ -186,8 +188,11 @@ adjustExportable r = case M.lookup "exporttree" (config r) of
 			, checkPresentCheap = False
 			, mkUnavailable = return Nothing
 			, getInfo = do
+				ts <- map (\t -> ("exportedtree", fromRef t) )
+					. map exportedTreeish
+					<$> getExport (uuid r)
 				is <- getInfo r
-				return (is++[("export", "yes")])
+				return (is++[("export", "yes")]++ts)
 			}
 	retrieveKeyFileFromExport getexportlocs exportinconflict k _af dest p = unVerified $
 		if maybe False (isJust . verifyKeyContent) (maybeLookupBackendVariety (keyVariety k))
diff --git a/doc/todo/add_prefix_option_to_export/comment_5_fe7223a5321b8a4aef723e276513f5be._comment b/doc/todo/add_prefix_option_to_export/comment_5_fe7223a5321b8a4aef723e276513f5be._comment
new file mode 100644
index 000000000..64a639c6e
--- /dev/null
+++ b/doc/todo/add_prefix_option_to_export/comment_5_fe7223a5321b8a4aef723e276513f5be._comment
@@ -0,0 +1,23 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2018-12-03T17:53:59Z"
+ content="""
+I wonder if you'd be better off querying `git annex whereis --json` 
+for public urls and providing those to the users. Several special remotes
+provide public urls. (S3 needs a non-default configuration to do it.)
+
+Anyway back to your question, git-annex arranges for the exported tree to
+always be available, including across clones of the repository. So you can
+get the exported tree, graft another file into it, and export the new tree.
+
+So how to look up the previously exported tree? [[/internals]] documents
+how to find it in the export.log, but it seems there ought to be a
+command-line interface to query for it. So I've made `git annex info remote`
+provide that information, as "exportedtree". Note that in an export
+conflict it may have multiple values. You'll want to use --fast with that,
+and probably --json.
+
+Let me know if you need something more, or if this todo can be closed with
+that.
+"""]]

diff --git a/doc/todo/assistant_should_detect_added_remotes/comment_1_1cadcd0d5c61a04bd1118d94e3fc7f45._comment b/doc/todo/assistant_should_detect_added_remotes/comment_1_1cadcd0d5c61a04bd1118d94e3fc7f45._comment
new file mode 100644
index 000000000..0fc3e5e76
--- /dev/null
+++ b/doc/todo/assistant_should_detect_added_remotes/comment_1_1cadcd0d5c61a04bd1118d94e3fc7f45._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2018-12-03T17:48:38Z"
+ content="""
+The assistant watches for changes to the git-annex branch, and reloads its
+list of remotes within 60 seconds after a change.
+
+If you're using `git remote add`, that doesn't affect the git-annex branch,
+so the assistant won't notice the new remote. Once `git annex
+sync` with that remote, the git-annex branch will be updated and the
+assistant will notice it then.
+"""]]

diff --git a/doc/bugs/Assertion___96__cnt___60_____40__sizeof___40____95__nl__95__value__95__type__95__LC__95__TIME__41_____47___sizeof___40____95__nl__95__value__95__type__95__LC__95__TIME__91__0__93____41____41____39___failed./comment_6_a852f4b40506edf9948c7953b01aa340._comment b/doc/bugs/Assertion___96__cnt___60_____40__sizeof___40____95__nl__95__value__95__type__95__LC__95__TIME__41_____47___sizeof___40____95__nl__95__value__95__type__95__LC__95__TIME__91__0__93____41____41____39___failed./comment_6_a852f4b40506edf9948c7953b01aa340._comment
new file mode 100644
index 000000000..ff0771f3b
--- /dev/null
+++ b/doc/bugs/Assertion___96__cnt___60_____40__sizeof___40____95__nl__95__value__95__type__95__LC__95__TIME__41_____47___sizeof___40____95__nl__95__value__95__type__95__LC__95__TIME__91__0__93____41____41____39___failed./comment_6_a852f4b40506edf9948c7953b01aa340._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 6"""
+ date="2018-12-03T17:41:43Z"
+ content="""
+Same problem reported in another bug, the bug sumitter was using Ubuntu
+14.04.5 LTS. Which also makes me think it's related to kernel version.
+"""]]
diff --git a/doc/bugs/rsync_fails_with_sync_error__58___syntax_or_usage_error.mdwn b/doc/bugs/rsync_fails_with_sync_error__58___syntax_or_usage_error.mdwn
index 650cd793e..bc458ee2b 100644
--- a/doc/bugs/rsync_fails_with_sync_error__58___syntax_or_usage_error.mdwn
+++ b/doc/bugs/rsync_fails_with_sync_error__58___syntax_or_usage_error.mdwn
@@ -109,3 +109,5 @@ upgrade supported from repository versions: 0 1 2 3 4 5 6
 ### 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)
 
 git annex has worked well for more than a year now :) happy user.
+
+> closing as a duplicate bug report [[done]] --[[Joey]]
diff --git a/doc/bugs/rsync_fails_with_sync_error__58___syntax_or_usage_error/comment_1_ebf78424a6dc1a886bd9286daedd71ce._comment b/doc/bugs/rsync_fails_with_sync_error__58___syntax_or_usage_error/comment_1_ebf78424a6dc1a886bd9286daedd71ce._comment
new file mode 100644
index 000000000..f7dcc1772
--- /dev/null
+++ b/doc/bugs/rsync_fails_with_sync_error__58___syntax_or_usage_error/comment_1_ebf78424a6dc1a886bd9286daedd71ce._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2018-12-03T17:40:15Z"
+ content="""
+This is the same problem as
+<http://git-annex.branchable.com/bugs/Assertion___96__cnt___60_____40__sizeof___40____95__nl__95__value__95__type__95__LC__95__TIME__41_____47___sizeof___40____95__nl__95__value__95__type__95__LC__95__TIME__91__0__93____41____41____39___failed./>
+and I'll bet your git-annex on the remote machine was installed from the
+standalone tarball too?
+"""]]

diff --git a/doc/walkthrough/adding_a_remote/comment_8_0c1005ec29e17846ba1a061ec7f36750._comment b/doc/walkthrough/adding_a_remote/comment_8_0c1005ec29e17846ba1a061ec7f36750._comment
deleted file mode 100644
index 0732255ce..000000000
--- a/doc/walkthrough/adding_a_remote/comment_8_0c1005ec29e17846ba1a061ec7f36750._comment
+++ /dev/null
@@ -1,8 +0,0 @@
-[[!comment format=mdwn
- username="techcustomersupport"
- avatar="http://cdn.libravatar.org/avatar/150632946f1b1da29beadfb6e4ce513b"
- subject="adding a remote"
- date="2018-11-26T11:43:08Z"
- content="""
-To add a new remote, use the git remote add command on the terminal, in the directory your repository is stored at. The git remote add command takes two arguments: A remote name, for example, origin. For more information visit - <a href=\"https://www.applesupportphonenumbers.com/blog/fix-mac-error-code-36/\">https://www.applesupportphonenumbers.com/blog/fix-mac-error-code-36/</a>
-"""]]

diff --git a/doc/tips/local_caching_of_annexed_files/comment_19_490c15d7673c535e83c7f1df3082e7ed._comment b/doc/tips/local_caching_of_annexed_files/comment_19_490c15d7673c535e83c7f1df3082e7ed._comment
new file mode 100644
index 000000000..d97f12092
--- /dev/null
+++ b/doc/tips/local_caching_of_annexed_files/comment_19_490c15d7673c535e83c7f1df3082e7ed._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 19"""
+ date="2018-12-03T17:34:10Z"
+ content="""
+git-annex looks at the file's stat() and only if the device id is the same
+as the stat of the destination directory does it use `cp`. If you see it
+running `rsync` instead, it's under the perhaps mistaken impression that
+it's a cross-device copy.
+"""]]

diff --git a/doc/bugs/dropunused_does_nothing/comment_1_493d556a74bfc7bec15f4c9881977b0c._comment b/doc/bugs/dropunused_does_nothing/comment_1_493d556a74bfc7bec15f4c9881977b0c._comment
new file mode 100644
index 000000000..d3ded0881
--- /dev/null
+++ b/doc/bugs/dropunused_does_nothing/comment_1_493d556a74bfc7bec15f4c9881977b0c._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2018-12-03T17:27:14Z"
+ content="""
+I wonder if the problem is with `unused` somehow listing files whose
+content is not present, or with `dropunused` somehow failing to remove the
+content. If you run `find -ls .git/annex/objects | grep SHA256E-s5480575--396855045e70ff04dd233f9fcf4e0b42cd25c73a0b0144de53c44bb3ed67972f.done.tif` 
+what does it output?
+"""]]