Recent changes to this wiki:

diff --git a/doc/bugs/Metadata_values_get_stuck_when_repeatedly_modified_in_the_same_batch_mode_run.mdwn b/doc/bugs/Metadata_values_get_stuck_when_repeatedly_modified_in_the_same_batch_mode_run.mdwn
new file mode 100644
index 0000000..1ec07dc
--- /dev/null
+++ b/doc/bugs/Metadata_values_get_stuck_when_repeatedly_modified_in_the_same_batch_mode_run.mdwn
@@ -0,0 +1,84 @@
+### Please describe the problem.
+
+While running `git-annex metadata --batch --json`, repeatedly assigning a field to the same value in the same run (with different values in between the assignments of the same value) causes a value to get stuck.
+
+### What steps will reproduce the problem?
+
+    $ touch test.txt
+    $ git annex add
+    $ git-annex metadata --batch --json
+    {"file":"test.txt","fields":{"f":["a"]}}
+    # prints { ... "f":["a"] ... }
+    {"file":"test.txt","fields":{"f":["b"]}}
+    # prints { ... "f":["b"] ... }
+    {"file":"test.txt","fields":{"f":["c"]}}
+    # prints { ... "f":["c"] ... }
+    {"file":"test.txt","fields":{"f":["a"]}}
+    # prints { ... "f":["a", "c"] ... }
+    {"file":"test.txt","fields":{"f":["b"]}}
+    # prints { ... "f":["c"] ... }
+    
+### What version of git-annex are you using? On what operating system?
+
+    git-annex version: 6.20161122+gitg9f179ae-1~ndall+1
+    build flags: Assistant Webapp Pairing Testsuite S3(multipartupload)(storageclasses) WebDAV Inotify DBus DesktopNotify XMPP ConcurrentOutput TorrentParser MagicMime Feeds Quvi
+    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 SHA1E SHA1 MD5E MD5 WORM URL
+    remote types: git gcrypt S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external
+    local repository version: 5
+    supported repository versions: 3 5 6
+    upgrade supported from repository versions: 0 1 2 3 4 5
+    operating system: linux x86_64
+
+I'm using Xubuntu 16.04, with the `git-annex-standalone` package from NeuroDebian repository.
+
+### Please provide any additional information below.
+
+If you keep reassigning the same values, things get very weird. Full inputs/outputs from a sample run:
+
+    {"file":"test.txt","fields":{"f":["a"]}}
+    {"command":"metadata","note":"f=a\nf-lastchanged=2016-12-05@21-17-39\nlastchanged=2016-12-05@21-17-39\n","success":true,"key":"SHA256E-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855.txt","file":"test.txt","fields":    {"f-lastchanged":["2016-12-05@21-17-39"],"lastchanged":["2016-12-05@21-17-39"],"f":["a"]}}
+    {"file":"test.txt","fields":{"f":["b"]}}
+    {"command":"metadata","note":"f=b\nf-lastchanged=2016-12-05@21-17-39\nlastchanged=2016-12-05@21-17-39\n","success":true,"key":"SHA256E-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855.txt","file":"test.txt","fields":{"f-lastchanged":["2016-12-05@21-17-39"],"lastchanged":["2016-12-05@21-17-39"],"f":["b"]}}
+    {"file":"test.txt","fields":{"f":["c"]}}
+    {"command":"metadata","note":"f=c\nf-lastchanged=2016-12-05@21-17-39\nlastchanged=2016-12-05@21-17-39\n","success":true,"key":"SHA256E-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855.txt","file":"test.txt","fields":{"f-lastchanged":["2016-12-05@21-17-39"],"lastchanged":["2016-12-05@21-17-39"],"f":["c"]}}
+    {"file":"test.txt","fields":{"f":["a"]}}
+    {"command":"metadata","note":"f=a\nf=c\nf-lastchanged=2016-12-05@21-17-39\nlastchanged=2016-12-05@21-17-39\n","success":true,"key":"SHA256E-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855.txt","file":"test.txt","fields":{"f-lastchanged":["2016-12-05@21-17-39"],"lastchanged":["2016-12-05@21-17-39"],"f":["a","c"]}}
+    {"file":"test.txt","fields":{"f":["b"]}}
+    {"command":"metadata","note":"f=c\nf-lastchanged=2016-12-05@21-17-39\nlastchanged=2016-12-05@21-17-39\n","success":true,"key":"SHA256E-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855.txt","file":"test.txt","fields":{"f-lastchanged":["2016-12-05@21-17-39"],"lastchanged":["2016-12-05@21-17-39"],"f":["c"]}}
+    {"file":"test.txt","fields":{"f":[]}}   
+    {"command":"metadata","note":"lastchanged=2016-12-05@21-17-39\n","success":true,"key":"SHA256E-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855.txt","file":"test.txt","fields":{"lastchanged":["2016-12-05@21-17-39"]}}
+    {"file":"test.txt","fields":{"f":["b"]}}
+    {"command":"metadata","note":"lastchanged=2016-12-05@21-17-39\n","success":true,"key":"SHA256E-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855.txt","file":"test.txt","fields":{"lastchanged":["2016-12-05@21-17-39"]}}
+    {"file":"test.txt","fields":{"f":["c"]}}
+    {"command":"metadata","note":"f=c\nf-lastchanged=2016-12-05@21-17-39\nlastchanged=2016-12-05@21-17-39\n","success":true,"key":"SHA256E-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855.txt","file":"test.txt","fields":{"f-lastchanged":["2016-12-05@21-17-39"],"lastchanged":["2016-12-05@21-17-39"],"f":["c"]}}
+    {"file":"test.txt","fields":{"f":["a"]}}
+    {"command":"metadata","note":"f=a\nf=c\nf-lastchanged=2016-12-05@21-17-39\nlastchanged=2016-12-05@21-17-39\n","success":true,"key":"SHA256E-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855.txt","file":"test.txt","fields":{"f-lastchanged":["2016-12-05@21-17-39"],"lastchanged":["2016-12-05@21-17-39"],"f":["a","c"]}}
+    {"file":"test.txt","fields":{"f":["b"]}}
+    {"command":"metadata","note":"f=c\nf-lastchanged=2016-12-05@21-17-39\nlastchanged=2016-12-05@21-17-39\n","success":true,"key":"SHA256E-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855.txt","file":"test.txt","fields":{"f-lastchanged":["2016-12-05@21-17-39"],"lastchanged":["2016-12-05@21-17-39"],"f":["c"]}}
+    {"file":"test.txt","fields":{"f":["c"]}}
+    {"command":"metadata","note":"f=c\nf-lastchanged=2016-12-05@21-17-39\nlastchanged=2016-12-05@21-17-39\n","success":true,"key":"SHA256E-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855.txt","file":"test.txt","fields":{"f-lastchanged":["2016-12-05@21-17-39"],"lastchanged":["2016-12-05@21-17-39"],"f":["c"]}}
+    {"file":"test.txt","fields":{"f":["a"]}}
+    {"command":"metadata","note":"f=a\nf=c\nf-lastchanged=2016-12-05@21-17-39\nlastchanged=2016-12-05@21-17-39\n","success":true,"key":"SHA256E-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855.txt","file":"test.txt","fields":{"f-lastchanged":["2016-12-05@21-17-39"],"lastchanged":["2016-12-05@21-17-39"],"f":["a","c"]}}
+    {"file":"test.txt","fields":{"f":["b"]}}
+    {"command":"metadata","note":"f=c\nf-lastchanged=2016-12-05@21-17-39\nlastchanged=2016-12-05@21-17-39\n","success":true,"key":"SHA256E-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855.txt","file":"test.txt","fields":{"f-lastchanged":["2016-12-05@21-17-39"],"lastchanged":["2016-12-05@21-17-39"],"f":["c"]}}
+    {"file":"test.txt","fields":{"f":["b"]}}
+    {"command":"metadata","note":"f=b\nf=c\nf-lastchanged=2016-12-05@21-17-39\nlastchanged=2016-12-05@21-17-39\n","success":true,"key":"SHA256E-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855.txt","file":"test.txt","fields":{"f-lastchanged":["2016-12-05@21-17-39"],"lastchanged":["2016-12-05@21-17-39"],"f":["b","c"]}}
+    {"file":"test.txt","fields":{"f":["a"]}}
+    {"command":"metadata","note":"f=a\nf=b\nf=c\nf-lastchanged=2016-12-05@21-17-39\nlastchanged=2016-12-05@21-17-39\n","success":true,"key":"SHA256E-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855.txt","file":"test.txt","fields":{"f-lastchanged":["2016-12-05@21-17-39"],"lastchanged":["2016-12-05@21-17-39"],"f":["a","b","c"]}}
+    {"file":"test.txt","fields":{"f":["d"]}}
+    {"command":"metadata","note":"f=b\nf=c\nf=d\nf-lastchanged=2016-12-05@21-17-39\nlastchanged=2016-12-05@21-17-39\n","success":true,"key":"SHA256E-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855.txt","file":"test.txt","fields":{"f-lastchanged":["2016-12-05@21-17-39"],"lastchanged":["2016-12-05@21-17-39"],"f":["b","c","d"]}}
+    {"file":"test.txt","fields":{"f":["a"]}}
+    {"command":"metadata","note":"f=b\nf=c\nf=d\nf-lastchanged=2016-12-05@21-17-39\nlastchanged=2016-12-05@21-17-39\n","success":true,"key":"SHA256E-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855.txt","file":"test.txt","fields":{"f-lastchanged":["2016-12-05@21-17-39"],"lastchanged":["2016-12-05@21-17-39"],"f":["b","c","d"]}}
+    {"file":"test.txt","fields":{"f":["a"]}}
+    {"command":"metadata","note":"f=b\nf=c\nf=d\nf-lastchanged=2016-12-05@21-17-39\nlastchanged=2016-12-05@21-17-39\n","success":true,"key":"SHA256E-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855.txt","file":"test.txt","fields":{"f-lastchanged":["2016-12-05@21-17-39"],"lastchanged":["2016-12-05@21-17-39"],"f":["b","c","d"]}}
+    {"file":"test.txt","fields":{"f":[]}}   
+    {"command":"metadata","note":"f=c\nf-lastchanged=2016-12-05@21-17-39\nlastchanged=2016-12-05@21-17-39\n","success":true,"key":"SHA256E-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855.txt","file":"test.txt","fields":{"f-lastchanged":["2016-12-05@21-17-39"],"lastchanged":["2016-12-05@21-17-39"],"f":["c"]}}
+    
+Restarting the process solves the issue.
+
+### 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 love the metadata functionality so much that I wrote [[tips/a_gui_for_metadata_operations]] and discovered this bug.
+Metadata driven views are awesome (but I don't like the entire folder hierarchy being appended to the filename).
+I haven't used the other commands much since I have not yet organized most of my stuff (and their naively copy-pasted backups), but I am glad I discovered git-annex before I began organizing.
+

Added a comment: UTF-8 problems in some other commands
diff --git a/doc/bugs/git-annex_fromkey_barfs_on_utf-8_input/comment_1_aa6fe46ee76dd8bfa9a56cbd5131cb8b._comment b/doc/bugs/git-annex_fromkey_barfs_on_utf-8_input/comment_1_aa6fe46ee76dd8bfa9a56cbd5131cb8b._comment
new file mode 100644
index 0000000..a0409e2
--- /dev/null
+++ b/doc/bugs/git-annex_fromkey_barfs_on_utf-8_input/comment_1_aa6fe46ee76dd8bfa9a56cbd5131cb8b._comment
@@ -0,0 +1,55 @@
+[[!comment format=mdwn
+ username="alpernebbi"
+ avatar="http://cdn.libravatar.org/avatar/daf2abb14f39e28ad75d5f9a03fcd106"
+ subject="UTF-8 problems in some other commands"
+ date="2016-12-05T20:46:07Z"
+ content="""
+Running the command above gives me the same error on Xubuntu 16.04, using `git-annex-standalone` package from NeuroDebian repositories.
+
+    git-annex version: 6.20161122+gitg9f179ae-1~ndall+1
+    build flags: Assistant Webapp Pairing Testsuite S3(multipartupload)(storageclasses) WebDAV Inotify DBus DesktopNotify XMPP ConcurrentOutput TorrentParser MagicMime Feeds Quvi
+    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 SHA1E SHA1 MD5E MD5 WORM URL
+    remote types: git gcrypt S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external
+    local repository version: 5
+    supported repository versions: 3 5 6
+    upgrade supported from repository versions: 0 1 2 3 4 5
+    operating system: linux x86_64
+
+I encountered other commands that fail as well:
+
+    $ touch u.txt ü.txt
+    $ git annex add
+
+    $ git-annex calckey ü.txt
+    # prints key
+
+    $ git-annex calckey --batch
+    ü.txt
+    # dies
+
+    $ git-annex lookupkey ü.txt
+    # prints key
+
+    $ git-annex lookupkey --batch
+    ü.txt
+    # dies
+
+    $ git-annex metadata --batch --json
+    {\"file\":\"ü.txt\"}
+    # dies
+
+    $ git-annex metadata --batch --json
+    {\"file\":\"u.txt\",\"fields\":{\"ü\":[\"b\"]}}
+    # dies
+
+    $ git-annex metadata --batch --json
+    {\"file\":\"u.txt\",\"fields\":{\"a\":[\"ü\"]}}
+    # dies
+
+All those die without output, all $? are 0.
+No values were recorded to metadata.
+Also:
+
+    $ git-annex-metadata --json
+    # entry for \"ü.txt\" has \"file\":\"��.txt\"
+"""]]

diff --git a/doc/tips/a_gui_for_metadata_operations.mdwn b/doc/tips/a_gui_for_metadata_operations.mdwn
new file mode 100644
index 0000000..1e11800
--- /dev/null
+++ b/doc/tips/a_gui_for_metadata_operations.mdwn
@@ -0,0 +1,13 @@
+Hey everyone.
+
+I wrote a GUI for git-annex metadata in Python: [git-annex-metadata-gui](https://github.com/alpernebbi/git-annex-metadata-gui). 
+It shows the files that are in the current branch (only those in the annex) in the respective folder hierarchy.
+The keys that are in the repository, but not in the current branch are also shown in another tab.
+You can view, edit or remove fields for individual files with support for multiple values for fields.
+There is a file preview for image and text files as well.
+I uploaded some screenshots in the repository to show it in action.
+
+While making it, I decided to move the git-annex calls into its own Python package, 
+which became [git-annex-adapter](https://github.com/alpernebbi/git-annex-adapter).
+
+I hope these can be useful to someone other than myself as well.

fix formatting
mdwn2man gets confused as `command` spanning multiple lines..
diff --git a/doc/git-annex-add.mdwn b/doc/git-annex-add.mdwn
index b65ed51..15bb8a6 100644
--- a/doc/git-annex-add.mdwn
+++ b/doc/git-annex-add.mdwn
@@ -15,9 +15,9 @@ If no path is specified, adds files from the current directory and below.
 Files that are already checked into git and are unmodified, or that
 git has been configured to ignore will be silently skipped.
 
-If annex.largefiles is configured, and does not match a file, `git annex
-add` will behave the same as `git add` and add the non-large file directly
-to the git repository, instead of to the annex.
+If annex.largefiles is configured, and does not match a file, 
+`git annex add` will behave the same as `git add` and add the
+non-large file directly to the git repository, instead of to the annex.
 
 Large files are added to the annex in locked form, which prevents further
 modification of their content unless unlocked by [[git-annex-unlock]](1).

rekey: Added --batch mode.
Would have liked to make the Parser parse the file and key pairs, but it
seems that optparse-applicative is unable to handle eg:
many ((,) <$> argument <*> argument)
This commit was sponsored by Thomas Hochstein on Patreon.
diff --git a/CHANGELOG b/CHANGELOG
index 215349f..c30447f 100644
--- a/CHANGELOG
+++ b/CHANGELOG
@@ -13,6 +13,7 @@ git-annex (6.20161119) UNRELEASED; urgency=medium
   * rmurl: Added --batch mode.
   * fromkey: Accept multiple pairs of files and keys.
     Thanks, Daniel Brooks.
+  * rekey: Added --batch mode.
 
  -- Joey Hess <id@joeyh.name>  Mon, 21 Nov 2016 11:27:50 -0400
 
diff --git a/Command/ReKey.hs b/Command/ReKey.hs
index 33734eb..4ddbd68 100644
--- a/Command/ReKey.hs
+++ b/Command/ReKey.hs
@@ -25,15 +25,39 @@ cmd = notDirect $
 	command "rekey" SectionPlumbing
 		"change keys used for files"
 		(paramRepeating $ paramPair paramPath paramKey)
-		(withParams seek)
+		(seek <$$> optParser)
 
-seek :: CmdParams -> CommandSeek
-seek = withPairs start
+data ReKeyOptions = ReKeyOptions
+	{ reKeyThese :: CmdParams
+	, batchOption :: BatchMode
+	}
 
-start :: (FilePath, String) -> CommandStart
-start (file, keyname) = ifAnnexed file go stop
+optParser :: CmdParamsDesc -> Parser ReKeyOptions
+optParser desc = ReKeyOptions
+	<$> cmdParams desc
+	<*> parseBatchOption
+
+-- Split on the last space, since a FilePath can contain whitespace,
+-- but a Key very rarely does.
+batchParser :: String -> Either String (FilePath, Key)
+batchParser s = case separate (== ' ') (reverse s) of
+	(rk, rf)
+		| null rk || null rf -> Left "Expected: \"file key\""
+		| otherwise -> case file2key (reverse rk) of
+			Nothing -> Left "bad key"
+			Just k -> Right (reverse rf, k)
+
+seek :: ReKeyOptions -> CommandSeek
+seek o = case batchOption o of
+	Batch -> batchInput batchParser (batchCommandAction . start)
+	NoBatch -> withPairs (start . parsekey) (reKeyThese o)
+  where
+	parsekey (file, skey) =
+		(file, fromMaybe (giveup "bad key") (file2key skey))
+
+start :: (FilePath, Key) -> CommandStart
+start (file, newkey) = ifAnnexed file go stop
   where
-	newkey = fromMaybe (giveup "bad key") $ file2key keyname
 	go oldkey
 		| oldkey == newkey = stop
 		| otherwise = do
diff --git a/Command/RmUrl.hs b/Command/RmUrl.hs
index 0f33d66..1a547a7 100644
--- a/Command/RmUrl.hs
+++ b/Command/RmUrl.hs
@@ -10,7 +10,6 @@ module Command.RmUrl where
 import Command
 import Logs.Web
 import qualified Remote
-import CmdLine.Batch
 
 cmd :: Command
 cmd = notBareRepo $
diff --git a/doc/git-annex-rekey.mdwn b/doc/git-annex-rekey.mdwn
index 4ec0b49..ce5e43d 100644
--- a/doc/git-annex-rekey.mdwn
+++ b/doc/git-annex-rekey.mdwn
@@ -20,6 +20,12 @@ Multiple pairs of file and key can be given in a single command line.
   Allow rekeying of even files whose content is not currently available.
   Use with caution.
 
+* `--batch`
+
+  Enables batch mode, in which lines are read from stdin.
+  Each line should contain the file, and the new key to use for that file,
+  separated by a single space.
+
 # SEE ALSO
 
 [[git-annex]](1)

cleanup
diff --git a/doc/git-annex-rmurl.mdwn b/doc/git-annex-rmurl.mdwn
index e971e62..504685a 100644
--- a/doc/git-annex-rmurl.mdwn
+++ b/doc/git-annex-rmurl.mdwn
@@ -10,10 +10,6 @@ git annex rmurl `[file url ..]`
 
 Record that the file is no longer available at the url.
 
-If nothing is specified on the command line, they are instead read
-from stdin. Any number of lines can be provided in this mode,
-each containing a file and and url, separated by a single space.
-
 # OPTIONS
 
 * `--batch`

rmurl: --batch
* rmurl: Multiple pairs of files and urls can be provided on the
command line.
* rmurl: Added --batch mode.
This commit was sponsored by Trenton Cronholm on Patreon.
diff --git a/CHANGELOG b/CHANGELOG
index 76da79e..384dc3c 100644
--- a/CHANGELOG
+++ b/CHANGELOG
@@ -8,6 +8,9 @@ git-annex (6.20161119) UNRELEASED; urgency=medium
     does not support graphical display, while xdot does.
   * Debian: xdot is a better interactive viewer than dot, so Suggest
     xdot, rather than graphviz.
+  * rmurl: Multiple pairs of files and urls can be provided on the
+    command line.
+  * rmurl: Added --batch mode.
 
  -- Joey Hess <id@joeyh.name>  Mon, 21 Nov 2016 11:27:50 -0400
 
diff --git a/Command/RmUrl.hs b/Command/RmUrl.hs
index eb78f7b..0f33d66 100644
--- a/Command/RmUrl.hs
+++ b/Command/RmUrl.hs
@@ -1,6 +1,6 @@
 {- git-annex command
  -
- - Copyright 2013 Joey Hess <id@joeyh.name>
+ - Copyright 2013-2016 Joey Hess <id@joeyh.name>
  -
  - Licensed under the GNU GPL version 3 or higher.
  -}
@@ -10,18 +10,39 @@ module Command.RmUrl where
 import Command
 import Logs.Web
 import qualified Remote
+import CmdLine.Batch
 
 cmd :: Command
 cmd = notBareRepo $
 	command "rmurl" SectionCommon 
 		"record file is not available at url"
-		(paramPair paramFile paramUrl)
-		(withParams seek)
+		(paramRepeating (paramPair paramFile paramUrl))
+		(seek <$$> optParser)
 
-seek :: CmdParams -> CommandSeek
-seek = withPairs start
+data RmUrlOptions = RmUrlOptions
+	{ rmThese :: CmdParams
+	, batchOption :: BatchMode
+	}
 
-start :: (FilePath, String) -> CommandStart
+optParser :: CmdParamsDesc -> Parser RmUrlOptions
+optParser desc = RmUrlOptions
+	<$> cmdParams desc
+	<*> parseBatchOption
+
+seek :: RmUrlOptions -> CommandSeek
+seek o = case batchOption o of
+	Batch -> batchInput batchParser (batchCommandAction . start)
+	NoBatch -> withPairs start (rmThese o)
+
+-- Split on the last space, since a FilePath can contain whitespace,
+-- but a url should not.
+batchParser :: String -> Either String (FilePath, URLString)
+batchParser s = case separate (== ' ') (reverse s) of
+	(ru, rf)
+		| null ru || null rf -> Left "Expected: \"file url\""
+		| otherwise -> Right (reverse rf, reverse ru)
+
+start :: (FilePath, URLString) -> CommandStart
 start (file, url) = flip whenAnnexed file $ \_ key -> do
 	showStart "rmurl" file
 	next $ next $ cleanup url key
diff --git a/doc/git-annex-rmurl.mdwn b/doc/git-annex-rmurl.mdwn
index 5faf9ea..e971e62 100644
--- a/doc/git-annex-rmurl.mdwn
+++ b/doc/git-annex-rmurl.mdwn
@@ -4,12 +4,24 @@ git-annex rmurl - record file is not available at url
 
 # SYNOPSIS
 
-git annex rmurl `file url`
+git annex rmurl `[file url ..]`
 
 # DESCRIPTION
 
 Record that the file is no longer available at the url.
 
+If nothing is specified on the command line, they are instead read
+from stdin. Any number of lines can be provided in this mode,
+each containing a file and and url, separated by a single space.
+
+# OPTIONS
+
+* `--batch`
+
+  Enables batch mode, in which lines are read from stdin.
+  Each line should contain the file, and the url to remove from that file,
+  separated by a single space.
+
 # SEE ALSO
 
 [[git-annex]](1)

git-annex fromkey now takes multiple pairs of keys and filenames
It also still reads from stdin when none are specified.
diff --git a/Command/FromKey.hs b/Command/FromKey.hs
index 670e9e6..0916cf7 100644
--- a/Command/FromKey.hs
+++ b/Command/FromKey.hs
@@ -20,16 +20,18 @@ import Network.URI
 cmd :: Command
 cmd = notDirect $ notBareRepo $
 	command "fromkey" SectionPlumbing "adds a file using a specific key"
-		(paramPair paramKey paramPath)
+		(paramRepeating (paramPair paramKey paramPath))
 		(withParams seek)
 
 seek :: CmdParams -> CommandSeek
+seek [] = do
+	withNothing startMass []
 seek ps = do
 	force <- Annex.getState Annex.force
-	withWords (start force) ps
+	withPairs (start force) ps
 
-start :: Bool -> [String] -> CommandStart
-start force (keyname:file:[]) = do
+start :: Bool -> (String, FilePath) -> CommandStart
+start force (keyname, file) = do
 	let key = mkKey keyname
 	unless force $ do
 		inbackend <- inAnnex key
@@ -37,10 +39,11 @@ start force (keyname:file:[]) = do
 			"key ("++ keyname ++") is not present in backend (use --force to override this sanity check)"
 	showStart "fromkey" file
 	next $ perform key file
-start _ [] = do
+
+startMass :: CommandStart
+startMass = do
 	showStart "fromkey" "stdin"
 	next massAdd
-start _ _ = giveup "specify a key and a dest file"
 
 massAdd :: CommandPerform
 massAdd = go True =<< map (separate (== ' ')) . lines <$> liftIO getContents
diff --git a/doc/git-annex-fromkey.mdwn b/doc/git-annex-fromkey.mdwn
index 461f42e..2591e97 100644
--- a/doc/git-annex-fromkey.mdwn
+++ b/doc/git-annex-fromkey.mdwn
@@ -4,14 +4,16 @@ git-annex fromkey - adds a file using a specific key
 
 # SYNOPSIS
 
-git annex fromkey `[key file]`
+git annex fromkey `[key file ...]`
 
 # DESCRIPTION
 
 This plumbing-level command can be used to manually set up a file
 in the git repository to link to a specified key.
 
-If the key and file are not specified on the command line, they are
+Multiple pairs of file and key can be given in a single command line.
+
+If no key and file pair are specified on the command line, they are
 instead read from stdin. Any number of lines can be provided in this
 mode, each containing a key and filename, separated by a single space.
 
@@ -26,7 +28,7 @@ to do that.
 * `--force`
 
   Allow making a file link to a key whose content is not in the local
-  repository. The key may not be known to git-annex at all.  
+  repository. The key may not be known to git-annex at all.
 
 # SEE ALSO
 

"fixed" by reading --help
diff --git a/doc/bugs/annex_add_ignores_.-prefixed_directories.mdwn b/doc/bugs/annex_add_ignores_.-prefixed_directories.mdwn
index 66f3b65..5db40f4 100644
--- a/doc/bugs/annex_add_ignores_.-prefixed_directories.mdwn
+++ b/doc/bugs/annex_add_ignores_.-prefixed_directories.mdwn
@@ -74,3 +74,5 @@ Changes to be committed:
 Ref: https://github.com/datalad/datalad/issues/1027
 
 [[!meta author=yoh]]
+
+[[done]]; oh -- it is RTFM: --include-dotfiles  --[[yoh]]

added forgotten author tag
diff --git a/doc/bugs/annex_add_ignores_.-prefixed_directories.mdwn b/doc/bugs/annex_add_ignores_.-prefixed_directories.mdwn
index f4ebfe6..66f3b65 100644
--- a/doc/bugs/annex_add_ignores_.-prefixed_directories.mdwn
+++ b/doc/bugs/annex_add_ignores_.-prefixed_directories.mdwn
@@ -72,3 +72,5 @@ Changes to be committed:
 """]]
 
 Ref: https://github.com/datalad/datalad/issues/1027
+
+[[!meta author=yoh]]

initial report
diff --git a/doc/bugs/annex_add_ignores_.-prefixed_directories.mdwn b/doc/bugs/annex_add_ignores_.-prefixed_directories.mdwn
new file mode 100644
index 0000000..f4ebfe6
--- /dev/null
+++ b/doc/bugs/annex_add_ignores_.-prefixed_directories.mdwn
@@ -0,0 +1,74 @@
+### Please describe the problem.
+
+annex add  seems to ignore content under directories having . prefix.
+
+We thought to unify (across direct/indirect/v6) adding files to annex repository by using 'git annex add' with corresponding setting for largefiles for any addition, but it seems to ignore content under .-prefixed directories, unlike git
+
+### What version of git-annex are you using? On what operating system?
+
+6.20161122+gitg9f179ae-1~ndall+1
+
+### Please provide any additional information below.
+
+[[!format sh """
+hopa:/tmp/datalad_temp_test_annex_add_no_dotfilesqMXck8
+$> git status                      
+On branch master
+ 
+Initial commit
+
+nothing to commit (create/copy files and use "git add" to track)
+
+$> mkdir .dir dir; echo 123 > .dir/123; echo 124 > dir/124
+
+$> git status
+On branch master
+
+Initial commit
+
+Untracked files:
+  (use "git add <file>..." to include in what will be committed)
+
+	.dir/
+	dir/
+
+nothing added to commit but untracked files present (use "git add" to track)
+
+$> git annex add -c 'annex.largefiles=nothing' .
+add dir/124 (non-large file; adding content to git repository) ok
+(recording state in git...)
+
+$> git status
+On branch master
+
+Initial commit
+
+Changes to be committed:
+  (use "git rm --cached <file>..." to unstage)
+
+	new file:   dir/124
+
+Untracked files:
+  (use "git add <file>..." to include in what will be committed)
+
+	.dir/
+
+
+# and with regular git
+$> git  -c 'annex.largefiles=nothing' add . 
+
+$> git status
+On branch master
+
+Initial commit
+
+Changes to be committed:
+  (use "git rm --cached <file>..." to unstage)
+
+	new file:   .dir/123
+	new file:   dir/124
+
+
+"""]]
+
+Ref: https://github.com/datalad/datalad/issues/1027

diff --git a/doc/forum/more_intelligent_copy_.mdwn b/doc/forum/more_intelligent_copy_.mdwn
new file mode 100644
index 0000000..1c9889a
--- /dev/null
+++ b/doc/forum/more_intelligent_copy_.mdwn
@@ -0,0 +1,15 @@
+Hi,
+
+I noticed, that 
+
+git annex copy --to REMOTE FILES
+
+and 
+
+git annex copy --to REMOTE --not --in REMOTE FILES
+
+behave differently. The first does not check, whether file contents are already in the remote the latter does that. I realize that this mimics "normal" (UNIX) copy behaviour but I was not entirely certain this was desired.
+Depending on the type of the remote and its configuration (encryption) the latter is considerably faster.
+
+Just my two cents.
+

Added a comment
diff --git a/doc/bugs/Nearline_bucket_stopped_working___40__can__39__t_even_HEAD_files__41__/comment_3_5ac676877feaa7cdb9e05d6b71b1a4c3._comment b/doc/bugs/Nearline_bucket_stopped_working___40__can__39__t_even_HEAD_files__41__/comment_3_5ac676877feaa7cdb9e05d6b71b1a4c3._comment
new file mode 100644
index 0000000..67b215b
--- /dev/null
+++ b/doc/bugs/Nearline_bucket_stopped_working___40__can__39__t_even_HEAD_files__41__/comment_3_5ac676877feaa7cdb9e05d6b71b1a4c3._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="justin.lebar@7a36fcafc322d9a381e89f08ab6289033c6dde91"
+ nickname="justin.lebar"
+ avatar="http://cdn.libravatar.org/avatar/9fca4b61a1ab555f231851e7543f9a3e"
+ subject="comment 3"
+ date="2016-12-04T04:30:38Z"
+ content="""
+For a while things were working, but now it's not working again, same problem as before.
+
+Do you think maybe it's a timestamp bug in the signature or something?  That could explain this \"mysteriously works then stops working\" behavior.
+"""]]

use list
diff --git a/doc/thanks.mdwn b/doc/thanks.mdwn
index 645cca7..eec4686 100644
--- a/doc/thanks.mdwn
+++ b/doc/thanks.mdwn
@@ -1,6 +1,6 @@
 The development of git-annex was made possible by the generous
 donations of many people. I want to say "Thank You!" to each of
-you individually, but until I meet all 1500 of you, this page will have to
+you individually, but until I meet all 1500+ of you, this page will have to
 do. You have my most sincere thanks. --[[Joey]]
 
 You can support my git-annex development
@@ -18,16 +18,8 @@ git-annex development is partially supported by the
 [NSF](https://www.nsf.gov/awardsearch/showAward?AWD_ID=1429999) as a part of the
 [DataLad project](http://datalad.org/).
 
-Thanks also to these folks for their support: martin f. krafft, John Byrnes,
-Aurélien Couderc, Jeffrey Chiu, Amitai Schlair, Andreas, Anthony DeRobertis,
-Baldur Kristinsson, Boyd Stephen Smith Jr., Brock Spratlen, Christian Diller,
-Denis Dzyubenko, Eskild Hustvedt, Evgeni Kunev, FBC, Fernando Jimenez, Greg
-Young, Henrik RIomar, Ignacio, Jake Vosloo, James Valleroy, Jason Woofenden,
-Jeff Goeke-Smith, Jim, Jochen Bartl, Johannes Schlatow, John Carr, Josh
-Taylor, Josh Triplett, Kuno Woudt, Matthias Urlichs, Mattias J, Nathan Howell,
-Nick Daly, Nicolas Schodet, Ole-Morten Duesund, Remy van Elst, RémiV, Thom
-May, Thomas Ferris Nicolaisen, Thomas Hochstein, Tyler Cipriani, encryptio,
-Øyvind A. Holm
+Thanks also to these folks for their support: 
+[[!inline raw=yes pages="thanks/list"]] and anonymous supporters.
 
 ## 2013-2014
 
@@ -385,13 +377,11 @@ Tyree, Aaron Whitehouse
 * Rsync.net, for providing me a free account so I can make sure git-annex
   works well with it.
 * LeastAuthority.com, for providing me a free Tahoe-LAFS grid account,
-  so I can test git-annex with that, and back up the git-annex assistant
-  screencasts.
+  so I can test git-annex with that.
+* Yury V. Zaytsev for running the Windows autobuilder.
+* Kevin McKenzie for providing a OSX account for testing.
 * Anna and Mark, for the loan of the video camera; as well as the rest of
   my family, for your support. Even when I couldn't explain what I was
   working on.
-* The Hodges, for providing such a congenial place for me to live and work
-  on these first world problems, while you're off helping people in the
-  third world.
 * And Mom, for stamping and stuffing so many thank you envelopes, and all the
   rhubarb pies.

update
diff --git a/doc/thanks/list b/doc/thanks/list
index 7b5a19e..653466f 100644
--- a/doc/thanks/list
+++ b/doc/thanks/list
@@ -41,4 +41,13 @@ Thomas Ferris Nicolaisen,
 Thomas Hochstein, 
 Tyler Cipriani, 
 encryptio, 
-Øyvind A. Holm,
+Øyvind A. Holm, 
+Bruno BEAUFILS, 
+Rémi Vanicat, 
+Trenton Cronholm, 
+Francois Marier, 
+Peter Hogg, 
+Amitai Schleier, 
+Brennen Bearnes, 
+Tim Howes, 
+Willard Korfhage, 

break out curent list of names into its own file so I can auto-add from patreon
and some misc updates
diff --git a/doc/thanks/list b/doc/thanks/list
new file mode 100644
index 0000000..7b5a19e
--- /dev/null
+++ b/doc/thanks/list
@@ -0,0 +1,44 @@
+martin f. krafft, 
+John Byrnes, 
+Aurélien Couderc, 
+Jeffrey Chiu, 
+Amitai Schlair, 
+Andreas, 
+Anthony DeRobertis, 
+Baldur Kristinsson, 
+Boyd Stephen Smith Jr., 
+Brock Spratlen, 
+Christian Diller, 
+Denis Dzyubenko, 
+Eskild Hustvedt, 
+Evgeni Kunev, 
+FBC, 
+Fernando Jimenez, 
+Greg Young, 
+Henrik RIomar, 
+Ignacio, 
+Jake Vosloo, 
+James Valleroy, 
+Jason Woofenden, 
+Jeff Goeke-Smith, 
+Jim, 
+Jochen Bartl, 
+Johannes Schlatow, 
+John Carr, 
+Josh Taylor, 
+Josh Triplett, 
+Kuno Woudt, 
+Matthias Urlichs, 
+Mattias J, 
+Nathan Howell, 
+Nick Daly, 
+Nicolas Schodet, 
+Ole-Morten Duesund, 
+Remy van Elst, 
+RémiV, 
+Thom May, 
+Thomas Ferris Nicolaisen, 
+Thomas Hochstein, 
+Tyler Cipriani, 
+encryptio, 
+Øyvind A. Holm,

diff --git a/doc/todo/Long_Running_Filter_Process.mdwn b/doc/todo/Long_Running_Filter_Process.mdwn
new file mode 100644
index 0000000..329abaf
--- /dev/null
+++ b/doc/todo/Long_Running_Filter_Process.mdwn
@@ -0,0 +1,22 @@
+Hello,
+
+while reading the release notes of git 2.11 I noticed a cool new feature has been merged:
+
+> If the filter command (a string value) is defined via
+> `filter.<driver>.process` then Git can process all blobs with a
+> single filter invocation for the entire life of a single Git
+> command.
+
+see the [git documentation][1].
+
+This has been developed in the context of git-lfs (see [PR 1382] [2]).
+
+If I understand correctly how it works this could speed up v6 repos. Looking at the history/website 
+of git-annex there doesn't seem to be yet any work on this so I though it was worth calling the 
+attention on the feature.
+
+Thanks a lot for all the work on git-annex, it's a really amazing project! The more I study it the more cool features I discover :)
+
+
+[1]: https://github.com/git/git/blob/v2.11.0/Documentation/gitattributes.txt#L384
+[2]: https://github.com/git-lfs/git-lfs/pull/1382

diff --git a/doc/bugs/ssh___34__Include__34___feature_broke_Android.mdwn b/doc/bugs/ssh___34__Include__34___feature_broke_Android.mdwn
index 8cdf8e1..9be4d43 100644
--- a/doc/bugs/ssh___34__Include__34___feature_broke_Android.mdwn
+++ b/doc/bugs/ssh___34__Include__34___feature_broke_Android.mdwn
@@ -4,3 +4,5 @@ https://git-annex.branchable.com/bugs/git_annex_init_failed_due_to_unsupported_s
 Unfortunately, the Android apk (which I got from https://downloads.kitenet.net/git-annex/android/current/5.0/git-annex.apk) has (according to ssh -v) OpenSSH_6.0p1.
 
 I had to edit .git/annex/ssh.config to comment out the three offending lines and then append the contents of ~/.ssh/config to get git-annex working again.
+
+(This is on a Nexus 10 running stock, though I doubt it matters)

diff --git a/doc/bugs/ssh___34__Include__34___feature_broke_Android.mdwn b/doc/bugs/ssh___34__Include__34___feature_broke_Android.mdwn
new file mode 100644
index 0000000..8cdf8e1
--- /dev/null
+++ b/doc/bugs/ssh___34__Include__34___feature_broke_Android.mdwn
@@ -0,0 +1,6 @@
+### Please describe the problem.
+https://git-annex.branchable.com/bugs/git_annex_init_failed_due_to_unsupported_ssh_option/ deal with Include not being supported by pre 7.3 by using the 6.4+ IgnoreUnknown directive.
+
+Unfortunately, the Android apk (which I got from https://downloads.kitenet.net/git-annex/android/current/5.0/git-annex.apk) has (according to ssh -v) OpenSSH_6.0p1.
+
+I had to edit .git/annex/ssh.config to comment out the three offending lines and then append the contents of ~/.ssh/config to get git-annex working again.

change link to windows autobuild page
diff --git a/doc/builds.mdwn b/doc/builds.mdwn
index e6c7c80..77c9351 100644
--- a/doc/builds.mdwn
+++ b/doc/builds.mdwn
@@ -49,7 +49,7 @@
 <iframe width=1024 scrolling=no frameborder=0 marginheight=0 marginwidth=0 src="https://downloads.kitenet.net/git-annex/autobuildtest/x86_64-apple-yosemite/testresult/status">
 </iframe>
 <h2><a href="https://qa.nest-initiative.org/view/msysGit/job/msysgit-git-annex-assistant-test/">Windows</a></h2>
-<a href="https://qa.nest-initiative.org/view/msysGit/job/msysgit-git-annex-assistant-test/">here</a>
+<a href="http://vps.zaytsev.net:8080/">here</a> (firewalled from most locations; kite can access it)
 <h2><a href="https://buildd.debian.org/status/package.php?p=git-annex&suite=sid">Debian</a></h2>
 <iframe width=1024 scrolling=no height=500px frameborder=0 marginheight=0 marginwidth=0 src="https://buildd.debian.org/status/package.php?p=git-annex&suite=sid">
 </iframe>

Added a comment: magic wormhole
diff --git a/doc/devblog/day_431__p2p_linking/comment_1_1d5f809564c25e765f82594af8e174ab._comment b/doc/devblog/day_431__p2p_linking/comment_1_1d5f809564c25e765f82594af8e174ab._comment
new file mode 100644
index 0000000..9eceb71
--- /dev/null
+++ b/doc/devblog/day_431__p2p_linking/comment_1_1d5f809564c25e765f82594af8e174ab._comment
@@ -0,0 +1,49 @@
+[[!comment format=mdwn
+ username="https://anarc.at/openid/"
+ nickname="anarcat"
+ avatar="http://cdn.libravatar.org/avatar/b36dcf65657dd36128161355d8920a99503def9461c1bb212410980fe6f07125"
+ subject="magic wormhole"
+ date="2016-11-30T22:16:19Z"
+ content="""
+> What I'd really like to have is an interface that displays a
+> one-time-use phrase of five to ten words, that can be read over the
+> phone or across the room. Exchange phrases with a friend, and get
+> your repositories securely linked together with tor.
+
+I already mentionned the project in [[design/assistant/telehash/]],
+but [magic-wormhole](https://github.com/warner/magic-wormhole) does
+exactly that:
+
+    % wormhole send README.md
+    Sending 7924 byte file named 'README.md'
+    On the other computer, please run: wormhole receive
+    Wormhole code is: 7-crossover-clockwork
+    
+    Sending (<-10.0.1.43:58988)..
+    100%|=========================| 7.92K/7.92K [00:00<00:00, 6.02MB/s]
+    File sent.. waiting for confirmation
+    Confirmation received. Transfer complete.
+
+Receiver:
+
+    % wormhole receive
+    Enter receive wormhole code: 7-crossover-clockwork
+    Receiving file (7924 bytes) into: README.md
+    ok? (y/n): y
+    Receiving (->tcp:10.0.1.43:58986)..
+    100%|===========================| 7.92K/7.92K [00:00<00:00, 120KB/s]
+    Received file written to README.md
+
+While that example shows a file transfer, arbitrary data can be
+transfered this way. There's a documented protocol, and it's not
+completely peer-to-peer: there are relay servers to deal with NAT'd
+machines. But the [PAKE
+protocol](https://en.wikipedia.org/wiki/Password-authenticated_key_agreement)
+(basically SPAKE2) could be a good inspiration here.
+
+Otherwise, I must say that, as a user, I don't mind copy-pasting a
+hidden service string (if that's what it's about): i can do that over
+a secure medium (email + OpenPGP or IM + OTR) easily... But I
+understand it can be difficult to do for new users.
+
+"""]]

diff --git a/doc/forum/Extra___38___missing_folders_on_remote.mdwn b/doc/forum/Extra___38___missing_folders_on_remote.mdwn
new file mode 100644
index 0000000..b78961c
--- /dev/null
+++ b/doc/forum/Extra___38___missing_folders_on_remote.mdwn
@@ -0,0 +1,9 @@
+I created a local annex directory that's an adjusted branch used with the assistant. On another machine, I initialized an annex directory, then made this into a full-backup ssh remote for my local.
+
+After the assistant pushes to the remote, and the remote runs `git annex sync`, the remote is missing some directories and has some extra directories. For example, it has the extra directory `Documents/programs/Documents/programs/`, which has different contents than `Documents/programs/`. Both directories are missing the subdirectory `graphing_experiments/`.
+
+From my local, `git annex whereis Documents/programs/graphing_experiments` says the directory exists on the remote. But it's not there.
+
+I recreated the remote from scratch and the problem persists.
+
+The assistant says the remote is caught up, and is keeping up with new content changes. What could cause this?

devblog
diff --git a/doc/devblog/day_431__p2p_linking.mdwn b/doc/devblog/day_431__p2p_linking.mdwn
new file mode 100644
index 0000000..1e53ffe
--- /dev/null
+++ b/doc/devblog/day_431__p2p_linking.mdwn
@@ -0,0 +1,27 @@
+Today I finished the second-to-last big missing peice for tor hidden service
+remotes. Networks of these remotes are P2P networks, and there needs to be
+a way for peers to find one-another, and to authenticate with one-another.
+The `git annex p2p` command sets up links between peers in such a network.
+
+So far it has only a basic interface that sets up a one way link between
+two peers. In the first repository, run `git annex p2p --gen-address`.
+That outputs a long address. In the second repository, run
+`git annex p2p --link peer1`, and paste the address into it. That sets up a
+git remote named "peer1" that connects back to the first repository over tor.
+
+That is a one-directional link, while a bi-directional link would be
+much more convenient to have between peers. Worse, the address can be reused by
+anyone who sees it, to link into the repository. And, the address is far
+too long to communicate in any way except for pasting it.
+
+So I want to improve that later. What I'd really like to have is an
+interface that displays a one-time-use phrase of five to ten words, that
+can be read over the phone or across the room. Exchange phrases with a
+friend, and get your repositories securely linked together with tor.
+
+But, `git annex p2p` is good enough for now. I can move on to the final
+keystone of the tor support, which is file transfer over tor.
+That should, fingers crossed, be relatively easy, and the `tor` branch is
+close to mergeable now.
+
+Today's work was sponsored by Riku Voipio.

diff --git a/doc/bugs/wget_always_shows_progress_bar.mdwn b/doc/bugs/wget_always_shows_progress_bar.mdwn
new file mode 100644
index 0000000..2829b39
--- /dev/null
+++ b/doc/bugs/wget_always_shows_progress_bar.mdwn
@@ -0,0 +1,24 @@
+### Please describe the problem.
+
+git annex addurl or importfeed operations were quiet on git-annex versions older than 5.20141219, if
+annex.web-options was set to "--quiet". But now the --show-progress option is always passed to wget.
+
+In some use cases this might be nice, but I'm using GNU Parallel to update multiple podcast feeds
+concurrently, and it causes wget to output the ugly "dot" indicator for every feed, which is totally
+useless since parallel buffers and groups the output. Adding "--no-show-progress" to web-options
+does not help (it does not override --show-progress), nor does redirecting stdout to /dev/null.
+Redirecting stderr would hide possible errors.
+
+### What steps will reproduce the problem?
+
+parallel git annex importfeed --relaxed --quiet ::: http://feeds.feedburner.com/freakonomicsradio
+
+### What version of git-annex are you using? On what operating system?
+
+5.20151208-1~bpo8+1 on Debian.
+
+### 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 love git annex and use it daily.
+
+

Remove obsolete link to Windows build logs
diff --git a/doc/install/Windows.mdwn b/doc/install/Windows.mdwn
index c9b60d6..1d9599a 100644
--- a/doc/install/Windows.mdwn
+++ b/doc/install/Windows.mdwn
@@ -24,7 +24,7 @@ important thing is that it should end with "All tests passed".
 A daily build is also available, thanks to Yury V. Zaytsev and
 Dartmouth College.
 
-* [download](https://downloads.kitenet.net/git-annex/autobuild/windows/) ([build logs](https://qa.nest-initiative.org/view/msysGit/job/msysgit-git-annex-assistant-test/))
+* [download](https://downloads.kitenet.net/git-annex/autobuild/windows/)
 
 ## building it yourself
 

prefer xdot over dot
* map: Run xdot if it's available in PATH. On OSX, the dot command
does not support graphical display, while xdot does.
* Debian: xdot is a better interactive viewer than dot, so Suggest
xdot, rather than graphviz.
diff --git a/CHANGELOG b/CHANGELOG
index 1e108d4..76da79e 100644
--- a/CHANGELOG
+++ b/CHANGELOG
@@ -4,6 +4,10 @@ git-annex (6.20161119) UNRELEASED; urgency=medium
     largerthan, mimetype, and smallerthan; the first two always failed
     to match, and the latter always matched.
   * Relicense 5 source files that are not part of the webapp from AGPL to GPL.
+  * map: Run xdot if it's available in PATH. On OSX, the dot command
+    does not support graphical display, while xdot does.
+  * Debian: xdot is a better interactive viewer than dot, so Suggest
+    xdot, rather than graphviz.
 
  -- Joey Hess <id@joeyh.name>  Mon, 21 Nov 2016 11:27:50 -0400
 
diff --git a/Command/Map.hs b/Command/Map.hs
index 2b21c40..43c00d2 100644
--- a/Command/Map.hs
+++ b/Command/Map.hs
@@ -47,15 +47,25 @@ start = do
 	liftIO $ writeFile file (drawMap rs trustmap umap)
 	next $ next $
 		ifM (Annex.getState Annex.fast)
-			( do
-				showLongNote $ "left map in " ++ file
-				return True
-			, do
-				showLongNote $ "running: dot -Tx11 " ++ file
-				showOutput
-				liftIO $ boolSystem "dot" [Param "-Tx11", File file]
+			( runViewer file []
+			, runViewer file
+	 			[ ("xdot", [File file])
+				, ("dot", [Param "-Tx11", File file])
+				]	
 			)
 
+runViewer :: FilePath -> [(String, [CommandParam])] -> Annex Bool
+runViewer file [] = do
+	showLongNote $ "left map in " ++ file
+	return True
+runViewer file ((c, ps):rest) = ifM (liftIO $ inPath c)
+	( do
+		showLongNote $ "running: " ++ c ++ unwords (toCommand ps)
+		showOutput
+		liftIO $ boolSystem c ps
+	, runViewer file rest
+	)
+
 {- Generates a graph for dot(1). Each repository, and any other uuids
  - (except for dead ones), are displayed as a node, and each of its
  - remotes is represented as an edge pointing at the node for the remote.
diff --git a/debian/control b/debian/control
index ec77a29..a077974 100644
--- a/debian/control
+++ b/debian/control
@@ -110,7 +110,7 @@ Recommends:
 	nocache,
 	aria2,
 Suggests:
-	graphviz,
+	xdot,
 	bup,
 	tahoe-lafs,
 	libnss-mdns,
diff --git a/doc/git-annex-map.mdwn b/doc/git-annex-map.mdwn
index cf28a95..ece26b3 100644
--- a/doc/git-annex-map.mdwn
+++ b/doc/git-annex-map.mdwn
@@ -10,8 +10,8 @@ git annex map
 
 Helps you keep track of your repositories, and the connections between them,
 by going out and looking at all the ones it can get to, and generating a
-Graphviz file displaying it all. If the `dot` command is available, it is
-used to display the file to your screen (using x11 backend).
+Graphviz file displaying it all. If the `xdot` or `dot` command is available,
+it is used to display the file to your screen.
   
 This command only connects to hosts that the host it's run on can
 directly connect to. It does not try to tunnel through intermediate hosts.
@@ -37,7 +37,7 @@ on that host.
 
 * `--fast`
 
-  Disable using `dot` to display the generated Graphviz file.
+  Don't display the generated Graphviz file, but save it for later use.
 
 # SEE ALSO
 

devblog
diff --git a/doc/devblog/day_430__tor_socket_problem.mdwn b/doc/devblog/day_430__tor_socket_problem.mdwn
new file mode 100644
index 0000000..7e7c8d1
--- /dev/null
+++ b/doc/devblog/day_430__tor_socket_problem.mdwn
@@ -0,0 +1,13 @@
+Debian's tor daemon is very locked down in the directories it can read
+from, and so I've had a hard time finding a place to put the unix socket
+file for git-annex's tor hidden service. Painful details in 
+<http://bugs.debian.org/846275>. At least for now, I'm putting it under
+/etc/tor/, which is probably a FHS violation, but seems to be the only
+option that doesn't involve a lot of added complexity.
+
+--- 
+
+The Windows autobuilder is moving, since
+[NEST](http://nest-initiative.org/) is shutting down the server it has been
+using. Yury Zaytsev has set up a new Windows autobuilder, hosted at
+Dartmouth College this time.

tighten added language
Removed part about neeing to install git-annex and git in the same
location. The installer checks if the location given exists, and if not,
tells the user that git is not installed there. And the default should
work if the user just picks it in both installers.
diff --git a/doc/install/Windows.mdwn b/doc/install/Windows.mdwn
index ff6a6ad..c9b60d6 100644
--- a/doc/install/Windows.mdwn
+++ b/doc/install/Windows.mdwn
@@ -1,13 +1,13 @@
 git-annex now does Windows!
 
-* First, [install Git for Windows](http://git-scm.com/downloads)  
+* First, [install Git for Windows](http://git-scm.com/downloads)
+
   Important: **Get the 32 bit version not the 64 bit version.**  
-  (Note that msysgit is no longer supported.) If you installed the
-  64 bit version of git, then parts of git-annex will still run,
-  however, some features, including tools like rsync, are not-functional.
+  If you installed the 64 bit version of git, then parts of git-annex will
+  still run, however, some features, including tools like rsync, will
+  not work.
+
 * Then, [install git-annex](https://downloads.kitenet.net/git-annex/windows/current/)
-  into the same location Git has been installed to. You must provide this path to the
-  git-annex installer. For instance, the path may be "C:\Users\John\AppData\Local\Programs\Git\"
 
 This port is now in reasonably good shape for command-line use of
 git-annex. The assistant and webapp are also usable. There are some known

Revert "Added link to Windows installation instructions. The page was not easy to find."
This reverts commit c68d4305eb016e026d655dff7c7cb96cbb8296ea.
With all due respect, the link to the instructions for each OS is in the
"detailed instructions" column. Adding a second link to the same thing
is unlikely to help.
diff --git a/doc/install.mdwn b/doc/install.mdwn
index 2104931..dccd9e5 100644
--- a/doc/install.mdwn
+++ b/doc/install.mdwn
@@ -17,7 +17,7 @@ detailed instructions             | quick install
 &nbsp;&nbsp;[[ScientificLinux5]]  |
 &nbsp;&nbsp;[[openSUSE]]          | `zypper in git-annex`
 &nbsp;&nbsp;[[Docker]]            | 
-[[Windows]]                       | [download installer](https://downloads.kitenet.net/git-annex/windows/current/) and follow the [instructions here](http://git-annex.branchable.com/install/Windows/) **beta**
+[[Windows]]                       | [download installer](https://downloads.kitenet.net/git-annex/windows/current/) **beta**
 """]]
 
 All the download links above use https for security. For added security, see

Merge branch 'master' of ssh://git-annex.branchable.com
Windows autobuilder is going to be hosted at Dartmouth now
diff --git a/doc/install/OSX.mdwn b/doc/install/OSX.mdwn
index 10fc8ba..082fd51 100644
--- a/doc/install/OSX.mdwn
+++ b/doc/install/OSX.mdwn
@@ -18,7 +18,7 @@ several more. Handy if you don't otherwise have git installed.
 
 ## autobuilds
 
-Thanks to Dartmouth for hosting the autobuilder.
+Thanks to Dartmouth College for hosting the autobuilder.
 
 * [autobuild of git-annex.dmg](https://downloads.kitenet.net/git-annex/autobuild/x86_64-apple-yosemite/git-annex.dmg) ([build logs](https://downloads.kitenet.net/git-annex/autobuild/x86_64-apple-yosemite/))
 
diff --git a/doc/install/Windows.mdwn b/doc/install/Windows.mdwn
index 7ea667a..f079bf8 100644
--- a/doc/install/Windows.mdwn
+++ b/doc/install/Windows.mdwn
@@ -18,7 +18,7 @@ important thing is that it should end with "All tests passed".
 ## autobuilds
 
 A daily build is also available, thanks to Yury V. Zaytsev and
-[NEST](http://nest-initiative.org/).
+Dartmouth College.
 
 * [download](https://downloads.kitenet.net/git-annex/autobuild/windows/) ([build logs](https://qa.nest-initiative.org/view/msysGit/job/msysgit-git-annex-assistant-test/))
 

Added more explanations of my experience with the Windows install process.
diff --git a/doc/install/Windows.mdwn b/doc/install/Windows.mdwn
index 7ea667a..00ef702 100644
--- a/doc/install/Windows.mdwn
+++ b/doc/install/Windows.mdwn
@@ -2,8 +2,12 @@ git-annex now does Windows!
 
 * First, [install Git for Windows](http://git-scm.com/downloads)  
   Important: **Get the 32 bit version not the 64 bit version.**  
-  (Note that msysgit is no longer supported.)
+  (Note that msysgit is no longer supported.) If you installed the
+  64 bit version of git, then parts of git-annex will still run,
+  however, some features, including tools like rsync, are not-functional.
 * Then, [install git-annex](https://downloads.kitenet.net/git-annex/windows/current/)
+  into the same location Git has been installed to. You must provide this path to the
+  git-annex installer. For instance, the path may be "C:\Users\John\AppData\Local\Programs\Git\"
 
 This port is now in reasonably good shape for command-line use of
 git-annex. The assistant and webapp are also usable. There are some known

Added link to Windows installation instructions. The page was not easy to find.
diff --git a/doc/install.mdwn b/doc/install.mdwn
index dccd9e5..2104931 100644
--- a/doc/install.mdwn
+++ b/doc/install.mdwn
@@ -17,7 +17,7 @@ detailed instructions             | quick install
 &nbsp;&nbsp;[[ScientificLinux5]]  |
 &nbsp;&nbsp;[[openSUSE]]          | `zypper in git-annex`
 &nbsp;&nbsp;[[Docker]]            | 
-[[Windows]]                       | [download installer](https://downloads.kitenet.net/git-annex/windows/current/) **beta**
+[[Windows]]                       | [download installer](https://downloads.kitenet.net/git-annex/windows/current/) and follow the [instructions here](http://git-annex.branchable.com/install/Windows/) **beta**
 """]]
 
 All the download links above use https for security. For added security, see

diff --git a/doc/bugs/git-annex_fromkey_barfs_on_utf-8_input.mdwn b/doc/bugs/git-annex_fromkey_barfs_on_utf-8_input.mdwn
new file mode 100644
index 0000000..c1f7178
--- /dev/null
+++ b/doc/bugs/git-annex_fromkey_barfs_on_utf-8_input.mdwn
@@ -0,0 +1,34 @@
+### Please describe the problem.
+
+I'm sending a stream of keys and filenames to git-annex fromkey on stdin, and it errors out with "git-annex: <stdin>: hGetContents: invalid argument (invalid byte sequence)". On the other hand yipdw tried to reproduce this and it worked fine for him, so I must be doing something wrong.
+
+I have LANG=en_US.UTF-8 set in my environment, if that matters.
+
+### What steps will reproduce the problem?
+
+[[!format sh """
+echo "MD5-s3263532--0b4d070eff7baa8ef314ca330aecb71f é" | git-annex fromkey
+"""]]
+
+### What version of git-annex are you using? On what operating system?
+
+[[!format sh """
+git-annex version: 6.20161118-g0a34f08
+build flags: Assistant Webapp Pairing Testsuite S3(multipartupload)(storageclasses) WebDAV Inotify DBus DesktopNotify XMPP ConcurrentOutput TorrentParser MagicMime Feeds Quvi
+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 SHA1E SHA1 MD5E MD5 WORM URL
+remote types: git gcrypt S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external
+local repository version: 5
+supported repository versions: 3 5 6
+upgrade supported from repository versions: 0 1 2 3 4 5
+operating system: linux x86_64
+"""]]
+
+### Please provide any additional information below.
+
+Note that this is indeed valid utf-8:
+
+[[!format sh """
+ db48x  ~  projects  IA.BAK-server  echo "é" | hexdump -C
+00000000  c3 a9 0a                                          |...|
+00000003
+"""]]

Added a comment: Temporary workaround until the brew formula is updated
diff --git a/doc/bugs/regression_due_to_usage_of_ssh_7.3___34__include__34___feature/comment_1_45003ab569c4649ca29c07877a83af29._comment b/doc/bugs/regression_due_to_usage_of_ssh_7.3___34__include__34___feature/comment_1_45003ab569c4649ca29c07877a83af29._comment
new file mode 100644
index 0000000..566926a
--- /dev/null
+++ b/doc/bugs/regression_due_to_usage_of_ssh_7.3___34__include__34___feature/comment_1_45003ab569c4649ca29c07877a83af29._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="palday@91f366b5178879146d2b6e1e53bfa21389ee89a8"
+ nickname="palday"
+ avatar="http://cdn.libravatar.org/avatar/077a63af75ddba159980fbf88690f401"
+ subject="Temporary workaround until the brew formula is updated"
+ date="2016-11-29T02:17:52Z"
+ content="""
+The homebrew formula doesn't yet this fix, but you can get around the problem in the meantime by getting a newer SSH via homebrew:
+
+```
+brew install homebrew/dupes/openssh
+```
+
+You can then choose to keep that or get rid of it when the formula for git annex is later updated.
+"""]]

Added a comment
diff --git a/doc/bugs/cabal_constraints_for_aws_and_esqueleto/comment_1_d91e44573ef4a0ec6e7098cb4cd360f5._comment b/doc/bugs/cabal_constraints_for_aws_and_esqueleto/comment_1_d91e44573ef4a0ec6e7098cb4cd360f5._comment
new file mode 100644
index 0000000..327b634
--- /dev/null
+++ b/doc/bugs/cabal_constraints_for_aws_and_esqueleto/comment_1_d91e44573ef4a0ec6e7098cb4cd360f5._comment
@@ -0,0 +1,30 @@
+[[!comment format=mdwn
+ username="https://launchpad.net/~felixonmars"
+ nickname="felixonmars"
+ avatar="http://cdn.libravatar.org/avatar/17284a3bb2e4ad9d3be8fab31f49865be9c1dc22143c728de731fe800a335d38"
+ subject="comment 1"
+ date="2016-11-28T04:17:12Z"
+ content="""
+aws has merged a PR to support http-conduit 2.2, but git-annex itself doesn't build with the new component yet:
+
+```
+[ 95 of 544] Compiling Utility.Url      ( Utility/Url.hs, dist/build/git-annex/git-annex-tmp/Utility/Url.o )
+
+Utility/Url.hs:354:34: error:
+    * The constructor `StatusCodeException' should have 2 arguments, but has been given 3
+    * In the pattern: StatusCodeException s _ _
+      In an equation for `matchStatusCodeException':
+          matchStatusCodeException want e@(StatusCodeException s _ _)
+            | want s = Just e
+            | otherwise = Nothing
+
+Utility/Url.hs:354:34: error:
+    * Couldn't match expected type `HttpException'
+                  with actual type `HttpExceptionContent'
+    * In the pattern: StatusCodeException s _ _
+      In an equation for `matchStatusCodeException':
+          matchStatusCodeException want e@(StatusCodeException s _ _)
+            | want s = Just e
+            | otherwise = Nothing
+```
+"""]]

removed
diff --git a/doc/bugs/cabal_constraints_for_aws_and_esqueleto/comment_1_ada25b56fe50225e518a46cb38247483._comment b/doc/bugs/cabal_constraints_for_aws_and_esqueleto/comment_1_ada25b56fe50225e518a46cb38247483._comment
deleted file mode 100644
index ced3a97..0000000
--- a/doc/bugs/cabal_constraints_for_aws_and_esqueleto/comment_1_ada25b56fe50225e518a46cb38247483._comment
+++ /dev/null
@@ -1,28 +0,0 @@
-[[!comment format=mdwn
- username="https://launchpad.net/~felixonmars"
- nickname="felixonmars"
- avatar="http://cdn.libravatar.org/avatar/17284a3bb2e4ad9d3be8fab31f49865be9c1dc22143c728de731fe800a335d38"
- subject="comment 1"
- date="2016-11-28T04:12:18Z"
- content="""
-aws has merged a PR to support http-conduit 2.2, but git-annex itself doesn't build with the new component yet:
-
-[ 95 of 544] Compiling Utility.Url      ( Utility/Url.hs, dist/build/git-annex/git-annex-tmp/Utility/Url.o )
-
-Utility/Url.hs:354:34: error:
-    * The constructor `StatusCodeException' should have 2 arguments, but has been given 3
-    * In the pattern: StatusCodeException s _ _
-      In an equation for `matchStatusCodeException':
-          matchStatusCodeException want e@(StatusCodeException s _ _)
-            | want s = Just e
-            | otherwise = Nothing
-
-Utility/Url.hs:354:34: error:
-    * Couldn't match expected type `HttpException'
-                  with actual type `HttpExceptionContent'
-    * In the pattern: StatusCodeException s _ _
-      In an equation for `matchStatusCodeException':
-          matchStatusCodeException want e@(StatusCodeException s _ _)
-            | want s = Just e
-            | otherwise = Nothing
-"""]]

Added a comment
diff --git a/doc/bugs/cabal_constraints_for_aws_and_esqueleto/comment_1_ada25b56fe50225e518a46cb38247483._comment b/doc/bugs/cabal_constraints_for_aws_and_esqueleto/comment_1_ada25b56fe50225e518a46cb38247483._comment
new file mode 100644
index 0000000..ced3a97
--- /dev/null
+++ b/doc/bugs/cabal_constraints_for_aws_and_esqueleto/comment_1_ada25b56fe50225e518a46cb38247483._comment
@@ -0,0 +1,28 @@
+[[!comment format=mdwn
+ username="https://launchpad.net/~felixonmars"
+ nickname="felixonmars"
+ avatar="http://cdn.libravatar.org/avatar/17284a3bb2e4ad9d3be8fab31f49865be9c1dc22143c728de731fe800a335d38"
+ subject="comment 1"
+ date="2016-11-28T04:12:18Z"
+ content="""
+aws has merged a PR to support http-conduit 2.2, but git-annex itself doesn't build with the new component yet:
+
+[ 95 of 544] Compiling Utility.Url      ( Utility/Url.hs, dist/build/git-annex/git-annex-tmp/Utility/Url.o )
+
+Utility/Url.hs:354:34: error:
+    * The constructor `StatusCodeException' should have 2 arguments, but has been given 3
+    * In the pattern: StatusCodeException s _ _
+      In an equation for `matchStatusCodeException':
+          matchStatusCodeException want e@(StatusCodeException s _ _)
+            | want s = Just e
+            | otherwise = Nothing
+
+Utility/Url.hs:354:34: error:
+    * Couldn't match expected type `HttpException'
+                  with actual type `HttpExceptionContent'
+    * In the pattern: StatusCodeException s _ _
+      In an equation for `matchStatusCodeException':
+          matchStatusCodeException want e@(StatusCodeException s _ _)
+            | want s = Just e
+            | otherwise = Nothing
+"""]]

diff --git a/doc/forum/Preserving_Directories_in_Metadata_Views.mdwn b/doc/forum/Preserving_Directories_in_Metadata_Views.mdwn
new file mode 100644
index 0000000..dfc45cb
--- /dev/null
+++ b/doc/forum/Preserving_Directories_in_Metadata_Views.mdwn
@@ -0,0 +1,47 @@
+I want to use metadata views to sort files into top-level directories based on a tag, but then preserve the directory structure underneath that. I'm having trouble with this.
+
+Say I have an annex at `~/annex` with a structure like this:
+
+    $ tree
+    .
+    ├── foo
+    │   └── bar
+    │       ├── one.txt
+    │       ├── three.txt
+    │       └── two.txt
+    └── waldo
+        └── fred
+            ├── a.txt
+            ├── b.txt
+            └── c.txt
+
+I tag some of the files with `blah`:
+
+    $ git annex metadata -t blah foo/bar/*
+
+Now I want to change my view to only see those files with a certain tag, but I want to maintain their directory structure, ie I want to end up with something like this:
+
+    $ tree
+    .
+    ├── blah
+    │   └── foo
+    │       └── bar
+    │           ├── one.txt
+    │           ├── three.txt
+    │           └── two.txt
+
+If I do `git annex view blah` I see the files `one.txt`, `two.txt` and `three.txt` but they are in the top level of `~/annex`. The `foo` and `bar` directories are not present.
+
+If I do `git annex view blah "/=*"` then the files I present under the `foo` directory, but the `bar` subdirectory is not there.
+
+It would also be fine if I could just hide the files that did not have the `blah` tag, so that I ended up with this:
+
+    $ tree
+    .
+    ├── foo
+    │   └── bar
+    │       ├── one.txt
+    │       ├── three.txt
+    │       └── two.txt
+
+Is something like this possible?

Added a comment
diff --git a/doc/bugs/Assistant_drops_files_from_remote_repos_that_it_shouldn__39__t/comment_9_c46cdba62da4f5ccfdc42dfc33aec600._comment b/doc/bugs/Assistant_drops_files_from_remote_repos_that_it_shouldn__39__t/comment_9_c46cdba62da4f5ccfdc42dfc33aec600._comment
new file mode 100644
index 0000000..a6a2397
--- /dev/null
+++ b/doc/bugs/Assistant_drops_files_from_remote_repos_that_it_shouldn__39__t/comment_9_c46cdba62da4f5ccfdc42dfc33aec600._comment
@@ -0,0 +1,34 @@
+[[!comment format=mdwn
+ username="boh"
+ avatar="http://cdn.libravatar.org/avatar/e7fa2d1c5d95e323fe48887f7f827b1f"
+ subject="comment 9"
+ date="2016-11-27T12:23:20Z"
+ content="""
+Seems as if the problem still exists in 6.20161118 (Debian).
+
+I have three repositories (among others), `jolla`, `sts-3xx`, and `here`.  `jolla` and `here` are in group `manual`, `sts-3xx` is `backup`; `here` and `sts-3xx` have assistants running, `jolla` not.  `jolla` and `sts-3xx` have slightly older versions of git-annex installed.
+
+Now, when I copy a file from `here` to `jolla` like this
+
+    git annex copy real_programmers.png -t jolla
+
+the file is subsequently dropped by the assistant:
+
+```
+drop real_programmers.png (locking jolla...) [2016-11-27 13:00:02.667376556] chat: ssh [\"-S\",\".git/annex/ssh/jolla\",\"-o\",\"ControlMaster
+=auto\",\"-o\",\"ControlPersist=yes\",\"-F\",\".git/annex/ssh.config\",\"-T\",\"jolla\",\"git-annex-shell 'lockcontent' '/~/Music/media/' '--debug' '
+SHA256E-s84499--ff98a733cc0122858fb11433c720e2d038fec190a3d36380d0e7e8dab468f883.png' --uuid 5298e3ce-1106-4d5e-b052-0aee4b27a344\"]
+(locking sts-3xx...) [2016-11-27 13:00:03.252473676] chat: ssh [..., \"git-annex-shell 'lockcontent' '/backups/exot/media/' '--debug' 'SHA256E-s84499--ff98a733cc0122858fb11433c720e2d038fec190a3d 36380d0e7e8dab468f883.png' --uuid 1fec6253-171d-4f86-885b-e233be2d65ec\"]
+(lockcontent failed) [2016-11-27 13:00:03.486158016] process done ExitFailure 1
+(checking sts-3xx...) [2016-11-27 13:00:03.487047149] call: ssh [..., \"git-annex-shell 'inannex' '/backups/exot/media/' '--debug' 'SHA256E-s84499--ff98a733cc0122858fb11433c720e2d038fec190a3d363 80d0e7e8dab468f883.png' --uuid 1fec6253-171d-4f86-885b-e233be2d65ec\"]
+[2016-11-27 13:00:03.76435136] process done ExitSuccess
+[2016-11-27 13:00:03.764705754] Dropping from here proof: Just (SafeDropProof (NumCopies 2) [RecentlyVerifiedCopy UUID \"1fec6253-171d-4 f86-885b-e233be2d65ec\",LockedCopy UUID \"5298e3ce-1106-4d5e-b052-0aee4b27a344\"] (Just (ContentRemovalLock (Key {keyName = \"ff98a733cc012 2858fb11433c720e2d038fec190a3d36380d0e7e8dab468f883.png\", keyBackendName = \"SHA256E\", keySize = Just 84499, keyMtime = Nothing, keyChun kSize = Nothing, keyChunkNum = Nothing}))))
+[2016-11-27 13:00:04.24333081] process done ExitFailure 1
+ok
+[2016-11-27 13:00:04.251232455] dropped real_programmers.png (from here) (copies now 4) : drop wanted after Upload UUID \"5298e3ce-1106- 4d5e-b052-0aee4b27a344\" real_programmers.png Just 84499
+```
+
+However, I failed to reproduce the problem by replicating my setup with fresh repositories …
+
+Please let me know if you need more information, and *so* many thanks for git-annex!
+"""]]

Added a comment
diff --git a/doc/bugs/addurl_pathdepth_description_misleading/comment_4_2a9eb14a8c6d06747bb5dda7ff179ec7._comment b/doc/bugs/addurl_pathdepth_description_misleading/comment_4_2a9eb14a8c6d06747bb5dda7ff179ec7._comment
new file mode 100644
index 0000000..0cafc2a
--- /dev/null
+++ b/doc/bugs/addurl_pathdepth_description_misleading/comment_4_2a9eb14a8c6d06747bb5dda7ff179ec7._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="CandyAngel"
+ avatar="http://cdn.libravatar.org/avatar/15c0aade8bec5bf004f939dd73cf9ed8"
+ subject="comment 4"
+ date="2016-11-25T20:27:07Z"
+ content="""
+I really don't know what to say. I can't even figure out which computer I updated git-annex on to test if it was still happening.. let alone reproduce it anymore. It does work fine.
+
+I'm so sorry to bother you with this, I've done something stupid! This is exactly why you ask for a transcript of bugs occurring. (Feel free to use this as an example for why you ask for them, so some good can come of it at least..).
+"""]]

diff --git a/doc/forum/Git-annex_link_to_different_file_names.mdwn b/doc/forum/Git-annex_link_to_different_file_names.mdwn
index f6ce011..a7a7c27 100644
--- a/doc/forum/Git-annex_link_to_different_file_names.mdwn
+++ b/doc/forum/Git-annex_link_to_different_file_names.mdwn
@@ -24,17 +24,17 @@ And
 
 The git-annex's drawing.pdf would have an history like this :
 
-[shop]
-|
-Commit A "Initial shop drawing"
-|
-Commit B "Add corrections from Wizzbasket"
- \
-  |
-  [asbuilt]
-  Commit C "Reflect as built"
-  |
-  Commit D "Change dweezelbox block for simplicity"
+    [shop]
+    |
+    Commit A "Initial shop drawing"
+    |
+    Commit B "Add corrections from Wizzbasket"
+     \
+      |
+      [asbuilt]
+      Commit C "Reflect as built"
+      |
+      Commit D "Change dweezelbox block for simplicity"
 
 But somehow the "managed by coworkers" repo would be a direct mode repo with Commit A pointing to drawing_shop_12_nov_2015.pdf, Commit B to drawing_shop_13_nov_2015.pdf etc.
 

diff --git a/doc/forum/Git-annex_link_to_different_file_names.mdwn b/doc/forum/Git-annex_link_to_different_file_names.mdwn
new file mode 100644
index 0000000..f6ce011
--- /dev/null
+++ b/doc/forum/Git-annex_link_to_different_file_names.mdwn
@@ -0,0 +1,41 @@
+This is a recreation of a stackexchange question, in case the community here is more knowledgeable.
+
+Link to stackexchange question : http://unix.stackexchange.com/questions/325753/git-annex-link-to-different-file-names
+
+Content :
+"Maybe this is just a crazy use case that doesn't work, but I was wondering if there's a way to build a file's history from files with different file names. I'm exploring this idea because I'd like to have a git-annex system but I can't force my coworkers to adapt.
+
+Here's what I have in mind :
+
+    Folder 1, managed by coworkers (On a shared disk) :
+
+        drawing_shop_12_nov_2015.pdf
+        drawing_shop_13_nov_2015.pdf
+        drawing_asbuilt_14_nov_2015.pdf
+        drawing_asbuilt_rev1_15_nov_2015.pdf
+
+And
+
+    Git-annex, managed by me :
+
+        drawing.pdf
+
+    (with a shop branch and a asbuilt branch)
+
+The git-annex's drawing.pdf would have an history like this :
+
+[shop]
+|
+Commit A "Initial shop drawing"
+|
+Commit B "Add corrections from Wizzbasket"
+ \
+  |
+  [asbuilt]
+  Commit C "Reflect as built"
+  |
+  Commit D "Change dweezelbox block for simplicity"
+
+But somehow the "managed by coworkers" repo would be a direct mode repo with Commit A pointing to drawing_shop_12_nov_2015.pdf, Commit B to drawing_shop_13_nov_2015.pdf etc.
+
+Can this be done?"

Added a comment: Sharing rsync special remote between repository
diff --git a/doc/special_remotes/rsync/comment_14_2261b1b7441eff9e28ec8e1f98d77980._comment b/doc/special_remotes/rsync/comment_14_2261b1b7441eff9e28ec8e1f98d77980._comment
new file mode 100644
index 0000000..4d6f0cf
--- /dev/null
+++ b/doc/special_remotes/rsync/comment_14_2261b1b7441eff9e28ec8e1f98d77980._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="davidriod@e75b369a4b1cced29c14354bce7493c61f00b1c7"
+ nickname="davidriod"
+ avatar="http://cdn.libravatar.org/avatar/d6e327bd88b88802d6f0c20c83f682a2"
+ subject="Sharing rsync special remote between repository"
+ date="2016-11-24T19:23:42Z"
+ content="""
+I was wondering if it is possible to share a rsync special remote between repository which are not parented in any way. The use case would be that even if these repositories are not related at all they still may contains the same binary file. It would be useful to have a single rsync remote in order to reduce space usage. I think it could work as the object names are based on their checksum, but I wonder if anyone has already try that ?
+"""]]

Added a comment: Walkthrough of a prudent retroactive annex.
diff --git a/doc/tips/How_to_retroactively_annex_a_file_already_in_a_git_repo/comment_8_834410421ccede5194bd8fbaccea8d1a._comment b/doc/tips/How_to_retroactively_annex_a_file_already_in_a_git_repo/comment_8_834410421ccede5194bd8fbaccea8d1a._comment
new file mode 100644
index 0000000..2c36962
--- /dev/null
+++ b/doc/tips/How_to_retroactively_annex_a_file_already_in_a_git_repo/comment_8_834410421ccede5194bd8fbaccea8d1a._comment
@@ -0,0 +1,82 @@
+[[!comment format=mdwn
+ username="StephaneGourichon"
+ avatar="http://cdn.libravatar.org/avatar/8cea01af2c7a8bf529d0a3d918ed4abf"
+ subject="Walkthrough of a prudent retroactive annex."
+ date="2016-11-24T11:27:59Z"
+ content="""
+Been using the one-liner.  Despite the warning, I'm not dead yet.
+
+There's much more to do than the one-liner.
+
+This post offers instructions.
+
+# First simple try: slow
+
+Was slow (estimated >600s for 189 commits).
+
+# In tmpfs: about 6 times faster
+
+I have cloned repository into /run/user/1000/rewrite-git, which is a tmpfs mount point. (Machine has plenty of RAM.)
+
+There I also did `git annex init`, git-annex found its state branches.
+
+On second try I also did 
+
+    git checkout -t remotes/origin/synced/master
+
+So that filter-branch would clean that, too.
+
+There, `filter-branch` operation finished in 90s first try, 149s second try.
+
+`.git/objects` wasn't smaller.
+
+# Practicing reduction on clone
+
+This produced no visible benefit:
+
+time git gc --aggressive
+time git repack -a -d 
+
+Even cloning and retrying on clone. Oh, but I should have done `git clone file:///path` as said on git-filter-branch man page's section titled \"CHECKLIST FOR SHRINKING A REPOSITORY\" 
+
+This (as seen on https://rtyley.github.io/bfg-repo-cleaner/ ) was efficient:
+
+    git reflog expire --expire=now --all && git gc --prune=now --aggressive
+
+`.git/objects` shrunk from 148M to 58M
+
+All this was on a clone of the repo in tmpfs.
+
+# Propagating cleaned up branches to origin
+
+This confirmed that filter-branch did not change last tree:
+
+    git diff remotes/origin/master..master
+    git diff remotes/origin/synced/master synced/master
+
+This, expectedly, was refused:
+
+    git push origin master
+    git push origin synced/master
+
+On origin, I checked out the hash of current master, then on tmpfs clone
+
+    git push -f origin master
+    git push -f origin synced/master
+
+Looks good.
+
+I'm not doing the aggressive shrink now, because of the \"two orders of magnitude more caution than normal filter-branch\" recommended by arand.
+
+# Now what? Check if precious not broken
+
+I'm planning to do the same operation on the other repos, then :
+
+* if everything seems right, 
+* if `git annex sync` works between all those fellows
+* etc, 
+* then I would perform the reflog expire, gc prune on some then all of them, etc.
+
+Joey, does this seem okay?  Any comment?
+
+"""]]

Added a comment: IgnoreUnknown Include considered harmful?
diff --git a/doc/bugs/git_annex_init_failed_due_to_unsupported_ssh_option/comment_2_32e142afd9fe65843d53883ba2ae48cb._comment b/doc/bugs/git_annex_init_failed_due_to_unsupported_ssh_option/comment_2_32e142afd9fe65843d53883ba2ae48cb._comment
new file mode 100644
index 0000000..42550d5
--- /dev/null
+++ b/doc/bugs/git_annex_init_failed_due_to_unsupported_ssh_option/comment_2_32e142afd9fe65843d53883ba2ae48cb._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="scottgorlin@a32946b2aad278883c1690a0753241583a9855b9"
+ nickname="scottgorlin"
+ avatar="http://cdn.libravatar.org/avatar/2dd1fc8add62bbf4ffefac081b322563"
+ subject="IgnoreUnknown Include considered harmful?"
+ date="2016-11-23T20:07:45Z"
+ content="""
+As noted, include appears to not work on a mac at the moment.  This means git-annex silently ignores the included configs, which may be required to ssh to the remotes of interest.  This is happening to me.
+
+My understanding is that ssh aliases are the recommended way of juggling multiple private keys amongst multiple hosts, so it is a required part of many git workflows.  In this particular case, I have set up git annex on a NAS which does not allow multiple ssh users (QNAP) and the authentication is done only via key identity, not username.  Thus, host aliases are necessary.
+
+If one config can't include another, I would prefer an early failure indicating a problem with the config file, or better, a solution where git-annex doesn't require a config.  In this scenario, git fetch remote_name and git annex copy --to remotename do not resolve to the same alias definitions (the latter is missing because of the ignored config!).
+
+I got my setup to work only by finding and manually editing <repo>/.git/annex/ssh_config, which to my knowledge is undocumented (ie when is it written? do any commands change it?); manual mucking around inside .git to me is not a good practice, and for now I have two different alias's defined (in repo and in ~/.ssh/config)
+
+
+"""]]

Added a comment: Known bug, fixed.
diff --git a/doc/bugs/Single_space_in_file_name_causes_git_annex_add_to_fail/comment_2_13c242250d1509d933b8f0bcb7b67302._comment b/doc/bugs/Single_space_in_file_name_causes_git_annex_add_to_fail/comment_2_13c242250d1509d933b8f0bcb7b67302._comment
new file mode 100644
index 0000000..bf41d40
--- /dev/null
+++ b/doc/bugs/Single_space_in_file_name_causes_git_annex_add_to_fail/comment_2_13c242250d1509d933b8f0bcb7b67302._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="https://launchpad.net/~stephane-gourichon-lpad"
+ nickname="stephane-gourichon-lpad"
+ avatar="http://cdn.libravatar.org/avatar/02d4a0af59175f9123720b4481d55a769ba954e20f6dd9b2792217d9fa0c6089"
+ subject="Known bug, fixed."
+ date="2016-11-23T18:04:27Z"
+ content="""
+This is a known bug introduced in 6.20161012 and fixed in 6.20161031.
+
+Solution is: just update your copy of git-annex. At this time most recent is 6.20161119 .
+
+For more details, see changelog at https://github.com/joeyh/git-annex/blob/master/CHANGELOG#L53
+
+
+
+"""]]

diff --git a/doc/forum/two-way_assistant_sync_with_ssh_special_remote.mdwn b/doc/forum/two-way_assistant_sync_with_ssh_special_remote.mdwn
index 749a793..ca04e44 100644
--- a/doc/forum/two-way_assistant_sync_with_ssh_special_remote.mdwn
+++ b/doc/forum/two-way_assistant_sync_with_ssh_special_remote.mdwn
@@ -1,20 +1,22 @@
 I am attempting to set up automatic two-way synchronization between my laptop and a server via ssh by running assistant on both machines. I want to have both machines be non-bare and unlocked.
 
-On the server:
+On the rhel server:
 
     $ mkdir ~/annex
-    $ cd annex
+    $ cd ~/annex
     $ git init
     $ git annex init u --version=6
     $ echo This is test file 1. >testfile1.txt
     $ git annex add testfile1.txt
     $ git annex sync
+    $ git remote add ml2 ssh://laptop/Users/username/annex
     $ git annex adjust --unlock
     $ git annex wanted . standard
     $ git annex group . client
 
-On my laptop:
+On my mac laptop:
 
+    $ cd ~/
     $ git clone ssh://server/home/username/annex
     $ cd annex
     $ git annex init ml2 --version=6
@@ -23,8 +25,8 @@ On my laptop:
     $ git annex wanted . standard
     $ git annex group . client
 
-Everything seems to work when I manually sync. When I run
+Everything seems to work when I manually sync. But when I run
 
     $ git annex assistant
 
-on both machines, however, I only get one-way automatic synchronization. Changes on the laptop are immediately propagated to the server. But changes on the server do not show up on the laptop until I manually sync. What am I doing wrong?
+on both machines, I only get one-way automatic synchronization. Changes on the laptop are immediately propagated to the server. But changes on the server do not show up on the laptop until I manually sync. What am I doing wrong?

diff --git a/doc/bugs/Inconsistent_results_between_git-annex-fsck_and_git-annex-whereis.mdwn b/doc/bugs/Inconsistent_results_between_git-annex-fsck_and_git-annex-whereis.mdwn
new file mode 100644
index 0000000..c9037b5
--- /dev/null
+++ b/doc/bugs/Inconsistent_results_between_git-annex-fsck_and_git-annex-whereis.mdwn
@@ -0,0 +1,53 @@
+### Please describe the problem.
+
+I'm seeing some inconsistent results between runs of `git annex fsck` and `git annex whereis` that I'm not able to explain. When I run `git annex fsck`, it reports a few keys that only have 1 copy, and advises me to make more copies. If I run `git annex whereis --key <key>`, git annex confirms that it only knows about 1 copy of this key. If I then use `git log --stat -S'<key>'` to find the actual file that it refers to, and run `git annex whereis <file>`, git annex report 9 copies of this file. Checking on remotes shows that these files do exist on the remote, so why does `git annex fsck` and `git annex whereis` mis-report the number of copies when querying for the key - but not for the actual filename? Additionally, `git annex find --lackingcopies 1` doesn't return any results, but should if there are actually files with not enough copies?
+
+
+### What steps will reproduce the problem?
+
+
+### What version of git-annex are you using? On what operating system?
+
+5.20151208-1build1 on Ubuntu Xenial, one remote running 5.20141024~bpo70+1 on Debian Wheezy
+
+### 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
+
+[william@hactar ~/Pictures/Photo Library]$ git annex whereis SHA256E-s1071765--dbaa7f32ee44c28d6a1f0c8095e8dfd8b4ec433b144085d5097425303a510ea9
+git-annex: SHA256E-s1071765--dbaa7f32ee44c28d6a1f0c8095e8dfd8b4ec433b144085d5097425303a510ea9 not found
+git-annex: whereis: 1 failed
+[william@hactar ~/Pictures/Photo Library]$ git annex whereis --key SHA256E-s1071765--dbaa7f32ee44c28d6a1f0c8095e8dfd8b4ec433b144085d5097425303a510ea9
+whereis SHA256E-s1071765--dbaa7f32ee44c28d6a1f0c8095e8dfd8b4ec433b144085d5097425303a510ea9 (1 copy) 
+        7691934f-2542-4103-9122-2db4e6cfc887 -- hactar [here]
+ok
+[william@hactar ~/Pictures/Photo Library]$ git annex fsck --key SHA256E-s1071765--dbaa7f32ee44c28d6a1f0c8095e8dfd8b4ec433b144085d5097425303a510ea9
+fsck SHA256E-s1071765--dbaa7f32ee44c28d6a1f0c8095e8dfd8b4ec433b144085d5097425303a510ea9 
+  Only 1 of 3 trustworthy copies exist of SHA256E-s1071765--dbaa7f32ee44c28d6a1f0c8095e8dfd8b4ec433b144085d5097425303a510ea9
+  Back it up with git-annex copy.
+failed
+(recording state in git...)
+git-annex: fsck: 1 failed
+[william@hactar ~/Pictures/Photo Library]$ git log --stat -S'SHA256E-s1071765--dbaa7f32ee44c28d6a1f0c8095e8dfd8b4ec433b144085d5097425303a510ea9'
+[william@hactar ~/Pictures/Photo Library]$ git annex whereis 2009/05/05/P1040890.JPG
+whereis 2009/05/05/P1040890.JPG (9 copies) 
+        0e825a69-1927-4f62-b731-6f3e98bba998 -- william@marvin:/media/backup/annex/photos [marvin]
+        1b728ab5-1e32-45a6-bc11-2a4bfdc9d6ab -- backup1
+        5c0caa42-b489-467b-a612-9590fa9d5a94 -- backup2
+        7691934f-2542-4103-9122-2db4e6cfc887 -- hactar [here]
+        894b2216-72e0-40e1-8765-1386e1e9e4b4 -- backup3
+        96f19fa8-d385-4e8b-b000-61ee15993a70 -- backup3
+        a862b121-d794-4af4-bb56-21adfe8962f2 -- S3
+        b083f8ae-42fb-41f0-a2a3-4e7c9f93aadb -- [guide]
+        bf021ce9-465b-4419-86e7-bddfd208fca4 -- git@newzaphod:~/repositories/annex/photos.git [zaphod]
+ok
+
+
+# End of transcript or log.
+"""]]
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+I trust Git Annex to keep hundreds of GB of data safe, and it has never failed me - despite my best efforts

diff --git a/doc/forum/Odd_Hybrid_Symlinks_To_Content.mdwn b/doc/forum/Odd_Hybrid_Symlinks_To_Content.mdwn
new file mode 100644
index 0000000..5e3b4d8
--- /dev/null
+++ b/doc/forum/Odd_Hybrid_Symlinks_To_Content.mdwn
@@ -0,0 +1,27 @@
+I've somehow managed to get my indirect repository to symlink to literal content instead of object files. 
+
+By this I mean literally the symlink is pointing at the contents of the file as the filename.
+
+So if I have a blah.txt file with this content:
+
+* First line
+* second line
+
+And I ls -al to view the symlink pointer, it shows up as this:
+
+* blah.txt -> First line?second line
+
+It literally has the contents of the file as the destination filename.
+
+I've tried a couple things I could think of to re-symlink the files, but they don't seem to do anything as they think everything is fine:
+
+* git annex indirect //returns nothing
+* git annex lock blah.txt //returns nothing
+* git annex fix blah.txt //returns nothing
+* git annex fsck //returns nothing
+
+I'm actually able to find several of these files hanging around by searching for all symlinks that don't point to something in the .git directory.
+
+Is there a way for me to replace the symlinks with correct symlinks to the objects in .git/annex? Can it even figure out which ones it was supposed to point to if the symlinks are messed up (are filenames -> content hashes stored anywhere else)?
+
+Else I might have to go do some manual rebasing and history editing to try to undo the bad commits manually. I've synced this repo to another direct repo so I'll need to figure out how to manually fix that repo too (using proxy).  From what I can tell the annex/direct/master seems to be same as master and synced/master branches? Is there an [[internals]] page for direct branches besides [[direct_mode]] so I know what should be fixed where?

cleanup
diff --git a/doc/git-annex-rekey.mdwn b/doc/git-annex-rekey.mdwn
index 7dbe6ae..4ec0b49 100644
--- a/doc/git-annex-rekey.mdwn
+++ b/doc/git-annex-rekey.mdwn
@@ -20,8 +20,6 @@ Multiple pairs of file and key can be given in a single command line.
   Allow rekeying of even files whose content is not currently available.
   Use with caution.
 
-# OPTIONS
-
 # SEE ALSO
 
 [[git-annex]](1)

devblog
diff --git a/doc/devblog/day_428-429__git_push_to_hiddden_service.mdwn b/doc/devblog/day_428-429__git_push_to_hiddden_service.mdwn
new file mode 100644
index 0000000..ec1bf12
--- /dev/null
+++ b/doc/devblog/day_428-429__git_push_to_hiddden_service.mdwn
@@ -0,0 +1,31 @@
+The `tor` branch is coming along nicely.
+
+This weekend, I continued working on the P2P protocol, implementing
+it for network sockets, and extending it to support connecting up
+git-send-pack/git-receive-pack. 
+
+There was a bit of a detour when I split the Free monad into two separate
+ones, one for Net operations and the other for Local filesystem operations.
+
+This weekend's work was sponsored by Thomas Hochstein on Patreon.
+
+----
+
+Today, implemented a `git-remote-tor-annex` command that git will
+use for tor-annex:: urls,  and made `git annex remotedaemon`
+serve the tor hidden service.
+
+Now I have git push/pull working to the hidden service, for example:
+
+	git pull tor-annex::eeaytkuhaupbarfi.onion:47651
+
+That works very well, but does not yet check that the user is authorized
+to use the repo, beyond knowing the onion address. And currently
+it only works in git-annex repos; with some tweaks it should
+also work in plain git repos.
+
+Next, I need to teach git-annex how to access tor-annex remotes.
+And after that, an interface in the webapp for setting them up and
+connecting them together.
+
+Today's work was sponsored by Josh Taylor on Patreon.

Added a comment
diff --git a/doc/forum/vanilla_git_repo_as_special_remote__63__/comment_2_6314256da98966f4c7d02aa0d6bf94ff._comment b/doc/forum/vanilla_git_repo_as_special_remote__63__/comment_2_6314256da98966f4c7d02aa0d6bf94ff._comment
new file mode 100644
index 0000000..f463554
--- /dev/null
+++ b/doc/forum/vanilla_git_repo_as_special_remote__63__/comment_2_6314256da98966f4c7d02aa0d6bf94ff._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="neocryptek@659edac901ffbc8e541a974f8f18987eeafc63bd"
+ nickname="neocryptek"
+ avatar="http://cdn.libravatar.org/avatar/d9bfdefa9b503f1ac4844a686618374e"
+ subject="comment 2"
+ date="2016-11-21T22:26:52Z"
+ content="""
+Right, though bup also requires installation on the server. I'm looking for a way to store content into a vanilla git repo (as I don't have permission to install anything custom on the server).
+
+Since I want to store the content outside of git annex, it feels like a special remote. Though ideally it would have human readable files like:
+
+* <https://git-annex.branchable.com/todo/dumb__44___unsafe__44___human-readable_backend/>
+
+But since it's git and not just a normal (single version) filesystem, it could dedupe and save previous versions. Is there an easy way to hook git up safely to the external remote protocol:
+
+* [[special_remotes/external]]
+"""]]

diff --git a/doc/forum/two-way_assistant_sync_with_ssh_special_remote.mdwn b/doc/forum/two-way_assistant_sync_with_ssh_special_remote.mdwn
new file mode 100644
index 0000000..749a793
--- /dev/null
+++ b/doc/forum/two-way_assistant_sync_with_ssh_special_remote.mdwn
@@ -0,0 +1,30 @@
+I am attempting to set up automatic two-way synchronization between my laptop and a server via ssh by running assistant on both machines. I want to have both machines be non-bare and unlocked.
+
+On the server:
+
+    $ mkdir ~/annex
+    $ cd annex
+    $ git init
+    $ git annex init u --version=6
+    $ echo This is test file 1. >testfile1.txt
+    $ git annex add testfile1.txt
+    $ git annex sync
+    $ git annex adjust --unlock
+    $ git annex wanted . standard
+    $ git annex group . client
+
+On my laptop:
+
+    $ git clone ssh://server/home/username/annex
+    $ cd annex
+    $ git annex init ml2 --version=6
+    $ git annex sync
+    $ git annex adjust --unlock
+    $ git annex wanted . standard
+    $ git annex group . client
+
+Everything seems to work when I manually sync. When I run
+
+    $ git annex assistant
+
+on both machines, however, I only get one-way automatic synchronization. Changes on the laptop are immediately propagated to the server. But changes on the server do not show up on the laptop until I manually sync. What am I doing wrong?

added meta field for myself
diff --git a/doc/bugs/adds_file_destined_for_annex_into_git_in___39__addurl__39__.mdwn b/doc/bugs/adds_file_destined_for_annex_into_git_in___39__addurl__39__.mdwn
index 7e900fa..a5cdfd6 100644
--- a/doc/bugs/adds_file_destined_for_annex_into_git_in___39__addurl__39__.mdwn
+++ b/doc/bugs/adds_file_destined_for_annex_into_git_in___39__addurl__39__.mdwn
@@ -36,5 +36,6 @@ cached/staged changes:
 
 """]]
 
+[[!meta author=yoh]]
 
 > [[fixed|done]] --[[Joey]]

todo
diff --git a/doc/todo/renameremote.mdwn b/doc/todo/renameremote.mdwn
new file mode 100644
index 0000000..3a92bf5
--- /dev/null
+++ b/doc/todo/renameremote.mdwn
@@ -0,0 +1,24 @@
+Sometimes a name has been used for a special remote, and you want to change
+the name. A common reason is that the special remote has become dead, and
+you want to reuse the name for a new special remote. 
+
+Initremote prevents reusing a name when the old one exists, even if the old
+one is dead. And that makes sense in general, because a dead remote can
+come back sometimes, and that would leave the repo with two special remotes
+with the same name, and so enableremote would need to be run with a uuid
+instead of a name to specify which one to enable, which is not a desirable
+state of affairs.
+
+So, add `git annex renameremote oldname newname`. This could also do a `git
+remote rename`, or equivilant. (`git remote rename` gets confused by special
+remotes not having a fetch url and fails; this can be worked around by
+manually renaming the stanza in git config.)
+
+Implementing that would need a way to remove the old name from remote.log.
+We can't remove lines from union merged files, but what we could do is
+add a new line like:
+
+	- name=oldname timestamp=<latest>
+
+And in parsing remote.log, if the UUID is "-", don't include the
+remote with that name in the the resulting map.

addurl: Fix bug in checking annex.largefiles expressions using largerthan, mimetype, and smallerthan; the first two always failed to match, and the latter always matched.
diff --git a/CHANGELOG b/CHANGELOG
index 3777e6d..de1a16f 100644
--- a/CHANGELOG
+++ b/CHANGELOG
@@ -1,3 +1,11 @@
+git-annex (6.20161119) UNRELEASED; urgency=medium
+
+  * addurl: Fix bug in checking annex.largefiles expressions using
+    largerthan, mimetype, and smallerthan; the first two always failed
+    to match, and the latter always matched.
+
+ -- Joey Hess <id@joeyh.name>  Mon, 21 Nov 2016 11:27:50 -0400
+
 git-annex (6.20161118) unstable; urgency=medium
 
   * git-annex.cabal: Loosen bounds on persistent to allow 2.5, which
diff --git a/Command/AddUrl.hs b/Command/AddUrl.hs
index e32ceb5..9b6ac28 100644
--- a/Command/AddUrl.hs
+++ b/Command/AddUrl.hs
@@ -341,7 +341,7 @@ cleanup u url file key mtmp = case mtmp of
 	Nothing -> go
 	Just tmp -> do
 		largematcher <- largeFilesMatcher
-		ifM (checkFileMatcher largematcher file)
+		ifM (checkFileMatcher largematcher tmp)
 			( go
 			, do
 				liftIO $ renameFile tmp file
diff --git a/doc/bugs/adds_file_destined_for_annex_into_git_in___39__addurl__39__.mdwn b/doc/bugs/adds_file_destined_for_annex_into_git_in___39__addurl__39__.mdwn
index 5b9c76e..7e900fa 100644
--- a/doc/bugs/adds_file_destined_for_annex_into_git_in___39__addurl__39__.mdwn
+++ b/doc/bugs/adds_file_destined_for_annex_into_git_in___39__addurl__39__.mdwn
@@ -37,4 +37,4 @@ cached/staged changes:
 """]]
 
 
-
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/bugs/adds_file_destined_for_annex_into_git_in___39__addurl__39__/comment_1_d598317883753baf02175a3bf866e08a._comment b/doc/bugs/adds_file_destined_for_annex_into_git_in___39__addurl__39__/comment_1_d598317883753baf02175a3bf866e08a._comment
new file mode 100644
index 0000000..e03e574
--- /dev/null
+++ b/doc/bugs/adds_file_destined_for_annex_into_git_in___39__addurl__39__/comment_1_d598317883753baf02175a3bf866e08a._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-11-21T15:12:54Z"
+ content="""
+It's sufficient to have "* annex.largefiles=(largerthan=100kb)"
+in .gitattributes.
+
+Even "* annex.largefiles=(largerthan=0kb)" will reproduce it.
+
+Ok, I see why.. It's running the largefile matcher on the destination file
+before it renames the temp file to it!
+
+Seems to have been broken this way ever since addurl got largefiles
+support. Testing didn't catch it because it only affects largefiles
+expressions that need to examine the file.
+
+Fixed in git. Audited other checkFileMatcher calls for this problem;
+the rest are ok.
+"""]]

Added a comment: Coldline
diff --git a/doc/tips/using_Google_Cloud_Storage/comment_8_1b4eb7e0f44865cd5ff0f8ef507d99c1._comment b/doc/tips/using_Google_Cloud_Storage/comment_8_1b4eb7e0f44865cd5ff0f8ef507d99c1._comment
new file mode 100644
index 0000000..1a71f77
--- /dev/null
+++ b/doc/tips/using_Google_Cloud_Storage/comment_8_1b4eb7e0f44865cd5ff0f8ef507d99c1._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="scottgorlin@a32946b2aad278883c1690a0753241583a9855b9"
+ nickname="scottgorlin"
+ avatar="http://cdn.libravatar.org/avatar/2dd1fc8add62bbf4ffefac081b322563"
+ subject="Coldline"
+ date="2016-11-21T00:49:23Z"
+ content="""
+Wanted to add that \"storageclass=COLDLINE\" appears to work seamlessly, both from my mac and arm NAS.  As far as I can tell, this appears to be a no-brainer vs glacier - builtin git annex client, simpler/cheaper billing, and no 4 hour delay!
+"""]]

initial whining
diff --git a/doc/bugs/adds_file_destined_for_annex_into_git_in___39__addurl__39__.mdwn b/doc/bugs/adds_file_destined_for_annex_into_git_in___39__addurl__39__.mdwn
new file mode 100644
index 0000000..5b9c76e
--- /dev/null
+++ b/doc/bugs/adds_file_destined_for_annex_into_git_in___39__addurl__39__.mdwn
@@ -0,0 +1,40 @@
+### Please describe the problem.
+
+When addurl'ing a big file with .gitattributes configured to add only some files directly into git (and 'git annex add' operating correctly), addurl adds large files straight into git.
+
+### What version of git-annex are you using? On what operating system?
+
+git-annex version: 6.20161018+gitgf3c366a-1~ndall+1
+
+
+### Please provide any additional information below.
+
+[[!format sh """
+$> cat .gitattributes 
+* annex.backend=MD5E
+* annex.largefiles=(largerthan=100kb)
+*.json annex.largefiles=nothing
+*.txt annex.largefiles=nothing
+*.tsv annex.largefiles=nothing
+*.nii.gz annex.largefiles=(largerthan=0kb)
+*.tgz annex.largefiles=(largerthan=0kb)
+*.tar.gz annex.largefiles=(largerthan=0kb)
+*.gz annex.largefiles=(largerthan=0kb)
+
+$> git annex addurl http://fcp-indi.s3.amazonaws.com/data/Projects/HBNSSI/RawDataTars/sub-0031121_baseline.tar.gz\?versionId\=7FvexHgyazWF.dUo238FA7XRiK0FWQDw.
+addurl fcp_indi.s3.amazonaws.com_data_Projects_HBNSSI_RawDataTars_sub_0031121_baseline.tar.gz_versionId_7FvexHgyazWF.dUo238FA7XRiK0FWQDw. (downloading http://fcp-indi.s3.amazonaws.com/data/Projects/HBNSSI/RawDataTars/sub-0031121_baseline.tar.gz?versionId=7FvexHgyazWF.dUo238FA7XRiK0FWQDw. ...) 
+/mnt/btrfs/datasets/datalad/crawl-misc/indi/ 100%[==============================================================================================>] 195.44M  21.2MB/s    in 12s     
+(non-large file; adding content to git repository) ok
+(recording state in git...)
+cached/staged changes:                                                                                                                                                              
+ \u2026r.gz_versionId_7FvexHgyazWF.dUo238FA7XRiK0FWQDw. | Bin 0 -> 204937338 bytes
+
+$> ls -l fcp_indi.s3.amazonaws.com_data_Projects_HBNSSI_RawDataTars_sub_0031121_baseline.tar.gz_versionId_7FvexHgyazWF.dUo238FA7XRiK0FWQDw. 
+-rw------- 1 yoh datalad 204937338 Oct 25 17:30 fcp_indi.s3.amazonaws.com_data_Projects_HBNSSI_RawDataTars_sub_0031121_baseline.tar.gz_versionId_7FvexHgyazWF.dUo238FA7XRiK0FWQDw.
+cached/staged changes:                                                                                                                                                              
+ \u2026r.gz_versionId_7FvexHgyazWF.dUo238FA7XRiK0FWQDw. | Bin 0 -> 204937338 bytes
+
+"""]]
+
+
+

Added a comment
diff --git a/doc/bugs/Nearline_bucket_stopped_working___40__can__39__t_even_HEAD_files__41__/comment_2_c227071f23a96ed9928f128e7f77e503._comment b/doc/bugs/Nearline_bucket_stopped_working___40__can__39__t_even_HEAD_files__41__/comment_2_c227071f23a96ed9928f128e7f77e503._comment
new file mode 100644
index 0000000..820e6b0
--- /dev/null
+++ b/doc/bugs/Nearline_bucket_stopped_working___40__can__39__t_even_HEAD_files__41__/comment_2_c227071f23a96ed9928f128e7f77e503._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="justin.lebar@7a36fcafc322d9a381e89f08ab6289033c6dde91"
+ nickname="justin.lebar"
+ avatar="http://cdn.libravatar.org/avatar/9fca4b61a1ab555f231851e7543f9a3e"
+ subject="comment 2"
+ date="2016-11-20T03:47:23Z"
+ content="""
+Thanks for your reply, Joey.  Sorry for the delay getting back to this -- I didn't realize I hadn't enabled notifications on the thread.
+
+The GCS docs suggest that 400 errors should be accompanied by an explanation in the reply body.
+
+> Error responses usually include a JSON document in the response body, which contains information about the error.
+
+https://cloud.google.com/storage/docs/json_api/v1/status-codes
+
+Do you think we're not getting an http response body here, or that it's not being printed out?
+"""]]

diff --git a/doc/bugs/Build_with_aws_head_fails.mdwn b/doc/bugs/Build_with_aws_head_fails.mdwn
new file mode 100644
index 0000000..9937d6c
--- /dev/null
+++ b/doc/bugs/Build_with_aws_head_fails.mdwn
@@ -0,0 +1,48 @@
+### Please describe the problem.
+https://github.com/aristidb/aws/issues/206 was recently resolved in https://github.com/aristidb/aws/pull/213.
+
+A newer version will be tagged imminently according to https://github.com/aristidb/aws/issues/206#issuecomment-260214736.
+
+With the http-conduit (<2.2.0) constraint removed from git-annex.cabal, and the aws dependency set to use aws head (currently c8806dc), the git-annex build fails. 
+
+### What steps will reproduce the problem?
+
+Remove the http-conduit (<2.2.0) constraint and attempt to build git-annex with aws head.
+
+### What version of git-annex are you using? On what operating system?
+
+macOS 10.11, git-annex 6.20161118.
+
+### Please provide any additional information below.
+Full build log: https://gist.github.com/ilovezfs/15bcd8f1086b3d825beff58140e04eec
+[[!format sh """
+[ 90 of 542] Compiling Types.Crypto     ( Types/Crypto.hs, dist/dist-sandbox-6b15e8f0/build/git-annex/git-annex-tmp/Types/Crypto.o )
+[ 91 of 542] Compiling Utility.Metered  ( Utility/Metered.hs, dist/dist-sandbox-6b15e8f0/build/git-annex/git-annex-tmp/Utility/Metered.o )
+[ 92 of 542] Compiling Messages.JSON    ( Messages/JSON.hs, dist/dist-sandbox-6b15e8f0/build/git-annex/git-annex-tmp/Messages/JSON.o )
+[ 93 of 542] Compiling Utility.Url      ( Utility/Url.hs, dist/dist-sandbox-6b15e8f0/build/git-annex/git-annex-tmp/Utility/Url.o )
+
+Utility/Url.hs:354:34: error:
+    • The constructor ‘StatusCodeException’ should have 2 arguments, but has been given 3
+    • In the pattern: StatusCodeException s _ _
+      In an equation for ‘matchStatusCodeException’:
+          matchStatusCodeException want e@(StatusCodeException s _ _)
+            | want s = Just e
+            | otherwise = Nothing
+
+Utility/Url.hs:354:34: error:
+    • Couldn't match expected type ‘HttpException’
+                  with actual type ‘HttpExceptionContent’
+    • In the pattern: StatusCodeException s _ _
+      In an equation for ‘matchStatusCodeException’:
+          matchStatusCodeException want e@(StatusCodeException s _ _)
+            | want s = Just e
+            | otherwise = Nothing
+cabal: Leaving directory '.'
+cabal: Error: some packages failed to install:
+git-annex-6.20161118 failed during the building phase. The exception was:
+ExitFailure 1
+"""]]
+
+### 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 :)
+

Added a comment
diff --git a/doc/bugs/add_fails_with_v6_repo_when_four_levels_deep/comment_2_b3998823aca4266089dcbcf325d8f8c1._comment b/doc/bugs/add_fails_with_v6_repo_when_four_levels_deep/comment_2_b3998823aca4266089dcbcf325d8f8c1._comment
new file mode 100644
index 0000000..1046fb0
--- /dev/null
+++ b/doc/bugs/add_fails_with_v6_repo_when_four_levels_deep/comment_2_b3998823aca4266089dcbcf325d8f8c1._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="t.z.mates"
+ avatar="http://cdn.libravatar.org/avatar/90f15fad216078fd08d62cc676487925"
+ subject="comment 2"
+ date="2016-11-19T04:42:25Z"
+ content="""
+Thanks for looking into it; I just checked again, and even on the newest version (6.20161118 binary), I'm still experiencing the behavior. However, I checked on an older OpenSuse box I have, and there it works (6.20161031 from OpenSuse repo).
+
+Since my two machines experiencing the problem are both running arch, it seems it's somehow related to that distro. I've checked both installing via the binary (from kitenet) and from the arch community repo, but both produce the same behavior. Further, the OpenSuse install has the same build flags as the binaries, so that doesn't seem to be it. Are there any other diagnostics I can run?
+
+This particular problem isn't very troublesome (it doesn't seem to have any material impact aside from error messages); however, I also occasionally experience a more serious bug. Namely, when certain (seemingly random) files are added to the repo locked, their content disappears and the symlink is broken (this is the other problem I alluded to in the description). I suspect that problem is related to this one though, since it also only affects my arch machines. I haven't yet submitted a report for that bug yet, though, since I can't reliably replicate it. 
+"""]]

add news item for git-annex 6.20161118
diff --git a/doc/news/version_6.20161118.mdwn b/doc/news/version_6.20161118.mdwn
new file mode 100644
index 0000000..42d8628
--- /dev/null
+++ b/doc/news/version_6.20161118.mdwn
@@ -0,0 +1,17 @@
+git-annex 6.20161118 released with [[!toggle text="these changes"]]
+[[!toggleable text="""
+   * git-annex.cabal: Loosen bounds on persistent to allow 2.5, which
+     on Debian has been patched to work with esqueleto.
+     This may break cabal's resolver on non-Debian systems;
+     if so, either use stack to build, or run cabal with
+     --constraint='persistent ==2.2.4.1'
+     Hopefully this mess with esqueleto will be resolved soon.
+   * sync: Pass --allow-unrelated-histories to git merge when used with git
+     git 2.9.0 or newer. This makes merging a remote into a freshly created
+     direct mode repository work the same as it works in indirect mode.
+   * Avoid backtraces on expected failures when built with ghc 8;
+     only use backtraces for unexpected errors.
+   * fsck --all --from was checking the existence and content of files
+     in the local repository, rather than on the special remote. Oops.
+   * Linux arm standalone: Build with a 32kb page size, which is needed
+     on several ARM NAS devices, including Drobo 5N, and WD NAS."""]]
\ No newline at end of file

comment
diff --git a/doc/forum/What_to_do_if_special_remotes_refuses_drops__63__/comment_1_0b523b2b6c361346c36ad456bbbac645._comment b/doc/forum/What_to_do_if_special_remotes_refuses_drops__63__/comment_1_0b523b2b6c361346c36ad456bbbac645._comment
new file mode 100644
index 0000000..cf808aa
--- /dev/null
+++ b/doc/forum/What_to_do_if_special_remotes_refuses_drops__63__/comment_1_0b523b2b6c361346c36ad456bbbac645._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-11-18T15:39:20Z"
+ content="""
+It could certianly be a bug in the special remote implementation. It's also
+possible for some special remotes to intentionally not be able to remove
+content (this is the case with the web special remote, and the bup special
+remote at least).
+
+You can manually remove the special remote, by editing .git/config and
+deleting the stanza for that remote. You may want to run `git annex dead
+$remotename` first, if you don't intend to ever use that special remote
+again.
+"""]]

Added a comment
diff --git a/doc/forum/uuid_mismatch___59___expected_Just___40__UUID_...___41___but_remote_gitrepo_has_UUID_.../comment_3_a681a4847acbe890c4e486288b3c81d3._comment b/doc/forum/uuid_mismatch___59___expected_Just___40__UUID_...___41___but_remote_gitrepo_has_UUID_.../comment_3_a681a4847acbe890c4e486288b3c81d3._comment
new file mode 100644
index 0000000..d92f3fe
--- /dev/null
+++ b/doc/forum/uuid_mismatch___59___expected_Just___40__UUID_...___41___but_remote_gitrepo_has_UUID_.../comment_3_a681a4847acbe890c4e486288b3c81d3._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="yomguy"
+ avatar="http://cdn.libravatar.org/avatar/03db077c04f8b753f3f504d9a2b06a29"
+ subject="comment 3"
+ date="2016-11-18T14:00:51Z"
+ content="""
+Hi joey,
+
+After modifying the gcrypt-id as you proposed, I have finally managed to clone the repo with  
+
+`git clone gcrypt::ssh://my.domain/home/admin/`
+
+But now I get only unresolved symbolic links for each files, that is .git/annex/objects directory only contains .map files.
+
+Would you have an idea about the reason/source of this behavior?
+
+Thank you so much,
+Guillaume
+"""]]

diff --git a/doc/forum/What_to_do_if_special_remotes_refuses_drops__63__.mdwn b/doc/forum/What_to_do_if_special_remotes_refuses_drops__63__.mdwn
new file mode 100644
index 0000000..512e895
--- /dev/null
+++ b/doc/forum/What_to_do_if_special_remotes_refuses_drops__63__.mdwn
@@ -0,0 +1,9 @@
+I have a special remote that I would like to delete and have marked it as such in the assistant. Although this was before my myriad of problems with git annex itself wanting to repair the repo all the time. Right now if I take a loog into my daemon.log I see the following error over and over again:
+
+```
+drop skydrive foo.bar 
+  This file could not be removed
+failed
+```
+
+I checked if I can login into my account and it works just fine. So I assume that this might be a bug? Is it somehow possible to forego the cleaning out of the special remote and just mark it as deleted for good? Thanks in advance!

Added a comment
diff --git a/doc/forum/how_to_disaster_recovery/comment_12_f2e570dc60a6f16e8f696d94e253775f._comment b/doc/forum/how_to_disaster_recovery/comment_12_f2e570dc60a6f16e8f696d94e253775f._comment
new file mode 100644
index 0000000..7c7da0e
--- /dev/null
+++ b/doc/forum/how_to_disaster_recovery/comment_12_f2e570dc60a6f16e8f696d94e253775f._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="openmedi"
+ subject="comment 12"
+ date="2016-11-18T12:03:44Z"
+ content="""
+A recent update to annex via homebrew now reslolves the issue with the weird looking webapp.
+"""]]

devblog
diff --git a/doc/devblog/day_426__grab_bag.mdwn b/doc/devblog/day_426__grab_bag.mdwn
index 4a3bf90..36e3207 100644
--- a/doc/devblog/day_426__grab_bag.mdwn
+++ b/doc/devblog/day_426__grab_bag.mdwn
@@ -45,19 +45,19 @@ authentication. Which is a whole nother ball of complexity. So, I'm leaning
 instead to using a simple custom protocol something like:
 
 		> AUTH $localuuid $token
-		< AUTH-OK $remoteuuid
+		< AUTH-SUCCESS $remoteuuid
 		> SENDPACK $length
 		> $gitdata
 		< RECVPACK $length
 		< $gitdata
 		> GET $pos $key
-		< SENDING $length
+		< DATA $length
 		< $bytes
-		> GET-OK
+		> SUCCESS
 		> PUT $key
-		< SEND $pos
-		> SENDING $length
+		< PUT-FROM $pos
+		> DATA $length
 		> $bytes
-		< PUT-OK
+		< SUCCESS
 
 Today's work was sponsored by Riku Voipio.
diff --git a/doc/devblog/day_427__free_p2p.mdwn b/doc/devblog/day_427__free_p2p.mdwn
new file mode 100644
index 0000000..7c72758
--- /dev/null
+++ b/doc/devblog/day_427__free_p2p.mdwn
@@ -0,0 +1,51 @@
+For a Haskell programmer, and day where a big thing is implemented
+without the least scrap of code that touches the IO monad is a good day.
+And this was a good day for me!
+
+Implemented the p2p protocol for tor hidden services. Its needs are somewhat
+similar to the external special remote protocol, but the two protocols are
+not fully overlapping with one-another. Rather than try to unify them, and
+so complicate both cases, I prefer to reuse as much code as possible between
+separate protocol implementations. The generating and parsing of messages
+is largely shared between them. I let the new p2p protocol otherwise
+develop in its own direction.
+
+But, I *do* want to make this p2p protocol reusable for other types of p2p
+networks than tor hidden services. This was an opportunity to use the Free
+monad, which I'd never used before. It worked out great, letting me write
+monadic code to handle requests and responses in the protocol, that reads
+the content of files and resumes transfers and so on, all independent
+of any concrete implementation.
+
+The whole implementation of the protocol only needed 74 lines of monadic code.
+It helped that I was able to factor out functions like this one, that is used
+both for handling a download, and by the remote when an upload is sent to it:
+
+	receiveContent :: Key -> Offset -> Len -> Proto Bool
+	receiveContent key offset len = do
+	        content <- receiveBytes len
+	        ok <- writeKeyFile key offset content
+	        sendMessage $ if ok then SUCCESS else FAILURE
+	        return ok
+
+To get transcripts of the protocol in action, the Free monad can be evaluated
+purely, providing the other side of the conversation:
+
+	ghci> putStrLn $ protoDump $ runPure (put (fromJust $ file2key "WORM--foo")) [PUT_FROM (Offset 10), SUCCESS]
+	> PUT WORM--foo
+	< PUT-FROM 10
+	> DATA 90
+	> bytes
+	< SUCCESS
+	result: True
+
+	ghci> putStrLn $ protoDump $ runPure (serve (toUUID "myuuid")) [GET (Offset 0) (fromJust $ file2key "WORM--foo")]
+	< GET 0 WORM--foo
+	> PROTO-ERROR must AUTH first
+	result: ()
+
+Am very happy with all this pure code and that I'm finally using Free monads.
+Next I need to get down the the dirty business of wiring this up to
+actual IO actions, and an actual network connection.
+
+Today's work was sponsored by Jake Vosloo on Patreon.

Added a comment: git annex copy --auto --to cloud works
diff --git a/doc/forum/sync_--content__44___fatal_is_outside_repository_errors/comment_4_a7f476aeacf88679f25badc78fad886a._comment b/doc/forum/sync_--content__44___fatal_is_outside_repository_errors/comment_4_a7f476aeacf88679f25badc78fad886a._comment
new file mode 100644
index 0000000..eec45e3
--- /dev/null
+++ b/doc/forum/sync_--content__44___fatal_is_outside_repository_errors/comment_4_a7f476aeacf88679f25badc78fad886a._comment
@@ -0,0 +1,57 @@
+[[!comment format=mdwn
+ username="andrew"
+ avatar="http://cdn.libravatar.org/avatar/acc0ece1eedf07dd9631e7d7d343c435"
+ subject="git annex copy --auto --to cloud works"
+ date="2016-11-17T17:49:27Z"
+ content="""
+Yes, only `git annex sync --content` seems to fail. I am using v6 with a mix of unlocked and locked files. I did not know about the --auto flags for copy/get.
+
+* `git annex copy --auto --to cloud` works fine
+* `git annex get --auto --from cloud` works fine
+
+
+*Are there any symlinks in the path to /Users/andrew/notes ? Eg, is /Users a symlink, or /Users/andrew a symlink, or //Users/andrew/notes itself symlinked to elsewhere?*
+
+**No**
+
+*You say it's only failing for some files. Do the filenames that it's failing on contain any non-ascii characters?*
+
+**They seem normal.**
+
+*So, please paste in git annex version and git annex info output.*
+
+    git-annex version: 6.20161110-gd48f4ca
+    build flags: Assistant Webapp Pairing Testsuite S3(multipartupload)(storageclasses) WebDAV FsEvents XMPP ConcurrentOutput TorrentParser MagicMime Feeds Quvi
+    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 SHA1E SHA1 MD5E MD5 WORM URL
+    remote types: git gcrypt S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external
+    local repository version: 6
+    supported repository versions: 3 5 6
+    upgrade supported from repository versions: 0 1 2 3 4 5
+    operating system: darwin x86_64
+
+    repository mode: indirect
+    trusted repositories: 0
+    semitrusted repositories: 10
+    00000000-0000-0000-0000-000000000001 -- web
+    00000000-0000-0000-0000-000000000002 -- bittorrent
+    22de57a0-c9ca-4bfe-8349-3141b3a87c8f -- Dream Objects [cloud]
+    334791ca-c284-4a87-a233-fc29be00d31a -- [disc_May-2-2015_a]
+    4c57ac0e-b8fe-4b4b-98d3-fb0a1b6b9657 -- MacBook Air [here]
+    6a85150d-6ea2-4ba1-92ce-8f4ef575b8e0 -- prowl MacBook Mini
+    896c3d52-427a-41a1-867c-d18e6740d758 -- disc_May_4_2015_1
+    96391b13-3981-430f-ac3b-6210e3d4e759 -- [disc_May-2-2015_b]
+    b4a41e90-2398-4bba-aaf5-d8f8cd78a5bc -- 2TB USB Drive [usbdrive]
+    e42b223d-ec04-4ad8-bdf7-8429a45d844c -- disc_May-2-2015_a
+    untrusted repositories: 0
+    transfers in progress: none
+    available local disk space: 2.32 gigabytes (+1 megabyte reserved)
+    temporary object directory size: 29.47 megabytes (clean up with git-annex unused)
+    local annex keys: 4104
+    local annex size: 10.53 gigabytes
+    annexed files in working tree: 6417
+    size of annexed files in working tree: 80.75 gigabytes
+    bloom filter size: 32 mebibytes (0.8% full)
+    backend usage: 
+    SHA256E: 6417
+
+"""]]

Added a comment: RESOLVED
diff --git a/doc/bugs/DBG__58___running___96____47__Users__47__joey__47__homebrew__47__opt__47__gpg-agent__47__bin__47__gpg-agent__39___for_testing_failed/comment_1_39718e8a35e42421a8aaf3316ae1d76a._comment b/doc/bugs/DBG__58___running___96____47__Users__47__joey__47__homebrew__47__opt__47__gpg-agent__47__bin__47__gpg-agent__39___for_testing_failed/comment_1_39718e8a35e42421a8aaf3316ae1d76a._comment
new file mode 100644
index 0000000..02b62f4
--- /dev/null
+++ b/doc/bugs/DBG__58___running___96____47__Users__47__joey__47__homebrew__47__opt__47__gpg-agent__47__bin__47__gpg-agent__39___for_testing_failed/comment_1_39718e8a35e42421a8aaf3316ae1d76a._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="andrew"
+ avatar="http://cdn.libravatar.org/avatar/acc0ece1eedf07dd9631e7d7d343c435"
+ subject="RESOLVED"
+ date="2016-11-17T14:59:15Z"
+ content="""
+Ooops. I am on OS-X. I use brew for my gnupg installation. It appears I had removed gpg from the path when installing something. I just needed to run to fix:
+
+    brew link gnupg2
+
+Thanks,
+
+Andrew
+"""]]

diff --git a/doc/bugs/when_you_get_a_file_but_don__39__t_actually_have_enough_space_for_it__44___the_error_message_makes_useless_suggestions.mdwn b/doc/bugs/when_you_get_a_file_but_don__39__t_actually_have_enough_space_for_it__44___the_error_message_makes_useless_suggestions.mdwn
new file mode 100644
index 0000000..19e8392
--- /dev/null
+++ b/doc/bugs/when_you_get_a_file_but_don__39__t_actually_have_enough_space_for_it__44___the_error_message_makes_useless_suggestions.mdwn
@@ -0,0 +1,21 @@
+The suggestion to make remotes available isn't really applicable, since the error was local.
+
+This is with git annex 6.20161110-gd48f4ca.
+
+[[!format sh """
+  ../git-annex.linux/git-annex get archiveteam-fire/metro.co.uk-urls-2007-04-12-20150627/metro.co.uk-urls-2007-04-12-20150627_meta.xml
+get archiveteam-fire/metro.co.uk-urls-2007-04-12-20150627/metro.co.uk-urls-2007-04-12-20150627_meta.xml 
+  not enough free space, need 98.82 GB more (use --force to override this check or adjust annex.diskreserve)
+
+  Unable to access these remotes: web
+
+  Try making some of these repositories available:
+        00000000-0000-0000-0000-000000000001 -- web
+        9f8218c0-763f-463d-9152-ecdc56d4452c -- iabak@redwyne.jwintjen.de:~/IA.BAK/shard12
+failed
+git-annex: get: 1 failed
+"""]]
+
+### 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)
+
+mixed success

Added a comment
diff --git a/doc/bugs/Adding_zip_or_7z_or_tar_archive_builds_for_windows/comment_2_afa6a131999feda67876859cd85ebcfc._comment b/doc/bugs/Adding_zip_or_7z_or_tar_archive_builds_for_windows/comment_2_afa6a131999feda67876859cd85ebcfc._comment
new file mode 100644
index 0000000..b0db544
--- /dev/null
+++ b/doc/bugs/Adding_zip_or_7z_or_tar_archive_builds_for_windows/comment_2_afa6a131999feda67876859cd85ebcfc._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="luckcolorsgoo@ab4f3c1c44a7dbcbcb9d9a29315b59ad524ceaaa"
+ nickname="luckcolorsgoo"
+ avatar="http://cdn.libravatar.org/avatar/ddff84cd2a97252a05cccb4bc5010448"
+ subject="comment 2"
+ date="2016-11-16T22:56:46Z"
+ content="""
+In my case i was going to make a script for automatically downloading and updating an git portbale / git annex instance, by first fetching git portbale and then downloading the gitannex exe.
+
+So yeah it's more reliable to extract an archive rather than trying to extract the setup without executing it.
+That's why i'm asking for this feature. :)
+
+
+
+"""]]

arm build uses 32kb page size
(Change was made in gitannexbuilder scripts not here.)
diff --git a/CHANGELOG b/CHANGELOG
index 6dd4edb..5bd9d3e 100644
--- a/CHANGELOG
+++ b/CHANGELOG
@@ -13,6 +13,8 @@ git-annex (6.20161112) UNRELEASED; urgency=medium
     only use backtraces for unexpected errors.
   * fsck --all --from was checking the existence and content of files
     in the local repository, rather than on the special remote. Oops.
+  * Linux arm standalone: Build with a 32kb page size, which is needed
+    on several ARM NAS devices, including Drobo 5N, and WD NAS.
 
  -- Joey Hess <id@joeyh.name>  Tue, 15 Nov 2016 11:15:27 -0400
 
diff --git a/doc/bugs/git-annex_won__39__t_execute_on_WD_My_Cloud_NAS/comment_8_48026cf7c187e97d53d15d35ed2c3670._comment b/doc/bugs/git-annex_won__39__t_execute_on_WD_My_Cloud_NAS/comment_8_48026cf7c187e97d53d15d35ed2c3670._comment
new file mode 100644
index 0000000..4930311
--- /dev/null
+++ b/doc/bugs/git-annex_won__39__t_execute_on_WD_My_Cloud_NAS/comment_8_48026cf7c187e97d53d15d35ed2c3670._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 8"""
+ date="2016-11-16T21:48:49Z"
+ content="""
+The arm daily build now uses a 32kb page size. So try
+<https://downloads.kitenet.net/git-annex/autobuild/armel/git-annex-standalone-armel.tar.gz>
+
+That has been verified to fix the problem on a Drobo 5N.
+
+This may still not be enough for some of the affected NAS devices, which
+use a 64kb page size. Unfortunately, gold fails to link with a 64kb page
+size: <http://bugs.debian.org/844467>
+"""]]

Added a comment: how about reusing the special remote protocol?
diff --git a/doc/devblog/day_426__grab_bag/comment_1_4d01c756850032d351fa99188a3301a7._comment b/doc/devblog/day_426__grab_bag/comment_1_4d01c756850032d351fa99188a3301a7._comment
new file mode 100644
index 0000000..7b5a294
--- /dev/null
+++ b/doc/devblog/day_426__grab_bag/comment_1_4d01c756850032d351fa99188a3301a7._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="https://anarc.at/openid/"
+ nickname="anarcat"
+ avatar="http://cdn.libravatar.org/avatar/b36dcf65657dd36128161355d8920a99503def9461c1bb212410980fe6f07125"
+ subject="how about reusing the special remote protocol?"
+ date="2016-11-16T21:58:08Z"
+ content="""
+git-annex already has a custom protocol detailed in [[design/external_special_remote_protocol]]. it could be quite useful to have that protocol extended to support direct object transfer instead of having to mess around with temporary files like may remotes do, for example...
+
+maybe that makes no sense at all, i don't know. :) --[[anarcat]]
+"""]]

devblog
diff --git a/doc/devblog/day_426__grab_bag.mdwn b/doc/devblog/day_426__grab_bag.mdwn
new file mode 100644
index 0000000..4a3bf90
--- /dev/null
+++ b/doc/devblog/day_426__grab_bag.mdwn
@@ -0,0 +1,63 @@
+Fixed one howler of a bug today. Turns out that
+`git annex fsck --all --from remote` didn't actually check the content of
+the remote, but checked the local repository. Only `--all` was buggy;
+`git annex fsck --from remote` was ok. Don't think this is crash priority
+enough to make a release for, since only `--all` is affected.
+
+Somewhat uncomfortably made `git annex sync` pass
+`--allow-unrelated-histories` to git merge. While I do think that git's
+recent refusal to merge unrelated histories is good in general, the
+problem is that initializing a direct mode repository involves making an
+empty commit. So merging from a remote into such a direct mode repository
+means merging unrelated histories, while an indirect mode repository doesn't.
+Seems best to avoid such inconsistencies, and the only way I could see to
+do it is to always use `--allow-unrelated-histories`. May revisit this once
+direct mode is finally removed.
+
+Using the git-annex arm standalone bundle on some WD NAS boxes used to
+work, and then it seems they changed their kernel to use a nonstandard page
+size, and broke it. This actually seems to be a 
+[bug in the gold linker](http://bugs.debian.org/844467), which defaults to an
+unncessarily small page size on arm. The git-annex arm bundle is being
+adjusted to try to deal with this.
+
+ghc 8 made `error` include some backtrace information. While it's really
+nice to have backtraces for unexpected exceptions in Haskell, it turns
+out that git-annex used `error` a lot with the intent of showing an error
+message to the user, and a backtrace clutters up such messages. So,
+bit the bullet and checked through every `error` in git-annex and made such
+ones not include a backtrace.
+
+Also, I've been considering what protocol to use between git-annex nodes
+when communicating over tor. One way would be to make it very similar to
+`git-annex-shell`, using rsync etc, and possibly reusing code from
+git-annex-shell. However, it can take a while to make a connection across
+the tor network, and that method seems to need a new connection for each
+file transfered etc. Also thought about using a http based protocol. The
+servant library is great for that, you get both http client and server
+implementations almost for free. Resuming interrupted transfers might
+complicate it, and the hidden service side would need to listen on a unix
+socket, instead of the regular http port. It might be worth it to use http
+for tor, if it could be reused for git-annex http servers not on the tor
+network. But, then I'd have to make the http server support git pull and
+push over http in a way that's compatable with how git uses http, including
+authentication. Which is a whole nother ball of complexity. So, I'm leaning
+instead to using a simple custom protocol something like:
+
+		> AUTH $localuuid $token
+		< AUTH-OK $remoteuuid
+		> SENDPACK $length
+		> $gitdata
+		< RECVPACK $length
+		< $gitdata
+		> GET $pos $key
+		< SENDING $length
+		< $bytes
+		> GET-OK
+		> PUT $key
+		< SEND $pos
+		> SENDING $length
+		> $bytes
+		< PUT-OK
+
+Today's work was sponsored by Riku Voipio.

fsck --all --from was checking the content of files in the local repository, rather than on the special remote.
Straight up forgot to handle this case!
This commit was sponsored by Fernando Jimenez on Patreon.
diff --git a/CHANGELOG b/CHANGELOG
index 71ef1c1..6dd4edb 100644
--- a/CHANGELOG
+++ b/CHANGELOG
@@ -11,6 +11,8 @@ git-annex (6.20161112) UNRELEASED; urgency=medium
     direct mode repository work the same as it works in indirect mode.
   * Avoid backtraces on expected failures when built with ghc 8;
     only use backtraces for unexpected errors.
+  * fsck --all --from was checking the existence and content of files
+    in the local repository, rather than on the special remote. Oops.
 
  -- Joey Hess <id@joeyh.name>  Tue, 15 Nov 2016 11:15:27 -0400
 
diff --git a/Command/Fsck.hs b/Command/Fsck.hs
index 9383c07..96ffd35 100644
--- a/Command/Fsck.hs
+++ b/Command/Fsck.hs
@@ -89,7 +89,7 @@ seek o = allowConcurrentOutput $ do
 	checkDeadRepo u
 	i <- prepIncremental u (incrementalOpt o)
 	withKeyOptions (keyOptions o) False
-		(\k ai -> startKey i k ai =<< getNumCopies)
+		(\k ai -> startKey from i k ai =<< getNumCopies)
 		(withFilesInGit $ whenAnnexed $ start from i)
 		(fsckFiles o)
 	cleanupIncremental i
@@ -109,7 +109,7 @@ start from inc file key = do
 			numcopies <- getFileNumCopies file
 			case from of
 				Nothing -> go $ perform key file backend numcopies
-				Just r -> go $ performRemote key file backend numcopies r
+				Just r -> go $ performRemote key (Just file) backend numcopies r
   where
 	go = runFsck inc (mkActionItem (Just file)) key
 
@@ -129,8 +129,8 @@ perform key file backend numcopies = do
 
 {- To fsck a remote, the content is retrieved to a tmp file,
  - and checked locally. -}
-performRemote :: Key -> FilePath -> Backend -> NumCopies -> Remote -> Annex Bool
-performRemote key file backend numcopies remote =
+performRemote :: Key -> AssociatedFile -> Backend -> NumCopies -> Remote -> Annex Bool
+performRemote key afile backend numcopies remote =
 	dispatch =<< Remote.hasKey remote key
   where
 	dispatch (Left err) = do
@@ -147,10 +147,10 @@ performRemote key file backend numcopies remote =
 				return False
 	dispatch (Right False) = go False Nothing
 	go present localcopy = check
-		[ verifyLocationLogRemote key file remote present
+		[ verifyLocationLogRemote key (maybe (key2file key) id afile) remote present
 		, checkKeySizeRemote key remote localcopy
 		, checkBackendRemote backend key remote localcopy
-		, checkKeyNumCopies key (Just file) numcopies
+		, checkKeyNumCopies key afile numcopies
 		]
 	withtmp a = do
 		pid <- liftIO getPID
@@ -161,7 +161,7 @@ performRemote key file backend numcopies remote =
 		cleanup
 		cleanup `after` a tmp
 	getfile tmp = ifM (checkDiskSpace (Just (takeDirectory tmp)) key 0 True)
-		( ifM (Remote.retrieveKeyFileCheap remote key (Just file) tmp)
+		( ifM (Remote.retrieveKeyFileCheap remote key afile tmp)
 			( return (Just True)
 			, ifM (Annex.getState Annex.fast)
 				( return Nothing
@@ -173,12 +173,14 @@ performRemote key file backend numcopies remote =
 		)
 	dummymeter _ = noop
 
-startKey :: Incremental -> Key -> ActionItem -> NumCopies -> CommandStart
-startKey inc key ai numcopies =
+startKey :: Maybe Remote -> Incremental -> Key -> ActionItem -> NumCopies -> CommandStart
+startKey from inc key ai numcopies =
 	case Backend.maybeLookupBackendName (keyBackendName key) of
 		Nothing -> stop
 		Just backend -> runFsck inc ai key $
-			performKey key backend numcopies
+			case from of
+				Nothing -> performKey key backend numcopies
+				Just r -> performRemote key Nothing backend numcopies r
 
 performKey :: Key -> Backend -> NumCopies -> Annex Bool
 performKey key backend numcopies = do
diff --git a/doc/bugs/git-annex-fsck___34__-all__34___flag_doesn__39__t_work_for_special_remote.mdwn b/doc/bugs/git-annex-fsck___34__-all__34___flag_doesn__39__t_work_for_special_remote.mdwn
index b989505..80193cd 100644
--- a/doc/bugs/git-annex-fsck___34__-all__34___flag_doesn__39__t_work_for_special_remote.mdwn
+++ b/doc/bugs/git-annex-fsck___34__-all__34___flag_doesn__39__t_work_for_special_remote.mdwn
@@ -24,3 +24,5 @@ I tried to use `git-annex-fsck --all --from remote` to check files on a special
 ### Have you had any luck using git-annex before?
 Yes, it's been very helpful for managing large files between laptops, desktops, external storage, and remote storage.
 
+> Thanks for an excellent test case and a clear bug report. I've fixed this
+> bug. [[done]] --[[Joey]]

moreinfo needed
diff --git a/doc/bugs/addurl_pathdepth_description_misleading/comment_3_2744e42db662486b46e203a72c3e56c7._comment b/doc/bugs/addurl_pathdepth_description_misleading/comment_3_2744e42db662486b46e203a72c3e56c7._comment
new file mode 100644
index 0000000..45be251
--- /dev/null
+++ b/doc/bugs/addurl_pathdepth_description_misleading/comment_3_2744e42db662486b46e203a72c3e56c7._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2016-11-16T19:04:37Z"
+ content="""
+Seems to work as described here:
+
+	joey@darkstar:~/tmp/r>rm localhost__joey_blog_index.html 
+	joey@darkstar:~/tmp/r>git annex addurl --pathdepth 2 http://localhost/~joey/blog/index.html
+	addurl blog/index.html (downloading http://localhost/~joey/blog/index.html ...) 
+	/home/joey/tmp/r/ 100%[===========>]  40.70K  --.-KB/s    in 0s      
+	ok
+	(recording state in git...)
+	joey@darkstar:~/tmp/r>ls
+	blog/
+	joey@darkstar:~/tmp/r>ls blog
+	index.html
+
+It would probably help if you can provide a test case where it does not work
+as described.
+"""]]

comment
diff --git a/doc/forum/sync_--content__44___fatal_is_outside_repository_errors/comment_2_8f694afa77f5a835c826d29d46d44615._comment b/doc/forum/sync_--content__44___fatal_is_outside_repository_errors/comment_2_8f694afa77f5a835c826d29d46d44615._comment
new file mode 100644
index 0000000..ccaeeb4
--- /dev/null
+++ b/doc/forum/sync_--content__44___fatal_is_outside_repository_errors/comment_2_8f694afa77f5a835c826d29d46d44615._comment
@@ -0,0 +1,30 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2016-11-16T18:52:07Z"
+ content="""
+It would be helpful if you said what version of git-annex you are using.
+
+And, is your git-annex repository using the new experimental v6 format? One
+user reported a similar error message with a v6 git-annex repository. See
+[[bugs/assistant_crashes_in_TransferScanner]]
+
+Or might your repository be using direct mode?
+
+So, please paste in `git annex version` and `git annex info` output.
+
+It kind of looks like it's having difficulty determining where the top of
+the git repository is, or constructing a relative path to the git
+repository.
+
+Are there any symlinks in the path to /Users/andrew/notes ? Eg, is /Users
+a symlink, or /Users/andrew a symlink, or //Users/andrew/notes itself
+symlinked to elsewhere?
+
+Does only `git annex sync --content` fail? What if you run, eg
+`git annex copy --auto --to cloud` and `git annex get --auto --from cloud`,
+does that fail similarly, or does it succeed?
+
+You say it's only failing for some files. Do the filenames that it's
+failing on contain any non-ascii characters?
+"""]]

comment
diff --git a/doc/bugs/add_fails_with_v6_repo_when_four_levels_deep/comment_1_e308245bf81a536db6f9a2b743d912bf._comment b/doc/bugs/add_fails_with_v6_repo_when_four_levels_deep/comment_1_e308245bf81a536db6f9a2b743d912bf._comment
new file mode 100644
index 0000000..a5d988f
--- /dev/null
+++ b/doc/bugs/add_fails_with_v6_repo_when_four_levels_deep/comment_1_e308245bf81a536db6f9a2b743d912bf._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-11-16T18:49:09Z"
+ content="""
+I'm not able to reproduce the problem with your test case and git-annex
+version 6.20161012.
+
+Can you still reproduce it after upgrading?
+"""]]

moreinfo
diff --git a/doc/bugs/Adding_zip_or_7z_or_tar_archive_builds_for_windows.mdwn b/doc/bugs/Adding_zip_or_7z_or_tar_archive_builds_for_windows.mdwn
index 6cca008..ae1f7c5 100644
--- a/doc/bugs/Adding_zip_or_7z_or_tar_archive_builds_for_windows.mdwn
+++ b/doc/bugs/Adding_zip_or_7z_or_tar_archive_builds_for_windows.mdwn
@@ -1,3 +1,5 @@
 Having a windows build of Git-Annex in an archived format would be very usefull for automation, and deploy.
 Could it be possible to add this to the buildserver of gitannex?
 
+[[!tag moreinfo]]
+

comment
diff --git a/doc/bugs/Adding_zip_or_7z_or_tar_archive_builds_for_windows/comment_1_70480ffd417788f18cd75a9b625ecf3b._comment b/doc/bugs/Adding_zip_or_7z_or_tar_archive_builds_for_windows/comment_1_70480ffd417788f18cd75a9b625ecf3b._comment
new file mode 100644
index 0000000..3bd7381
--- /dev/null
+++ b/doc/bugs/Adding_zip_or_7z_or_tar_archive_builds_for_windows/comment_1_70480ffd417788f18cd75a9b625ecf3b._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-11-16T18:41:25Z"
+ content="""
+It would be helpful to have more details, such as an example of software
+distributed for windows that way, or documentation of how such an archive
+is used on windows.
+
+The git-annex Windows installer is a exe file that uses the NullSoft
+installation system. As far as I know that's pretty common in the Windows
+world.
+
+I don't see any point in zipping up the single exe. It would be possible to
+make a zip containing all the files that instlling the exe installs. But,
+the installation process has to integrate git-annex with git, it installs
+menu items, etc. A zip file would not be able to handle that integration.
+So its use seems limited to me.
+"""]]

comment
diff --git a/doc/bugs/When_stopping___96__git_annex_get__96___files_left_broken/comment_1_9392346203c561b88f30fa2ce7540b76._comment b/doc/bugs/When_stopping___96__git_annex_get__96___files_left_broken/comment_1_9392346203c561b88f30fa2ce7540b76._comment
new file mode 100644
index 0000000..4f90ddf
--- /dev/null
+++ b/doc/bugs/When_stopping___96__git_annex_get__96___files_left_broken/comment_1_9392346203c561b88f30fa2ce7540b76._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-11-16T18:36:34Z"
+ content="""
+Thing is, git-annex get does not update the file in place. Only once the
+entire file is downloaded, and its content is verified correct is it moved
+into a place where you can access it.
+
+So, it seems much more likely to me that the content of the file, as
+originally added to git-annex, was bad, and the it had just finished
+verifying the content and moving it into place when you interruped the
+command.
+
+Please check with `git annex fsck` on the file and see if it determines
+it has the content git-annex expects it to have.
+
+However, I notice you're using a v6 repository. Is the file an unlocked
+file? It's possible that in that specific case there could be a bug.
+I've interrupted `git annex get` on a nearly daily basis for years, but
+v6 is still experimental and not as well tested.
+"""]]

already fixed
diff --git a/doc/bugs/Single_space_in_file_name_causes_git_annex_add_to_fail.mdwn b/doc/bugs/Single_space_in_file_name_causes_git_annex_add_to_fail.mdwn
index 14f772c..0965621 100644
--- a/doc/bugs/Single_space_in_file_name_causes_git_annex_add_to_fail.mdwn
+++ b/doc/bugs/Single_space_in_file_name_causes_git_annex_add_to_fail.mdwn
@@ -51,3 +51,7 @@ Not sure whether this means that this bug is actually fixed or whether it's an a
 ### 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)
 
 Just starting out with it as a way of archiving some of my media seems to work great apart from this. Thanks a bunch!
+
+> This bug was already fixed in git-annex 6.20161031. I told the Debian
+> maintainer about the bug fix at the time; package has not been updated
+> yet. [[done]] on git-annex side. --[[Joey]] 

comment
diff --git a/doc/forum/vanilla_git_repo_as_special_remote__63__/comment_1_67e186265ae21f2cd8451750152f2a6d._comment b/doc/forum/vanilla_git_repo_as_special_remote__63__/comment_1_67e186265ae21f2cd8451750152f2a6d._comment
new file mode 100644
index 0000000..6539749
--- /dev/null
+++ b/doc/forum/vanilla_git_repo_as_special_remote__63__/comment_1_67e186265ae21f2cd8451750152f2a6d._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-11-16T18:30:12Z"
+ content="""
+You can use bup as a special remote, which will store the content in a git
+repository. But, not in a form that git diff can be used with.
+
+[[git-annex-diffdriver]] can be used to make `git diff` work on annexed
+files. For example:
+
+	export GIT_EXTERNAL_DIFF="git-annex diffdriver -- diff -u --"
+"""]]

diff --git a/doc/bugs/DBG__58___running___96____47__Users__47__joey__47__homebrew__47__opt__47__gpg-agent__47__bin__47__gpg-agent__39___for_testing_failed.mdwn b/doc/bugs/DBG__58___running___96____47__Users__47__joey__47__homebrew__47__opt__47__gpg-agent__47__bin__47__gpg-agent__39___for_testing_failed.mdwn
new file mode 100644
index 0000000..a3b85bd
--- /dev/null
+++ b/doc/bugs/DBG__58___running___96____47__Users__47__joey__47__homebrew__47__opt__47__gpg-agent__47__bin__47__gpg-agent__39___for_testing_failed.mdwn
@@ -0,0 +1,30 @@
+### Please describe the problem.
+Issue uploading to S3 remote (Dreamhost)
+
+### What steps will reproduce the problem?
+git-annex copy massart/f16_Web1/screencaptures/IMG_5159.MOV --to=cloud
+on my repo
+
+### What version of git-annex are you using? On what operating system?
+6.20161031-g0a58e94
+OS-X 10.11.6
+
+### Please provide any additional information below.
+I am using a different WIFI I haven't used before. Maybe it is blocking something…
+
+[[!format sh """
+git-annex copy massart/f16_Web1/screencaptures/IMG_5159.MOV --to=cloud
+copy massart/f16_Web1/screencaptures/IMG_5159.MOV (checking cloud...) (to cloud...) 
+17%           0.0 B/s 0sgpg: error running `/Users/joey/homebrew/opt/gpg-agent/bin/gpg-agent': probably not installed
+gpg: DBG: running `/Users/joey/homebrew/opt/gpg-agent/bin/gpg-agent' for testing failed: Configuration error
+gpg: can't connect to the agent: IPC connect call failed
+gpg: problem with the agent: No agent running
+35%       1021.8KB/s 30s
+  user error (gpg ["--quiet","--trust-model","always","--batch","--passphrase-fd","26","--symmetric","--force-mdc","--no-textmode"] exited 2)
+failed
+git-annex: copy: 1 failed
+"""]]
+
+### 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.
+

Added a comment: how to investigate
diff --git a/doc/forum/sync_--content__44___fatal_is_outside_repository_errors/comment_2_09c62e4abf4ccc0d2e030ef5e1bcdf71._comment b/doc/forum/sync_--content__44___fatal_is_outside_repository_errors/comment_2_09c62e4abf4ccc0d2e030ef5e1bcdf71._comment
new file mode 100644
index 0000000..fcca1b2
--- /dev/null
+++ b/doc/forum/sync_--content__44___fatal_is_outside_repository_errors/comment_2_09c62e4abf4ccc0d2e030ef5e1bcdf71._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="andrew"
+ avatar="http://cdn.libravatar.org/avatar/acc0ece1eedf07dd9631e7d7d343c435"
+ subject="how to investigate"
+ date="2016-11-16T15:37:01Z"
+ content="""
+Any thoughts? I am unsure how to investigate where this problem is. I assume these files are in my git repo or git-annex objects but I can't seem to find them using any search commands.
+
+Thanks,
+
+Andrew
+"""]]

removed
diff --git a/doc/special_remotes/S3/comment_27_2b6c92994533988b7dd9e6e6abc45835._comment b/doc/special_remotes/S3/comment_27_2b6c92994533988b7dd9e6e6abc45835._comment
deleted file mode 100644
index 4d996f8..0000000
--- a/doc/special_remotes/S3/comment_27_2b6c92994533988b7dd9e6e6abc45835._comment
+++ /dev/null
@@ -1,12 +0,0 @@
-[[!comment format=mdwn
- username="David_K"
- avatar="http://cdn.libravatar.org/avatar/09dd8544695feb9b8d8ee54e4ff0168d"
- subject="comment 27"
- date="2016-11-16T01:28:04Z"
- content="""
-I'd like to reiterate q
-
-Is there a way to tell the S3 backend to store the files as they are named locally, instead of by hashed content name? i.e., I've annexed foo/bar.txt and annex puts it in s3 as mybucket.name/foo/bar.txt instead of mybucket.name/GPGHMACSHA1-random.txt
-
-
-"""]]

Added a comment
diff --git a/doc/special_remotes/S3/comment_28_c4dafad82a898eafd6d9e3703fad2c48._comment b/doc/special_remotes/S3/comment_28_c4dafad82a898eafd6d9e3703fad2c48._comment
new file mode 100644
index 0000000..8649742
--- /dev/null
+++ b/doc/special_remotes/S3/comment_28_c4dafad82a898eafd6d9e3703fad2c48._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="David_K"
+ avatar="http://cdn.libravatar.org/avatar/09dd8544695feb9b8d8ee54e4ff0168d"
+ subject="comment 28"
+ date="2016-11-16T01:28:14Z"
+ content="""
+I'd like to reiterate a question that was unanswered above:
+
+Is there a way to tell the S3 backend to store the files as they are named locally, instead of by hashed content name? i.e., I've annexed foo/bar.txt and annex puts it in s3 as mybucket.name/foo/bar.txt instead of mybucket.name/GPGHMACSHA1-random.txt
+
+
+"""]]

Added a comment
diff --git a/doc/special_remotes/S3/comment_27_2b6c92994533988b7dd9e6e6abc45835._comment b/doc/special_remotes/S3/comment_27_2b6c92994533988b7dd9e6e6abc45835._comment
new file mode 100644
index 0000000..4d996f8
--- /dev/null
+++ b/doc/special_remotes/S3/comment_27_2b6c92994533988b7dd9e6e6abc45835._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="David_K"
+ avatar="http://cdn.libravatar.org/avatar/09dd8544695feb9b8d8ee54e4ff0168d"
+ subject="comment 27"
+ date="2016-11-16T01:28:04Z"
+ content="""
+I'd like to reiterate q
+
+Is there a way to tell the S3 backend to store the files as they are named locally, instead of by hashed content name? i.e., I've annexed foo/bar.txt and annex puts it in s3 as mybucket.name/foo/bar.txt instead of mybucket.name/GPGHMACSHA1-random.txt
+
+
+"""]]

Added a comment
diff --git a/doc/devblog/day_425__tor/comment_1_1dd41fa32eb3867d764f3238005b5b81._comment b/doc/devblog/day_425__tor/comment_1_1dd41fa32eb3867d764f3238005b5b81._comment
new file mode 100644
index 0000000..fe609ca
--- /dev/null
+++ b/doc/devblog/day_425__tor/comment_1_1dd41fa32eb3867d764f3238005b5b81._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="grawity@2ea26be48562f66fcb9b66307da72b1e2e37453f"
+ nickname="grawity"
+ avatar="http://cdn.libravatar.org/avatar/7003e967f47003bae82966aa373de8ef"
+ subject="comment 1"
+ date="2016-11-15T18:01:18Z"
+ content="""
+…or `pkexec`, which is present on many systems and generally integrates better with whatever DE/non-DE the user may be running.
+
+(OTOH, pkexec does not set up X11 access – then again, root helpers shouldn't need it.)
+"""]]

close
diff --git a/doc/bugs/Webapp_missing_CSS_and_JS_resources___40__401_Unauthorized__41__.mdwn b/doc/bugs/Webapp_missing_CSS_and_JS_resources___40__401_Unauthorized__41__.mdwn
index 0c3fc16..17fe3ac 100644
--- a/doc/bugs/Webapp_missing_CSS_and_JS_resources___40__401_Unauthorized__41__.mdwn
+++ b/doc/bugs/Webapp_missing_CSS_and_JS_resources___40__401_Unauthorized__41__.mdwn
@@ -30,4 +30,5 @@ operating system: darwin x86_64
 
 ### 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)
 
-
+> [[done]], my fix worked! Don't know entirely why it was needed..
+> --[[Joey]]

Added a comment
diff --git a/doc/bugs/Webapp_missing_CSS_and_JS_resources___40__401_Unauthorized__41__/comment_3_54bd11140dbe794182263c1a062ad031._comment b/doc/bugs/Webapp_missing_CSS_and_JS_resources___40__401_Unauthorized__41__/comment_3_54bd11140dbe794182263c1a062ad031._comment
new file mode 100644
index 0000000..cb6e9b4
--- /dev/null
+++ b/doc/bugs/Webapp_missing_CSS_and_JS_resources___40__401_Unauthorized__41__/comment_3_54bd11140dbe794182263c1a062ad031._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="christopher@5845ecd3cef9edadd4dc084df00e1fa60ce311eb"
+ nickname="christopher"
+ avatar="http://cdn.libravatar.org/avatar/4b722efb21f38d9944730c93727bc602"
+ subject="comment 3"
+ date="2016-11-15T12:15:37Z"
+ content="""
+Hi Joey,
+
+I installed git-annex using the homebrew recipe from https://github.com/Homebrew/homebrew-core/blob/master/Formula/git-annex.rb, OS X 10.11.6 (15G31)
+
+These are the dependencies reported by homebrew:
+
+Build: ghc ✔, cabal-install ✔, pkg-config ✔
+Required: gsasl ✔, libidn ✔, libmagic ✔, gnutls ✔, quvi ✔
+
+I've re-installed using \"brew install git-annex --HEAD\" to pull in your latest commit and I can confirm that everything works as expected and the /static/ resources load correctly.
+
+Thanks,
+Chris
+"""]]