Recent changes to this wiki:

Added a comment
diff --git a/doc/forum/How_big_can_a_git-annex_repo_get_and_still_be_reliable_and_fast__63__/comment_3_cc62f722b3e1db7d75d6976ef3854f94._comment b/doc/forum/How_big_can_a_git-annex_repo_get_and_still_be_reliable_and_fast__63__/comment_3_cc62f722b3e1db7d75d6976ef3854f94._comment
new file mode 100644
index 0000000..da8067a
--- /dev/null
+++ b/doc/forum/How_big_can_a_git-annex_repo_get_and_still_be_reliable_and_fast__63__/comment_3_cc62f722b3e1db7d75d6976ef3854f94._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="Mattt"
+ subject="comment 3"
+ date="2015-07-05T19:40:30Z"
+ content="""
+Thanks CandyAngel and Joey. That helped. I have transferred pretty much my entire repo into git annex now and have it sorted the way I want. Yay! 
+"""]]

Added a comment
diff --git a/doc/backends/comment_16_c68dfaeee2ef18f420f7e11ff5f604b9._comment b/doc/backends/comment_16_c68dfaeee2ef18f420f7e11ff5f604b9._comment
new file mode 100644
index 0000000..64c0102
--- /dev/null
+++ b/doc/backends/comment_16_c68dfaeee2ef18f420f7e11ff5f604b9._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="CandyAngel"
+ subject="comment 16"
+ date="2015-07-05T15:00:46Z"
+ content="""
+Or I could not be an idiot and tell you the command specifically looking up a key for a file: lookupkey
+
+    ## git annex lookupkey CG\ Cookie/Compositing\ in\ Blender/01_CompositingInBlender_SourceFiles.zip 
+    SHA256E-s744506832--08d2daced60b5eb6509044d5eefca82e7a6899350f49adc0083014229739515e.zip
+
+So to get the backend (if the first component is always the backend):
+
+    ## git annex lookupkey CG\ Cookie/Compositing\ in\ Blender/01_CompositingInBlender_SourceFiles.zip | cut -d- -f1
+    SHA256E
+"""]]

Added a comment
diff --git a/doc/backends/comment_15_b3445fd1f379346c642a27211c6c798b._comment b/doc/backends/comment_15_b3445fd1f379346c642a27211c6c798b._comment
new file mode 100644
index 0000000..3fc12af
--- /dev/null
+++ b/doc/backends/comment_15_b3445fd1f379346c642a27211c6c798b._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="CandyAngel"
+ subject="comment 15"
+ date="2015-07-05T14:54:18Z"
+ content="""
+It's not explicit, but 'git annex info $FILE' tells you the key, which has the backend as its first component:
+
+    ## git annex info CG\ Cookie/Compositing\ in\ Blender/01_CompositingInBlender_SourceFiles.zip 
+    file: CG Cookie/Compositing in Blender/01_CompositingInBlender_SourceFiles.zip
+    size: 744.51 megabytes
+    key: SHA256E-s744506832--08d2daced60b5eb6509044d5eefca82e7a6899350f49adc0083014229739515e.zip
+
+I don't think there are any situations where the first component of the key isn't the backend, but don't hold me to that, please :)
+"""]]

Added a comment: Backend of specified file
diff --git a/doc/backends/comment_14_57154dcd1041a33f220f9105b709be89._comment b/doc/backends/comment_14_57154dcd1041a33f220f9105b709be89._comment
new file mode 100644
index 0000000..4469602
--- /dev/null
+++ b/doc/backends/comment_14_57154dcd1041a33f220f9105b709be89._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="xelez0@57a58225d4e5b260555ebc4a9d0a8df85d1e971a"
+ nickname="xelez0"
+ subject="Backend of specified file"
+ date="2015-07-05T13:19:43Z"
+ content="""
+How can I determine backend of specified file? Looking over man pages and can't find it.
+"""]]

diff --git a/doc/forum/Robustness_on_failing_hardware.mdwn b/doc/forum/Robustness_on_failing_hardware.mdwn
new file mode 100644
index 0000000..ec32cbf
--- /dev/null
+++ b/doc/forum/Robustness_on_failing_hardware.mdwn
@@ -0,0 +1,30 @@
+Hi everyone,
+
+
+I've had a bad git-annex day and I left some musings on my first use of it. There's a question though at the end if you don't need to read that.
+
+
+today I've spend some time trying to deal with a failing SHA256E backend. Or more precise, I'm patienting a refurbished Athlon board[*] without case and that seems to give a lot of errors. I've put up some shielding at the SDRAM which helped a lot on the checksumming, but now its the network department is having a hard time. 
+
+This is basicly an effort to recover an old 1.5TB USB NTFS disks with bit rot, a failed ext4 and recover collections from other aging USB/desktop disks. There is some new hardware on the way, to restore another (proper) box with some ECC memory. That should fix my problems, I think. I've never dealt with a problem like this before. Before git-annex I would have been using rsync -azc or mostly -azu, but I've never had problems like this before. 
+
+It has me pondering a bit though. To help git-annex i've done manual rsync -azc transfers, with some although a very low success--I wonder if its the lack of casing, lack of ground, or simply the non-ecc that is the cause. But that is not really the question.
+
+rsync does not at first glance have an option to configure the amount of retries, but -azc does try and gives a checksum failure another try before giving up. I had never seen rsync do that before even though I've been using it for a decade. I guess that shows how rare this problem should be, but its still creeping me a bit. I've never had checksummed media file collections, so I really cant be sure about integrity, can I?
+
+The behaviour of the SHA256E backend is a bit hysterical in this environment. Running a full annex fsck always results in some bad files. The bigger the file the harder it is to get a checksum match. I guess if I wanted to continue I should wrap the fsck step in a shell script that can reinject and fsck again and does do not needless re-checks in one run. It should figure it out in the end with a bit of more time.
+
+My other reaction would be to throw more checksums at it, from simple to complex. Something between filesize and sha256. I guess the whole would then have some different modes of retries and behaviours of failure maybe. Or levels of trust in the integrity. Maybe using simpler checksums would make the situation more bearable, since the problem is not disk-related iow. if the file is there and has checked out ok, then the re-fsck itself and bad memory/shielding are the culprits. 
+
+tldr;
+
+git-annex has no retry at all. I have seen it can take a -i <keyfile> somewhere. For robustness, it would be nice if there was a rsync -c mode. It would confirm the object was transferred correctly too. My workflow is to 'annex fsck' at the remote after copying files there. Is it correct to presume that using 'annex move' in my case, would have made the sending repo dropping files even though the remote still has only corrupted copies?
+
+I'm new to git-annex but been wanting something like git annex for a long time. Made some attempts myself, and too pondered how to use venerable GIT but never figured something out. What I'm saying though is I may want to dig around to see what I can do with Haskell. 
+
+I'm thinking a backend with some more checksums, maybe then some option to fsck to request only partial check of the key. Has something like a faster/less-thorough fsck using smaller checksums ever come up? And might this be a way to go at this? What do you think.
+
+
+
+
+[*] Asus M2A7A-AM SE w/ AMD Athlon 64 X2 5200+ Dual Core 2.7 

Added a comment: Patched git-annex output
diff --git a/doc/bugs/git-annex_sync_under_windows_fails_by_using_itself_as_the_ssh_command/comment_2_18b3ddff003bcdd78779b35c900964c2._comment b/doc/bugs/git-annex_sync_under_windows_fails_by_using_itself_as_the_ssh_command/comment_2_18b3ddff003bcdd78779b35c900964c2._comment
new file mode 100644
index 0000000..3493cb7
--- /dev/null
+++ b/doc/bugs/git-annex_sync_under_windows_fails_by_using_itself_as_the_ssh_command/comment_2_18b3ddff003bcdd78779b35c900964c2._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="johannes.elferich@796088e47b21d72547837ed62ae5c5cb187830b3"
+ nickname="johannes.elferich"
+ subject="Patched git-annex output"
+ date="2015-07-04T02:12:51Z"
+ content="""
+You are right something weird is going on with the GIT_ANNEX_SSHOPTION variable even though I have no idea what....
+
+This is the output I get after patching:
+
+›git annex sync
+(\"GIT_ANNEX_SSHOPTION\",Nothing)
+commit  (recording state in git...)
+ok
+pull origin fatal: protocol error: bad line length character: (\"GI
+git-annex.exe: unknown command 35.89.33.17
+
+Usage: git-annex command [option ...]
+
+"""]]

commit example
diff --git a/doc/git-annex-proxy.mdwn b/doc/git-annex-proxy.mdwn
index 23621ea..570789c 100644
--- a/doc/git-annex-proxy.mdwn
+++ b/doc/git-annex-proxy.mdwn
@@ -25,6 +25,12 @@ To rename a directory:
 
 	git annex proxy -- git mv mydir newname
 
+To commit the changes to a specific file, first use git annex add to
+stage the changes in the index, and then proxy a commit:
+
+	git annex add myfile
+	git annex proxy -- git commit myfile -m foo
+
 # SEE ALSO
 
 [[git-annex]](1)

comment
diff --git a/doc/todo/commit_in_direct_mode/comment_1_7d9e62010905e0d70cb586534cc09a75._comment b/doc/todo/commit_in_direct_mode/comment_1_7d9e62010905e0d70cb586534cc09a75._comment
new file mode 100644
index 0000000..55454db
--- /dev/null
+++ b/doc/todo/commit_in_direct_mode/comment_1_7d9e62010905e0d70cb586534cc09a75._comment
@@ -0,0 +1,67 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-07-03T17:59:39Z"
+ content="""
+I am reluctant to make direct mode grow to replicate significant (and
+really quite complex) git commands like commit. Which is why I have not
+added this. 
+
+`git annex proxy` brings a lot of regular git commands to
+direct mode.
+
+It's possible to use it to make a commit in direct mode. You only have
+to manually `git annex add` the modified files first, to get them staged
+in the index.
+
+	joey@darkstar:~/tmp/a>date > newfile
+	joey@darkstar:~/tmp/a>echo modified > foo
+	joey@darkstar:~/tmp/a>git annex add newfile foo
+	add newfile ok
+	add foo ok
+	(recording state in git...)
+	joey@darkstar:~/tmp/a>git annex proxy -- git commit foo -m foo
+	ok
+	(recording state in git...)
+	[annex/direct/master 739c518] foo
+	 1 file changed, 1 insertion(+), 1 deletion(-)
+	joey@darkstar:~/tmp/a>git show
+	commit 739c518997cc9d0a21e920213394079fce9e7a11
+	Author: Joey Hess <joeyh@joeyh.name>
+	Date:   Fri Jul 3 14:04:19 2015 -0400
+	
+	    foo
+	
+	diff --git a/foo b/foo
+	index 4925a0e..0f22f36 120000
+	--- a/foo
+	+++ b/foo
+	@@ -1 +1 @@
+	-.git/annex/objects/fV/Zq/SHA256E-s30--79d01999a1e7d689136859f7462651dbe179b9c779c45d4e0b2815f426628b75/SHA256E-s30--79d01999a1e7d689136859f7462651dbe179b9c779c45d4e0b2815f426628b75
+	\ No newline at end of file
+	+.git/annex/objects/qw/8m/SHA256E-s9--4487e24377581c1a43c957c7700c8b49920de7b8500c05590cee74996ef73f42/SHA256E-s9--4487e24377581c1a43c957c7700c8b49920de7b8500c05590cee74996ef73f42
+	\ No newline at end of file
+	joey@darkstar:~/tmp/a>git annex proxy -- git commit -a -m added\ newfile
+	ok
+	[annex/direct/master 9abe7a4] added newfile
+	 1 file changed, 1 insertion(+)
+	 create mode 120000 newfile
+	joey@darkstar:~/tmp/a>git show
+	commit 9abe7a4fa083ea0e4529df0054f44f4e30d9e0ae
+	Author: Joey Hess <joeyh@joeyh.name>
+	Date:   Fri Jul 3 14:04:38 2015 -0400
+	
+	    added newfile
+	
+	diff --git a/newfile b/newfile
+	new file mode 120000
+	index 0000000..1bb8d0d
+	--- /dev/null
+	+++ b/newfile
+	@@ -0,0 +1 @@
+	+.git/annex/objects/23/q9/SHA256E-s30--42fb3eaea7c7932a9056e531f764ca83d117c69c79d4458f9860c6e525f8e498/SHA256E-s30--42fb3eaea7c7932a9056e531f764ca83d117c69c79d4458f9860c6e525f8e498
+	\ No newline at end of file
+
+This works because `git annex proxy` sets up a temporary work tree,
+using the content of the index. So you can commit any/all staged files.
+"""]]

fixed
diff --git a/doc/bugs/Android_build_missing_webapp.mdwn b/doc/bugs/Android_build_missing_webapp.mdwn
index 8f18725..dc9c4db 100644
--- a/doc/bugs/Android_build_missing_webapp.mdwn
+++ b/doc/bugs/Android_build_missing_webapp.mdwn
@@ -29,3 +29,11 @@ v5.20150617~g031b85a
 
 # End of transcript or log.
 """]]
+
+> I've reverted to the previous release, which included the webapp, afaik.
+> 
+> Unfortunately, the android autobuilder remains broken after I spent 12
+> hours fighting with it. Unsure when that will be resolved and a newer
+> release will be able to be made. 
+> 
+> Anyhow, the immediate bug is [[done]] --[[Joey]]

Added a comment: enable s3 remote on clone
diff --git a/doc/tips/using_Amazon_S3/comment_13_30bdbd217fd2b603984cf7d3a3dce266._comment b/doc/tips/using_Amazon_S3/comment_13_30bdbd217fd2b603984cf7d3a3dce266._comment
new file mode 100644
index 0000000..60e3c49
--- /dev/null
+++ b/doc/tips/using_Amazon_S3/comment_13_30bdbd217fd2b603984cf7d3a3dce266._comment
@@ -0,0 +1,37 @@
+[[!comment format=mdwn
+ username="james@2468840dc8f314e837e1fde99a5fb1b884fa993a"
+ nickname="james"
+ subject="enable s3 remote on clone"
+ date="2015-07-03T14:46:49Z"
+ content="""
+Hi,
+I am trying to enable access to my s3 area from a clone. I am running into this issue:
+
+~~~
+$ git annex enableremote mys3 
+enableremote mys3 (encryption update) (hybrid cipher with gpg key EA1CF14BD8467AFB) (gpg) gpg: decryption failed: secret key not available
+
+git-annex: user error (gpg [\"--batch\",\"--no-tty\",\"--use-agent\",\"--quiet\",\"--trust-model\",\"always\",\"--decrypt\"] exited 2)
+failed
+git-annex: enableremote: 1 failed
+~~~
+
+
+My gpg key is available :
+
+~~~
+$ gpg -K EA1CF14BD8467AFB
+sec   4096R/D8467AFB 2010-10-25
+uid                  James Richardson (email) <james@jamestechnotes.com>
+uid                  James Richardson <james.richardson.jr@gmail.com>
+uid       [ revoked] James Richardson (list) <jr@jamesr.biz>
+uid       [ revoked] James Richardson (James Richardson) <james@jamesr.biz>
+ssb   4096R/F90CF7F0 2010-10-25
+ssb   4096R/005D609B 2010-10-26
+~~~
+
+I would expect this to pop up a dialog asking me for my passphrase, as it will when I run the gpg command from a term.
+
+Any ideas?
+
+"""]]

Added a comment
diff --git a/doc/bugs/Installation_on_ArchLinux_fails/comment_4_be3a6b3955354fb56eec0371b8f32f6a._comment b/doc/bugs/Installation_on_ArchLinux_fails/comment_4_be3a6b3955354fb56eec0371b8f32f6a._comment
new file mode 100644
index 0000000..c88b405
--- /dev/null
+++ b/doc/bugs/Installation_on_ArchLinux_fails/comment_4_be3a6b3955354fb56eec0371b8f32f6a._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="CandyAngel"
+ subject="comment 4"
+ date="2015-07-03T08:11:08Z"
+ content="""
+I'll try to replicate the curl problem in a VM over the weekend.
+"""]]

Added a comment
diff --git a/doc/git-annex-copy/comment_2_599958b0a57d2f8f4383733d28ad9c8d._comment b/doc/git-annex-copy/comment_2_599958b0a57d2f8f4383733d28ad9c8d._comment
new file mode 100644
index 0000000..687018b
--- /dev/null
+++ b/doc/git-annex-copy/comment_2_599958b0a57d2f8f4383733d28ad9c8d._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="tomekwi"
+ subject="comment 2"
+ date="2015-07-03T05:17:12Z"
+ content="""
+By the way I’m running 5.20140717 – the version distributed by Fedora.
+"""]]

Added a comment: --all seems to do nothing
diff --git a/doc/git-annex-copy/comment_1_9be279110a112335bc72ee8c8a347da2._comment b/doc/git-annex-copy/comment_1_9be279110a112335bc72ee8c8a347da2._comment
new file mode 100644
index 0000000..026a2b1
--- /dev/null
+++ b/doc/git-annex-copy/comment_1_9be279110a112335bc72ee8c8a347da2._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="tomekwi"
+ subject="--all seems to do nothing"
+ date="2015-07-03T05:14:37Z"
+ content="""
+Hi,
+
+I want to back up all my files including previous versions on an external drive. I’ve tried these two commands – both of them exited instantly without producing any output:
+
+    $ git-annex copy --all --to=external-drive
+    $ git-annex copy --unused --to=external-drive
+"""]]

devblog
diff --git a/doc/devblog/day_294__back_focusing_on_bugs.mdwn b/doc/devblog/day_294__back_focusing_on_bugs.mdwn
new file mode 100644
index 0000000..0c7b510
--- /dev/null
+++ b/doc/devblog/day_294__back_focusing_on_bugs.mdwn
@@ -0,0 +1,7 @@
+Back, and have spent all day focusing on new bug reports. All told, I fixed
+4 bugs, followed up on all other bugs reported while I was away, and fixed
+the android autobuilder.
+
+The message backlog started the day at 250 or something, and is down to 178
+now. Looks like others have been following up to forum posts while I was
+away (thanks!) so those should clear quickly.

comment
diff --git a/doc/forum/Storing_copies_on_LTO_tapes__63__/comment_2_6d16d00c7ef8d846e370e1b298a7bc7a._comment b/doc/forum/Storing_copies_on_LTO_tapes__63__/comment_2_6d16d00c7ef8d846e370e1b298a7bc7a._comment
new file mode 100644
index 0000000..ed00112
--- /dev/null
+++ b/doc/forum/Storing_copies_on_LTO_tapes__63__/comment_2_6d16d00c7ef8d846e370e1b298a7bc7a._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""another approach"""
+ date="2015-07-02T22:25:25Z"
+ content="""
+You could make a special remote that streams the whole tar file from the
+tape, and uses `git annex setkey` to add each file from the tarball to the
+annex.
+
+Done this way, the first file that `git annex get` processed would actually
+cause *every* file to be gotten from the tape. As it continued on to
+subsequent files, the `git annex get` would see their content was already
+present and skip them.
+
+Of course, the downside is it works on a whole tape at a time, so if you
+don't want to load the whole tape into the filesystem, you wouldn't want to
+use this approach.
+"""]]

update
diff --git a/doc/forum/Storing_copies_on_LTO_tapes__63__/comment_1_9ae9ca3983f7d4209fd1de65d982731d._comment b/doc/forum/Storing_copies_on_LTO_tapes__63__/comment_1_9ae9ca3983f7d4209fd1de65d982731d._comment
index c734222..805042e 100644
--- a/doc/forum/Storing_copies_on_LTO_tapes__63__/comment_1_9ae9ca3983f7d4209fd1de65d982731d._comment
+++ b/doc/forum/Storing_copies_on_LTO_tapes__63__/comment_1_9ae9ca3983f7d4209fd1de65d982731d._comment
@@ -23,7 +23,9 @@ and keep a list. On shutdown, it then sorts the list, retrieves the keys
 in order, and runs `git annex setkey` to move the content into the annex.
 Still a little bit weird, because `git annex get` would seem to fail
 and then pause at the end for a long time, after which the files would
-actually end up being present. (Also, I er, removed `git annex setkey` in
+actually end up being present. 
+
+(Also, I er, removed `git annex setkey` in
 2011, because it didn't seem very useful, but this is in fact a use case
-for it, so I can bring it back if you get that far.)
+for it, so I've added it back now.)
 """]]

Brought back the setkey plumbing command that was removed in 2011, since we found a use case for it. Note that the command's syntax was changed for consistency.
diff --git a/CmdLine/GitAnnex.hs b/CmdLine/GitAnnex.hs
index 326dd3b..354f451 100644
--- a/CmdLine/GitAnnex.hs
+++ b/CmdLine/GitAnnex.hs
@@ -26,6 +26,7 @@ import qualified Command.ContentLocation
 import qualified Command.ExamineKey
 import qualified Command.FromKey
 import qualified Command.RegisterUrl
+import qualified Command.SetKey
 import qualified Command.DropKey
 import qualified Command.TransferKey
 import qualified Command.TransferKeys
@@ -159,6 +160,7 @@ cmds = concat
 	, Command.ExamineKey.cmd
 	, Command.FromKey.cmd
 	, Command.RegisterUrl.cmd
+	, Command.SetKey.cmd
 	, Command.DropKey.cmd
 	, Command.TransferKey.cmd
 	, Command.TransferKeys.cmd
diff --git a/Command/SetKey.hs b/Command/SetKey.hs
new file mode 100644
index 0000000..02118fb
--- /dev/null
+++ b/Command/SetKey.hs
@@ -0,0 +1,49 @@
+{- git-annex command
+ -
+ - Copyright 2010, 2015 Joey Hess <joey@kitenet.net>
+ -
+ - Licensed under the GNU GPL version 3 or higher.
+ -}
+
+module Command.SetKey where
+
+import Common.Annex
+import Command
+import Logs.Location
+import Annex.Content
+import Types.Key
+
+cmd :: [Command]
+cmd = [command "setkey" (paramPair paramKey paramPath) seek
+	SectionPlumbing "sets annexed content for a key"]
+
+seek :: CommandSeek
+seek = withWords start
+
+start :: [String] -> CommandStart
+start (keyname:file:[]) = do
+	showStart "setkey" file
+	next $ perform file (mkKey keyname)
+start _ = error "specify a key and a content file"
+
+mkKey :: String -> Key
+mkKey = fromMaybe (error "bad key") . file2key
+
+perform :: FilePath -> Key -> CommandPerform
+perform file key = do
+	-- the file might be on a different filesystem, so mv is used
+	-- rather than simply calling moveAnnex; disk space is also
+	-- checked this way.
+	ok <- getViaTmp key $ \dest ->
+		if dest /= file
+			then liftIO $
+				boolSystem "mv" [File file, File dest]
+		else return True
+	if ok
+		then next $ cleanup key
+		else error "mv failed!"
+
+cleanup :: Key -> CommandCleanup
+cleanup key = do
+	logStatus key InfoPresent
+	return True
diff --git a/debian/changelog b/debian/changelog
index 608a84d..795921a 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -9,6 +9,9 @@ git-annex (5.20150618) UNRELEASED; urgency=medium
   * assistant: Fix ANNEX_SHELL_DIR written to ~/.ssh/authorized_keys 
     in local pairing to be the absolute path to the repository, not "."
     This was a reversion caused by the relative path changes in 5.20150113.
+  * Brought back the setkey plumbing command that was removed in 2011, since
+    we found a use case for it. Note that the command's syntax was changed
+    for consistency.
 
  -- Joey Hess <id@joeyh.name>  Thu, 02 Jul 2015 12:31:14 -0400
 
diff --git a/doc/git-annex-dropkey.mdwn b/doc/git-annex-dropkey.mdwn
index 7a25e23..0db29f9 100644
--- a/doc/git-annex-dropkey.mdwn
+++ b/doc/git-annex-dropkey.mdwn
@@ -21,6 +21,8 @@ exist; using it can easily result in data loss.
 
 [[git-annex]](1)
 
+[[git-annex-setkey]](1)
+
 # AUTHOR
 
 Joey Hess <id@joeyh.name>
diff --git a/doc/git-annex-setkey.mdwn b/doc/git-annex-setkey.mdwn
new file mode 100644
index 0000000..439984c
--- /dev/null
+++ b/doc/git-annex-setkey.mdwn
@@ -0,0 +1,30 @@
+# NAME
+
+git-annex setkey - sets annexed content for a key
+
+# SYNOPSIS
+
+git annex setkey key file
+
+# DESCRIPTION
+
+This plumbing-level command makes the content of the specified key
+be set to the specified file. The file is moved into the annex.
+
+No checking is done that the file contains the expected contents of the key.
+So it's generally a better idea to use [[git-annex-reinject]](1) instead of
+this command.
+
+# SEE ALSO
+
+[[git-annex]](1)
+
+[[git-annex-reinject]](1)
+
+[[git-annex-dropkey]](1)
+
+# AUTHOR
+
+Joey Hess <id@joeyh.name>
+
+Warning: Automatically converted into a man page by mdwn2man. Edit with care.
diff --git a/doc/git-annex.mdwn b/doc/git-annex.mdwn
index a0d5a0b..7a3edf0 100644
--- a/doc/git-annex.mdwn
+++ b/doc/git-annex.mdwn
@@ -547,6 +547,13 @@ subdirectories).
   
   See [[git-annex-registerurl]](1) for details.
 
+* `setkey key file`
+
+  Moves a file into the annex as the content of a key.
+  
+  See [[git-annex-setkey]](1) for details.
+
+
 * `dropkey [key ...]`
 
   Drops annexed content for specified keys.

response
diff --git a/doc/forum/Storing_copies_on_LTO_tapes__63__/comment_1_9ae9ca3983f7d4209fd1de65d982731d._comment b/doc/forum/Storing_copies_on_LTO_tapes__63__/comment_1_9ae9ca3983f7d4209fd1de65d982731d._comment
new file mode 100644
index 0000000..c734222
--- /dev/null
+++ b/doc/forum/Storing_copies_on_LTO_tapes__63__/comment_1_9ae9ca3983f7d4209fd1de65d982731d._comment
@@ -0,0 +1,29 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-07-02T21:00:00Z"
+ content="""
+All your solutions are reasonable, but you're right that none of them
+avoid random-access. And git-annex is generally not built in a way that
+makes it easy to avoid random-access.
+
+But, I think it's tractable with a special remote.
+
+Consider a special remote that has two retrieval modes.
+In one mode, it always fails to retrieve keys, but keeps a list. In the
+second mode, it starts up by going through its list, retreives everything
+in order to a temporary directory, and then when asked to retrieve a key,
+just moves it from the temp dir into place. This is somewhat similar to how
+Amazon Glacier works, and like git-annex's glacier support, it would result
+in the first `git-annex get` failing, and a second `git annex get` being
+needed to finish the retrival.
+
+That could be improved.. Make the special remote fail to retrive keys,
+and keep a list. On shutdown, it then sorts the list, retrieves the keys
+in order, and runs `git annex setkey` to move the content into the annex.
+Still a little bit weird, because `git annex get` would seem to fail
+and then pause at the end for a long time, after which the files would
+actually end up being present. (Also, I er, removed `git annex setkey` in
+2011, because it didn't seem very useful, but this is in fact a use case
+for it, so I can bring it back if you get that far.)
+"""]]

response
diff --git a/doc/forum/Trouble_adding_ssh_remote_using_assistant_on_windows/comment_1_0055392bfead0dd1d9dc1a196a6e5269._comment b/doc/forum/Trouble_adding_ssh_remote_using_assistant_on_windows/comment_1_0055392bfead0dd1d9dc1a196a6e5269._comment
new file mode 100644
index 0000000..74a4ae0
--- /dev/null
+++ b/doc/forum/Trouble_adding_ssh_remote_using_assistant_on_windows/comment_1_0055392bfead0dd1d9dc1a196a6e5269._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-07-02T20:53:54Z"
+ content="""
+This particular feature is unfortunately currently broken on Windows.
+
+I have developed a fix, but am waiting on it getting into a library I use.
+See [[bugs/windows_ssh_webapp_password_entry_broken]].
+
+As a workaround, if you can manually set up a passwordless ssh key on
+Windows, and configure the remote server to let you log in using that key,
+the webapp can then be used to add a repository on the server.
+"""]]

comment
diff --git a/doc/forum/How_big_can_a_git-annex_repo_get_and_still_be_reliable_and_fast__63__/comment_2_6a7a3c372599eed7c52d5f54e5287577._comment b/doc/forum/How_big_can_a_git-annex_repo_get_and_still_be_reliable_and_fast__63__/comment_2_6a7a3c372599eed7c52d5f54e5287577._comment
new file mode 100644
index 0000000..fc05edd
--- /dev/null
+++ b/doc/forum/How_big_can_a_git-annex_repo_get_and_still_be_reliable_and_fast__63__/comment_2_6a7a3c372599eed7c52d5f54e5287577._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2015-07-02T20:44:09Z"
+ content="""
+Depending on the total size of the small files, you might consider a mixed
+repo, with the small files checked into git normally, and the larger files
+annexed. 
+
+The advantage is that you then don't need to use git-annex commands to
+manage the many small files. This will probably be faster, for except you
+won't need to `git annex get` a ton of small files, which will avoid a lot
+of overhead.
+
+Of course, if you have gigabytes of small files, that will result
+in a git repo gigabytes in size, and you will start to run into some of the
+scalability problems that git-annex addresses.
+"""]]

comment
diff --git a/doc/todo/easy_way_to_reproduce_normal_download_command/comment_1_26ddfa03fcf51250b963cb9511a38404._comment b/doc/todo/easy_way_to_reproduce_normal_download_command/comment_1_26ddfa03fcf51250b963cb9511a38404._comment
new file mode 100644
index 0000000..2c050ff
--- /dev/null
+++ b/doc/todo/easy_way_to_reproduce_normal_download_command/comment_1_26ddfa03fcf51250b963cb9511a38404._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-07-02T20:36:22Z"
+ content="""
+Separate options could be added, but I'm not sure they're needed.
+git-annex only ever runs one of curl or wget on a given system.
+
+Which one varies depending on what is installed (ie, it uses wget when
+available and otherwise uses curl), but as long as that's
+stable, you can just use annex.web-options to pass additional options to
+whichever one it runs.
+
+FWIW, --limit-rate works for both curl and wget, more or less the same.
+"""]]

fixed
diff --git a/doc/todo/__91__PATCH__93___Log.hs:_Add_missing_dash_to_--raw_option.mdwn b/doc/todo/__91__PATCH__93___Log.hs:_Add_missing_dash_to_--raw_option.mdwn
index 0a1ee55..9a4e925 100644
--- a/doc/todo/__91__PATCH__93___Log.hs:_Add_missing_dash_to_--raw_option.mdwn
+++ b/doc/todo/__91__PATCH__93___Log.hs:_Add_missing_dash_to_--raw_option.mdwn
@@ -31,3 +31,7 @@ index 9ee7f85..495c43c 100644
 2.4.4.408.g16da57c
 
 """]]
+
+> Thanks for the patch! Someone else reported a bug about it and I already
+> patched it when I noticed this, so you missed getting in the commit log..
+> this time! ;) [[done]] --[[Joey]]

comment
diff --git a/doc/forum/security_risk_presented_by_remote.log__63__/comment_6_6a3911dc346d506d4350b5aec7619462._comment b/doc/forum/security_risk_presented_by_remote.log__63__/comment_6_6a3911dc346d506d4350b5aec7619462._comment
new file mode 100644
index 0000000..0b331bf
--- /dev/null
+++ b/doc/forum/security_risk_presented_by_remote.log__63__/comment_6_6a3911dc346d506d4350b5aec7619462._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 6"""
+ date="2015-07-02T20:23:48Z"
+ content="""
+There are two cases there s3creds= can be in the remote.log.
+
+If you enabled gpg encryption, it stores the S3 creds there, encrypted with
+the gpg key you told it to use. So you can share the repo to users who don't
+have the gpg key, and they cannot access the S3 login credentials.
+
+If you didn't use gpg encryption, and you manually set `embedcreds=yes`
+then the s3creds= will contain the un-encrypted creds. 
+And like the docs for embedcreds says, you then need to be careful who
+you give the git repo to, since they can then access those S3 credentials.
+This is not a default configuration.
+
+(There was also the [[upgrades/insecure_embedded_creds]] bug in 2014.
+But, git-annex will detect repos with that problem and warns very verbosely
+about it.)
+"""]]

comment
diff --git a/doc/todo/git-annex_info___34__du__34___remote_support/comment_2_1547eb348bf30e5a06686aee082062f4._comment b/doc/todo/git-annex_info___34__du__34___remote_support/comment_2_1547eb348bf30e5a06686aee082062f4._comment
new file mode 100644
index 0000000..d7e59b6
--- /dev/null
+++ b/doc/todo/git-annex_info___34__du__34___remote_support/comment_2_1547eb348bf30e5a06686aee082062f4._comment
@@ -0,0 +1,45 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2015-07-02T20:04:19Z"
+ content="""
+Note that using `--in remote` also limits the display to files that
+are present in the specified remote, much as --exclude limits the display.
+
+	joey@darkstar:~/lib/sound/podcasts/Agile_in_3_Minutes>git annex info . --in archive-10
+	directory: .
+	local annex keys: 13
+	local annex size: 27.88 megabytes
+	annexed files in working tree: 13
+	size of annexed files in working tree: 27.88 megabytes
+	numcopies stats: 
+		numcopies +1: 9
+		numcopies +2: 4
+	repositories containing these files: 5
+		27.88 MB: 00000000-0000-0000-0000-000000000001 -- web
+	 	27.88 MB: 1b5ecc94-abb3-45f7-8f4c-5bc65f78d518 -- toshiba passport 1tb [passport]
+	 	27.88 MB: 587b9ccf-4548-4d6f-9765-27faecc4105f -- darkstar [here]
+	 	27.88 MB: 6fa26a5f-cb05-4ef0-951b-bc59266ee4e4 -- archive-10 [archive]
+	 	  8.3 MB: b0bb7176-98e6-457d-b68e-41bfd49be147 -- joey@gnu:~/lib/sound [gnu]
+	joey@darkstar:~/lib/sound/podcasts/Agile_in_3_Minutes>git annex info .
+	directory: .
+	local annex keys: 16
+	local annex size: 34.32 megabytes
+	annexed files in working tree: 16
+	size of annexed files in working tree: 34.32 megabytes
+	numcopies stats: 
+		numcopies +1: 9
+		numcopies +2: 4
+		numcopies +0: 3
+	repositories containing these files: 5
+		34.32 MB: 00000000-0000-0000-0000-000000000001 -- web
+	 	34.32 MB: 1b5ecc94-abb3-45f7-8f4c-5bc65f78d518 -- toshiba passport 1tb [passport]
+ 		34.32 MB: 587b9ccf-4548-4d6f-9765-27faecc4105f -- darkstar [here]
+ 		27.88 MB: 6fa26a5f-cb05-4ef0-951b-bc59266ee4e4 -- archive-10 [archive]
+	 	  8.3 MB: b0bb7176-98e6-457d-b68e-41bfd49be147 -- joey@gnu:~/lib/sound [gnu]
+
+In the first command above, it is only considering files that are in the archive-10 remote,
+and it shows what size those files are taking up on each listed repository. The second command
+considers all files and we can see that some other repos have files not present in the archive-10 remote.
+
+"""]]

comment
diff --git a/doc/todo/Set_total_storage_limit_for_special_remotes./comment_1_8945025ad54e28f48474f8931746a775._comment b/doc/todo/Set_total_storage_limit_for_special_remotes./comment_1_8945025ad54e28f48474f8931746a775._comment
new file mode 100644
index 0000000..0df5669
--- /dev/null
+++ b/doc/todo/Set_total_storage_limit_for_special_remotes./comment_1_8945025ad54e28f48474f8931746a775._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-07-02T20:01:42Z"
+ content="""
+This totally makes sense to want, but it's rather difficult to implement since
+multiple git-annex repos can all be uploading content to the same special
+remote, while disconnected from each other.
+"""]]

fixed via time machine
diff --git a/doc/todo/git-annex_info___34__du__34___remote_support.mdwn b/doc/todo/git-annex_info___34__du__34___remote_support.mdwn
index 42aa5bd..e20cdc9 100644
--- a/doc/todo/git-annex_info___34__du__34___remote_support.mdwn
+++ b/doc/todo/git-annex_info___34__du__34___remote_support.mdwn
@@ -38,3 +38,4 @@ just to be clear here, the problem isn't as much providing `du-like output`, whi
 
 i still think it would be nice to have a `du` command, just because it's a command "WTF" situation users seem to get stuck into.. but this issue is only about having this work on remote repositories. thanks! -- [[anarcat]]
 
+> Fixed via time machine. [[done]] --[[Joey]]
diff --git a/doc/todo/git-annex_info___34__du__34___remote_support/comment_1_9d3ac51bdf3bb749bc40a1bb05edbc76._comment b/doc/todo/git-annex_info___34__du__34___remote_support/comment_1_9d3ac51bdf3bb749bc40a1bb05edbc76._comment
new file mode 100644
index 0000000..5960792
--- /dev/null
+++ b/doc/todo/git-annex_info___34__du__34___remote_support/comment_1_9d3ac51bdf3bb749bc40a1bb05edbc76._comment
@@ -0,0 +1,30 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-07-02T19:58:10Z"
+ content="""
+Actually, this was added in version 5.20150420, when info is run
+with a directory parameter.
+
+	joey@darkstar:~/lib/sound/misc>git annex info .
+	directory: .
+	local annex keys: 2
+	local annex size: 10.5 megabytes
+	annexed files in working tree: 21
+	size of annexed files in working tree: 288.98 megabytes
+	numcopies stats: 
+		numcopies +3: 19
+		numcopies +4: 2
+	repositories containing these files: 11
+	 	288.98 MB: 0c443de8-e644-11df-acbf-f7cd7ca6210d -- oldgnu
+	 	288.98 MB: 1b5ecc94-abb3-45f7-8f4c-5bc65f78d518 -- toshiba passport 1tb [passport]
+	 	288.98 MB: 6fa26a5f-cb05-4ef0-951b-bc59266ee4e4 -- archive-10 [archive]
+	 	288.98 MB: 7570b02e-15e9-11e0-adf0-9f3f94cb2eaa -- archive-4 sata drive
+	 	288.98 MB: 8da3593e-63d2-11e1-a026-43b95a8b93d2 -- archive-7 sata drive
+	 	288.98 MB: b0bb7176-98e6-457d-b68e-41bfd49be147 -- joey@gnu:~/lib/sound [gnu]
+	 	288.98 MB: b238695e-e617-11df-9d8b-c350f0825fb0 -- turtle internal [turtle]
+	 	288.98 MB: ca9c5d52-f03a-11df-ac14-6b772ffe59f9 -- archive-5 sata drive
+	 	288.98 MB: f1c0ce8d-d848-4d21-988c-dd78eed172e8 -- archive-8 sata drive
+	 	  10.5 MB: 587b9ccf-4548-4d6f-9765-27faecc4105f -- darkstar [here]
+
+"""]]

comment and warning
diff --git a/doc/bugs/Corrupted_.git__47__annex__47__index_when_running_assistant/comment_6_f0999dbd00e06ab2cbf68b58527c2b9b._comment b/doc/bugs/Corrupted_.git__47__annex__47__index_when_running_assistant/comment_6_f0999dbd00e06ab2cbf68b58527c2b9b._comment
new file mode 100644
index 0000000..f11e80b
--- /dev/null
+++ b/doc/bugs/Corrupted_.git__47__annex__47__index_when_running_assistant/comment_6_f0999dbd00e06ab2cbf68b58527c2b9b._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 6"""
+ date="2015-07-02T19:14:40Z"
+ content="""
+Yeah, --prune=now is bad news when using git-annex. At least, if
+you might be doing it at the same time that git-annex is staging
+objects in the index.
+
+Using it in combination with annex.alwayscommit=false is a particularly
+foot-shootish thing. I've added a warning to its documentation.
+
+`git gc` uses a lock file, `.git/gc.pid`. It might be possible for
+git-annex to hold that lock when it's in the process of staging and
+committing objects, to avoid `git gc` running at such times.
+"""]]
diff --git a/doc/git-annex.mdwn b/doc/git-annex.mdwn
index 45b02ec..a0d5a0b 100644
--- a/doc/git-annex.mdwn
+++ b/doc/git-annex.mdwn
@@ -862,6 +862,10 @@ Here are all the supported configuration settings.
   commit the data by running `git annex merge` (or by automatic merges)
   or `git annex sync`.
 
+  Note that you beware running `git gc` if using this configuration,
+  since it could garbage collect objects that are staged in git-annex's
+  index but not yet committed.
+
 * `annex.hardlink`
 
   Set this to `true` to make file contents be hard linked into the

assistant: Fix local pairing to not include newline in ssh pubkey, which is rejected on the other end for security reasons.
diff --git a/Assistant/WebApp/Configurators/Pairing.hs b/Assistant/WebApp/Configurators/Pairing.hs
index beaf57f..039676a 100644
--- a/Assistant/WebApp/Configurators/Pairing.hs
+++ b/Assistant/WebApp/Configurators/Pairing.hs
@@ -223,11 +223,12 @@ startLocalPairing stage oncancel alert muuid displaysecret secret = do
 	 - background. -}
 	thread <- liftAssistant $ asIO $ do
 		keypair <- liftIO $ genSshKeyPair
+		let pubkey = either error id $ validateSshPubKey $ sshPubKey keypair
 		pairdata <- liftIO $ PairData
 			<$> getHostname
 			<*> myUserName
 			<*> pure reldir
-			<*> pure (sshPubKey keypair)
+			<*> pure pubkey
 			<*> (maybe genUUID return muuid)
 		let sender = multicastPairMsg Nothing secret pairdata
 		let pip = PairingInProgress secret Nothing keypair pairdata stage
diff --git a/debian/changelog b/debian/changelog
index a91b849..fc8b397 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -4,6 +4,8 @@ git-annex (5.20150618) UNRELEASED; urgency=medium
   * assistant --autostart: First any daemons that are already running,
     which might be left over from a previous login session and so unable to
     use the ssh agent of a new login session.
+  * assistant: Fix local pairing to not include newline in ssh pubkey,
+    which is rejected on the other end for security reasons.
 
  -- Joey Hess <id@joeyh.name>  Thu, 02 Jul 2015 12:31:14 -0400
 
diff --git a/doc/bugs/local_pair_fails_if_non-ascii_characters_present_on_annex_path/comment_4_c6d6fa60e71895b7c0c68cc75cd7c5cc._comment b/doc/bugs/local_pair_fails_if_non-ascii_characters_present_on_annex_path/comment_4_c6d6fa60e71895b7c0c68cc75cd7c5cc._comment
new file mode 100644
index 0000000..7ecbe91
--- /dev/null
+++ b/doc/bugs/local_pair_fails_if_non-ascii_characters_present_on_annex_path/comment_4_c6d6fa60e71895b7c0c68cc75cd7c5cc._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2015-07-02T18:32:16Z"
+ content="""
+In comment 2, we see a message containing a ssh key with a newline at the
+end. That is the control character it's objecting to, and it has good
+security reasons to not allow newlines in there (multiline ssh keys could
+result in a ~/.ssh/authorized_keys that runs arbitrary commands).
+
+I was able to reproduce that myself. The problem was that the assistant
+didn't remove newlines when sending the ssh key. Fixed it.
+
+This bug report is **closed**, for the second time.
+If you see this message using any newer version of git-annex,
+please file a new bug report.
+"""]]

cannot reproduce
diff --git a/doc/bugs/view_fails_with___34__invalid_character__34__/comment_1_7c5447729352f75afd0bde1daf0f849f._comment b/doc/bugs/view_fails_with___34__invalid_character__34__/comment_1_7c5447729352f75afd0bde1daf0f849f._comment
new file mode 100644
index 0000000..71d4f45
--- /dev/null
+++ b/doc/bugs/view_fails_with___34__invalid_character__34__/comment_1_7c5447729352f75afd0bde1daf0f849f._comment
@@ -0,0 +1,34 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-07-02T18:18:22Z"
+ content="""
+It seems like you have some kind of system misconfiguration,
+resulting in setlocale(3) failing. Probably `LC_ALL` is set to a locale
+that is not available or is somehow broken.
+
+I tested by setting metadata to a completely bogus unicode value, and it
+all works ok here:
+
+	joey@darkstar:~/tmp/annex>git annex metadata -s person=$(perl -le "print chr(0x99999999)")  you
+	Wide character in print at -e line 1.
+	metadata you 
+	  lastchanged=2015-07-02@18-23-34
+	  person=�������
+	  person-lastchanged=2015-07-02@18-23-34
+	ok
+	(recording state in git...)
+	joey@darkstar:~/tmp/annex>git annex metadata you
+	metadata you 
+	  lastchanged=2015-07-02@18-23-34
+	  person=�������
+	  person-lastchanged=2015-07-02@18-23-34
+	ok
+	joey@darkstar:~/tmp/annex>git annex view person='*'
+	view  (searching...)
+	
+	Switched to branch 'views/person=_'
+	ok
+	joey@darkstar:~/tmp/annex#person=_>ls
+	Gödel/  \376\202\231\246\231\246\231/
+"""]]

assistant --autostart: First any daemons that are already running, which might be left over from a previous login session and so unable to use the ssh agent of a new login session.
diff --git a/Command/Assistant.hs b/Command/Assistant.hs
index 97bc08c..8a916aa 100644
--- a/Command/Assistant.hs
+++ b/Command/Assistant.hs
@@ -91,6 +91,12 @@ autoStart startdelay = do
   where
 	go haveionice program dir = do
 		setCurrentDirectory dir
+		-- First stop any old daemon running in this directory, which
+		-- might be a leftover from an old login session. Such a
+		-- leftover might be left in an environment where it is
+		-- unavble to use the ssh agent or other login session
+		-- resources.
+		void $ boolSystem program [Param "assistant", Param "--stop"]
 		if haveionice
 			then boolSystem "ionice" (Param "-c3" : Param program : baseparams)
 			else boolSystem program baseparams
diff --git a/debian/changelog b/debian/changelog
index 80bf514..a91b849 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,6 +1,9 @@
 git-annex (5.20150618) UNRELEASED; urgency=medium
 
   * log: Fix reversion introduced in version 5.20150528 that broke this command.
+  * assistant --autostart: First any daemons that are already running,
+    which might be left over from a previous login session and so unable to
+    use the ssh agent of a new login session.
 
  -- Joey Hess <id@joeyh.name>  Thu, 02 Jul 2015 12:31:14 -0400
 
diff --git a/doc/bugs/kill_git-annex_assistant_on_logout.mdwn b/doc/bugs/kill_git-annex_assistant_on_logout.mdwn
index 0640a5a..7c3a5af 100644
--- a/doc/bugs/kill_git-annex_assistant_on_logout.mdwn
+++ b/doc/bugs/kill_git-annex_assistant_on_logout.mdwn
@@ -1,3 +1,29 @@
 When you logout of any x session git-annex does not get killed.
 This means that if you login again git-annex will still try to use the ssh-agent from the last session which doesn't run anymore.
 This leads to countless password queries unless you use a passwordless key.
+
+> I've fixed this, though maybe not in an ideal way.
+> 
+> There's no way to make a XDG desktop file run a command on logout, that I
+> can see. That would have been my first choice.
+> 
+> So, I thought I'd just have the assistant not run setsid, so it's part of
+> the current login session and would get killed automatically on logout. 
+> I was surprised that this didn't seem to work, on a system using logind.
+> Even when the desktop file ran git-annex with --foreground, it was not
+> stopped on logout. This may be because logind defaults to
+> KillUserProcesses=false,
+> although I'm not sure why processes that are part of the login session
+> are not killed at least.
+> 
+> What I have settled on is to leave the daemon running after logout, 
+> but on a new login have the `git annex assistant --autostart` kill the
+> old daemon and start a new one.
+> 
+> Only possible problem with that is there will be a small window after
+> login where the old daemon is running. It might slip in a password prompt
+> there, using the new DISPLAY. At least it won't flood, and even a single
+> password prompt is pretty unlikely.
+> 
+> I am tenatively going to call this [[done]]. Seems to me that logind
+> could be improved though. --[[Joey]]

merge bugs
diff --git a/doc/bugs/Endless_SSH_password_prompts.mdwn b/doc/bugs/Endless_SSH_password_prompts.mdwn
index fad730a..6a180f2 100644
--- a/doc/bugs/Endless_SSH_password_prompts.mdwn
+++ b/doc/bugs/Endless_SSH_password_prompts.mdwn
@@ -32,3 +32,7 @@ I don't understand why this is happening.
 > line, they can also read the dialog box ssh pops up, ignore the 
 > misleading "passphrase request" in the title, and see that it's actually
 > prompting about a host key change. --[[Joey]]
+>
+> Update: See [[bugs/kill_git-annex_assistant_on_logout]] -- the fact that
+> it happened after logging back in suggests that was the actual cause of
+> this problem. --[[Joey]]
diff --git a/doc/bugs/flooding_me_with_ssh_password_prompts.mdwn b/doc/bugs/flooding_me_with_ssh_password_prompts.mdwn
index 191ad02..0d513d4 100644
--- a/doc/bugs/flooding_me_with_ssh_password_prompts.mdwn
+++ b/doc/bugs/flooding_me_with_ssh_password_prompts.mdwn
@@ -40,3 +40,8 @@ It's unclear - i guess you need to setup git-annex to autostart and sync with re
 ### What version of git-annex are you using? On what operating system?
 
 5.20140927~bpo70+3 on debian wheezy.
+
+> The git-annex daemon being a "leftover" from a previous session seems
+> like the root cause. We have a new bug for this,
+> [[bugs/kill_git-annex_assistant_on_logout]], so I am going to close this
+> one as a dup. [[done]] --[[Joey]]
diff --git a/doc/bugs/kill_git-annex_assistant_on_logout/comment_1_35ad241515014f1c85668c6152538fb9._comment b/doc/bugs/kill_git-annex_assistant_on_logout/comment_1_35ad241515014f1c85668c6152538fb9._comment
new file mode 100644
index 0000000..824fcbf
--- /dev/null
+++ b/doc/bugs/kill_git-annex_assistant_on_logout/comment_1_35ad241515014f1c85668c6152538fb9._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-07-02T17:05:15Z"
+ content="""
+Thanks, some people have reported repeated ssh-agent prompts, and this is
+the first one that fingered logout as contributing to the problem.
+(Reading through the past reports, that all had hints about logout.)
+
+So, we need to get a desktop file to stop git-annex on logout. If that's
+even possible.
+"""]]

comment
diff --git a/doc/bugs/Interrupted_command_broke_encfs_repository/comment_1_0b5fd2ca4b067becb930206e0ee82b3d._comment b/doc/bugs/Interrupted_command_broke_encfs_repository/comment_1_0b5fd2ca4b067becb930206e0ee82b3d._comment
new file mode 100644
index 0000000..957fa56
--- /dev/null
+++ b/doc/bugs/Interrupted_command_broke_encfs_repository/comment_1_0b5fd2ca4b067becb930206e0ee82b3d._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-07-02T16:57:56Z"
+ content="""
+git-annex contains no code whatsoever that writes to .git/config. It relies
+entirely on `git config` to write that file. I'm pretty sure that `git
+config` doesn't contain code to write garbage (in this case a symlink
+target belonging to another file) to the .git/config file either.
+
+The fact that you're having IO errors also points strongly at this being
+a level above userspace, so either encfs or the SD card. I think your tech
+stack contains at least one POS (namely encfs), and probably more problems
+(SD card, whatever nonsense filesystem Android is using for it, etc).
+"""]]

comment
diff --git a/doc/bugs/Installation_on_ArchLinux_fails/comment_3_848fcafc5a3ffcc6641aa2dc3bd8286f._comment b/doc/bugs/Installation_on_ArchLinux_fails/comment_3_848fcafc5a3ffcc6641aa2dc3bd8286f._comment
new file mode 100644
index 0000000..53298bf
--- /dev/null
+++ b/doc/bugs/Installation_on_ArchLinux_fails/comment_3_848fcafc5a3ffcc6641aa2dc3bd8286f._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2015-07-02T16:38:51Z"
+ content="""
+Not a whole lot I can do about this.. We can update install/ArchLinux
+and that's about it. Probably more productive to get in touch with the
+maintainer of the AUR package if it needs fixed.
+
+But, ArchHaskell seems promising. Much better than the hacks used to build
+the git-annex-bin AUR, IMHO. Since I'm not an Arch user, and don't
+understand the distro (on a number of levels it seems very puzzling to
+me..), I am reluctant to update the documentation myself to say to use it, but
+if it makes sense to point users at haskell-core, by all means update the
+docs to do so.
+
+(Any details about the curl thing?)
+"""]]

comment
diff --git a/doc/todo/S3_fsck_support/comment_3_2b96f61188b2ada729a284e95fc89dab._comment b/doc/todo/S3_fsck_support/comment_3_2b96f61188b2ada729a284e95fc89dab._comment
new file mode 100644
index 0000000..fea0477
--- /dev/null
+++ b/doc/todo/S3_fsck_support/comment_3_2b96f61188b2ada729a284e95fc89dab._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2015-07-02T16:43:03Z"
+ content="""
+Not knowing how S3's backend is implemented, I have to assume that, in
+order to get the advertised number of 9's of reliability, it involves some
+replication of data, as well as some method to detect if a bit has flipped
+or a drive has died, and recover.
+
+This is requesting that git-annex ask S3 for a md5sum, and compare it
+against a md5sum that it, presumably, keeps track of locally. If the two
+are different, git-annex could tell that S3 has lost data. But, git-annex is
+in a much worse position to tell if S3 has lost data then S3 itself is.
+It seems very unlikely that this extra checking would ever detect a problem
+that S3 didn't itself detect and fix (or in the 0.00001% case, 
+fail to fix and delete the lost file?)
+
+Bit flips during transfer seem more likely than that. `poContentMD5` could
+help guard against those.
+"""]]

log: Fix reversion introduced in version 5.20150528 that broke this command.
diff --git a/Command/Log.hs b/Command/Log.hs
index 9ee7f85..495c43c 100644
--- a/Command/Log.hs
+++ b/Command/Log.hs
@@ -151,7 +151,7 @@ getLog key os = do
 		[ Param "log"
 		, Param "-z"
 		, Param "--pretty=format:%ct"
-		, Param "-raw"
+		, Param "--raw"
 		, Param "--abbrev=40"
 		, Param "--remove-empty"
 		] ++ os ++
diff --git a/Test.hs b/Test.hs
index 95f4af2..9f211d2 100644
--- a/Test.hs
+++ b/Test.hs
@@ -180,6 +180,7 @@ unitTests :: String -> TestTree
 unitTests note = testGroup ("Unit Tests " ++ note)
 	[ testCase "add sha1dup" test_add_sha1dup
 	, testCase "add extras" test_add_extras
+	, testCase "log" test_log
 	, testCase "import" test_import
 	, testCase "reinject" test_reinject
 	, testCase "unannex (no copy)" test_unannex_nocopy
@@ -282,6 +283,10 @@ test_add_extras = intmpclonerepo $ do
 	annexed_present wormannexedfile
 	checkbackend wormannexedfile backendWORM
 
+test_log :: Assertion
+test_log = intmpclonerepo $ do
+	git_annex "log" [annexedfile] @? "log failed"
+
 test_import :: Assertion
 test_import = intmpclonerepo $ Utility.Tmp.withTmpDir "importtest" $ \importdir -> do
 	(toimport1, importf1, imported1) <- mktoimport importdir "import1"
diff --git a/debian/changelog b/debian/changelog
index 4f35454..80bf514 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+git-annex (5.20150618) UNRELEASED; urgency=medium
+
+  * log: Fix reversion introduced in version 5.20150528 that broke this command.
+
+ -- Joey Hess <id@joeyh.name>  Thu, 02 Jul 2015 12:31:14 -0400
+
 git-annex (5.20150617) unstable; urgency=medium
 
   * Now supports git annex sync --all --content to sync all versions of all
diff --git a/doc/bugs/log_fails_with_-raw_error.mdwn b/doc/bugs/log_fails_with_-raw_error.mdwn
index 86abd5d..553c507 100644
--- a/doc/bugs/log_fails_with_-raw_error.mdwn
+++ b/doc/bugs/log_fails_with_-raw_error.mdwn
@@ -43,3 +43,5 @@ upgrade supported from repository versions: 0 1 2 4
 """]]
 
 --[[anarcat]]
+
+> Fixed to use --raw, and added a test case. [[done]] --[[Joey]]
diff --git a/doc/bugs/log_fails_with_-raw_error/comment_1_dcb3ff1a076c81472cd471254946a868._comment b/doc/bugs/log_fails_with_-raw_error/comment_1_dcb3ff1a076c81472cd471254946a868._comment
new file mode 100644
index 0000000..efdf0dc
--- /dev/null
+++ b/doc/bugs/log_fails_with_-raw_error/comment_1_dcb3ff1a076c81472cd471254946a868._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-07-02T16:18:09Z"
+ content="""
+I can reproduce this with debian unstable. It is a reversion introduced
+in version 5.20150528 of git-annex.
+"""]]

followup
diff --git a/doc/bugs/git-annex_sync_under_windows_fails_by_using_itself_as_the_ssh_command/comment_1_b726337841cca318bf0a54f0e6240d86._comment b/doc/bugs/git-annex_sync_under_windows_fails_by_using_itself_as_the_ssh_command/comment_1_b726337841cca318bf0a54f0e6240d86._comment
new file mode 100644
index 0000000..bfa2a0a
--- /dev/null
+++ b/doc/bugs/git-annex_sync_under_windows_fails_by_using_itself_as_the_ssh_command/comment_1_b726337841cca318bf0a54f0e6240d86._comment
@@ -0,0 +1,36 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-07-02T15:50:12Z"
+ content="""
+Based on the usage output, it seems to be running a recent enough version
+of git-annex, which should notice if it's being run as a proxy for ssh.
+
+Some kind of problem with the environment variables used to communicate
+with the git-annex proxy seems like the most likely problem.
+But, I am not able to reproduce this problem on Windows (XP) here.
+The `GIT_SSH` env var is clearly being set, or git wouldn't try to run
+git-annex as ssh. The `GIT_ANNEX_SSHOPTION` env var is set in the same way
+as `GIT_SSH`. Maybe git-annex is failing to see it for some reason?
+
+Since you're comfortable with building git-annex from source, maybe you can
+try some simple patches to debug this?
+
+Here's the first patch I'd suggest. it will make git-annex print out
+what value, if any, it's seeing for `GIT_ANNEX_SSHOPTION`. Note that you'll
+need to install the patched git-annex into the path.
+
+	diff --git a/CmdLine/GitAnnex.hs b/CmdLine/GitAnnex.hs
+	index 326dd3b..b612dbb 100644
+	--- a/CmdLine/GitAnnex.hs
+	+++ b/CmdLine/GitAnnex.hs
+	@@ -225,6 +225,8 @@ run args = do
+	 #ifdef WITH_EKG
+	 	_ <- forkServer "localhost" 4242
+	 #endif
+	+	v <- getEnv sshOptionsEnv
+	+	print (sshOptionsEnv, v)
+	 	go envmodes
+	   where
+	 	go [] = dispatch True args cmds gitAnnexOptions [] header Git.CurrentRepo.get
+"""]]

comment
diff --git a/doc/bugs/Resource_temporarily_unavailable_when_running_enableremote/comment_1_14a5135c2e822129972feb570e453bc8._comment b/doc/bugs/Resource_temporarily_unavailable_when_running_enableremote/comment_1_14a5135c2e822129972feb570e453bc8._comment
new file mode 100644
index 0000000..6fce74e
--- /dev/null
+++ b/doc/bugs/Resource_temporarily_unavailable_when_running_enableremote/comment_1_14a5135c2e822129972feb570e453bc8._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-07-02T15:45:13Z"
+ content="""
+So it's writing the creds file that's failing. The only thing unusual
+about this file write is that it's done with a umask of 0077.
+
+Seeing what strace has to say about it would probably be useful..
+"""]]

Added a comment
diff --git a/doc/forum/How_big_can_a_git-annex_repo_get_and_still_be_reliable_and_fast__63__/comment_1_99e7e1b178bbb17fffea0892538d4049._comment b/doc/forum/How_big_can_a_git-annex_repo_get_and_still_be_reliable_and_fast__63__/comment_1_99e7e1b178bbb17fffea0892538d4049._comment
new file mode 100644
index 0000000..84252ba
--- /dev/null
+++ b/doc/forum/How_big_can_a_git-annex_repo_get_and_still_be_reliable_and_fast__63__/comment_1_99e7e1b178bbb17fffea0892538d4049._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="CandyAngel"
+ subject="comment 1"
+ date="2015-06-30T07:17:48Z"
+ content="""
+It can actually get really big and still be okay to use, if you follow the [tips page for annexs with lots of files](/tips/Repositories with large number of files).
+
+Mine is still reasonably responsive at 10 million files! Iterating over it all (git annex info, deduping) is really painful though, but it'd be like that without git-annex..
+"""]]

Added a comment
diff --git a/doc/forum/Restoring_files__63__/comment_1_735b98419b3ba6207cc364426b03ce74._comment b/doc/forum/Restoring_files__63__/comment_1_735b98419b3ba6207cc364426b03ce74._comment
new file mode 100644
index 0000000..81cf361
--- /dev/null
+++ b/doc/forum/Restoring_files__63__/comment_1_735b98419b3ba6207cc364426b03ce74._comment
@@ -0,0 +1,40 @@
+[[!comment format=mdwn
+ username="Chel"
+ subject="comment 1"
+ date="2015-06-30T06:32:59Z"
+ content="""
+If there are no branches, other than git-annex, then you do not have git history.
+
+If it is really the old repository with deleted branches and not a newly created
+one, then there is a possibility, that the git history has not been fully
+deleted/garbage-collected yet (i.e. there are old objects and packs in
+`.git/objects` and `.git/objects/pack`). It that case:
+
+1. *Do not run* git commands until you create a backup of the .git directory,
+   because some usual git commands automatically launch `git gc --auto`, which
+   removes some old unreachable objects (and maybe reflog entries).
+
+2. See if there are some reflogs of deleted branches or HEAD left in `.git/logs`.
+   Reflogs will give you commit ids that branches’ tips pointed to. But usually
+   reflogs are deleted with their branches.
+
+3. As the last resort, use `git fsck --dangling` to find objects, that may be
+   the commits of deleted branches. See also other options of `git fsck` command.
+
+Of course, all that is not necessary if you have a clone of the repo somewhere.
+Then just fetch the history from it.
+
+Git history will give you the history of modifications in the repository, the
+content of not annexed files (that were stored directly in git) and the names
+of annexed files (represented as symlinks).
+
+If all you need is just the contents of annexed files, then look at
+`.git/annex/objects`.  
+**But**: if the repository was in direct mode, then `.git/annex/objects` *may*
+contain only *old* versions of files. The current versions of annexed files
+in direct mode are stored in the working directory, which is empty in your case.
+
+The git-annex branch contains just the location log of the content of annexed
+files, i.e. which git-annex repositories and when stored the contents.
+
+"""]]

diff --git a/doc/forum/How_big_can_a_git-annex_repo_get_and_still_be_reliable_and_fast__63__.mdwn b/doc/forum/How_big_can_a_git-annex_repo_get_and_still_be_reliable_and_fast__63__.mdwn
new file mode 100644
index 0000000..1349ad9
--- /dev/null
+++ b/doc/forum/How_big_can_a_git-annex_repo_get_and_still_be_reliable_and_fast__63__.mdwn
@@ -0,0 +1,8 @@
+As title says, how big can a git-annex repo be?
+
+My use case is this:
+I have a few external hard disks (like 2TB, 3TB etc) and each of them have a bunch of files. Ideally I would like to keep all of the data organized in a _single_ git annex repo. However, there are probably a handful of really big files and a LARGE number of really small files, and I doubt its a good idea to put all of them in together.
+
+What should be my biggest concern? I assume file size is not a problem, and I should either tar/zip smaller files into much bigger ones and annex that, or split it up into multiple small annex repositories.
+
+Any suggestions? What do the rest of you with similar amounts of data do?

diff --git a/doc/forum/Restoring_files__63__.mdwn b/doc/forum/Restoring_files__63__.mdwn
new file mode 100644
index 0000000..d0bf86d
--- /dev/null
+++ b/doc/forum/Restoring_files__63__.mdwn
@@ -0,0 +1,11 @@
+One of my users created a git annex repository a while ago and has since left the lab, and I think they messed it up badly.
+
+It looks like all of the data is present in the annex directory, but there are no files in main directory, other than the .git folder. The master branch seems to be gone, and the only branch left is called git-annex.
+
+git log gives the error "fatal: bad default revision 'HEAD'" when I first do git log, because the branch that I am on doesn't exist (the master branch). Changing to the git-annex branch works, but then I can't go back to the master branch because it doesn't exist.
+
+git annex unannex doesn't seem to do anything. Is there any way to get the data back following this kind of mess up?
+
+Thanks for your help
+
+-Mike

diff --git a/doc/forum/Trouble_adding_ssh_remote_using_assistant_on_windows.mdwn b/doc/forum/Trouble_adding_ssh_remote_using_assistant_on_windows.mdwn
new file mode 100644
index 0000000..08da616
--- /dev/null
+++ b/doc/forum/Trouble_adding_ssh_remote_using_assistant_on_windows.mdwn
@@ -0,0 +1,19 @@
+Hi, just trying to set up git-annex-assistant on freshly installed windows 10. I've run the web app and created a local repo. I also grabbed the tarball on my server and ran "git-annex" with no arguments (?). I'm now trying to add remote server using ssh. I add the correct details and click "Check this server", at which point it displays "Testing Server, Checking ssh connection to the server. This could take a minute". indefinitely.
+
+I've checked the log and don't see any ssh errors, but I do see some weirdness:
+
+```
+(scanning...) [2015-06-29 19:02:36 GMT Summer Time] Watcher: Performing startup scan
+(started...) rerrrrrrceereeeevccecccc:vvcvvvv ::v::::f  :    aff ffffiaafaaaaliiaiiiiellilllldeeleeee ddedddd(  d    N(( ((((oNN(NNNN ooNooooe  o    ree eeeerrrerrrrorrrrrrrrooroooo)rrorrrr
+))r))))
+
+)
+
+rerrrceeevccc:vvv :::f   afffiaaaliiiellldeee ddd(   N(((oNNN oooe   reeerrrrorrrrooo)rrr
+)))
+
+rerrrrrrrrrrrrrceeeeeeeeeeeeevccccccccccccc:vvvvvvvvvvvvv :::::::::::::f             afffffffffffffiaaaaaaaaaaaaaliiiiiiiiiiiiiellllllllllllldeeeeeeeeeeeee ddddddddddddd(             N(((((((((((((oNNNNNNNNNNNNN oooooooooooooe             reeeeeeeeeeeeerrrrrrrrrrrrrrorrrrrrrrrrrrrrooooooooooooo)rrrrrrrrrrrrr
+)))))))))))))
+```
+
+Not sure what that is but it might be relevant? Any help would be appreciated.

diff --git a/doc/bugs/kill_git-annex_assistant_on_logout.mdwn b/doc/bugs/kill_git-annex_assistant_on_logout.mdwn
new file mode 100644
index 0000000..0640a5a
--- /dev/null
+++ b/doc/bugs/kill_git-annex_assistant_on_logout.mdwn
@@ -0,0 +1,3 @@
+When you logout of any x session git-annex does not get killed.
+This means that if you login again git-annex will still try to use the ssh-agent from the last session which doesn't run anymore.
+This leads to countless password queries unless you use a passwordless key.

diff --git a/doc/bugs/Interrupted_command_broke_encfs_repository.mdwn b/doc/bugs/Interrupted_command_broke_encfs_repository.mdwn
new file mode 100644
index 0000000..38bb060
--- /dev/null
+++ b/doc/bugs/Interrupted_command_broke_encfs_repository.mdwn
@@ -0,0 +1,54 @@
+### Please describe the problem.
+
+I use git annex on my phone on an encfs directory on a debian root put on a sdcard.
+
+After an interruption, it may happens that git-annex (or git?) changes the
+content of a file in the .git directory by a content in a file from the working
+directory.
+
+[[!format sh """
+$ cat .git/config
+../../../.git/annex/objects/f8/gZ/SHA256E-s1455016--03aaa9bcccada56b6615d9e333b8ada2dd6d1fb14c4aacfac87271939377f537.JPG/SHA256E-s1455016--03aaa9bcccada56b6615d9e333b8ada2dd6d1fb14c4aacfac87271939377f537.JPG
+$ cat .git/refs/remotes/master
+../../../../.git/annex/objects/29/wQ/SHA256E-s2533743--ec986bdbe37257bb5a940469d1e1b64a6016902736ed87315bab5856de322f42.JPG/SHA256E-s2533743--ec986bdbe37257bb5a940469d1e1b64a6016902736ed87315bab5856de322f42.JPG
+"""]]
+
+I only experienced this behavior two or three times since I have been using git-annex (3 years ago).
+
+Everything else works fine and fsck indicates no problem with the sdcard.
+
+This is a strange behavior that is a pain to solve, but today, I experienced something
+even stranger.
+
+Instead of writing the content into the .git/ directory. It was put in the encoded file in the crypt directory, with the path correctly encoded.
+
+[[!format sh """
+$ cat repo/.git/config
+cat: repo/.git/config: Input/output error
+$ encfsctl encode crypt_repo/ .git/config
+CqJBnbpfTEgKPAnmc8Sbo/IA-gS5lOzCF65DW9C7l-3MYU/OKritNqY4ewLnzQ,R2dtBXzW
+$ cat crypt_repo/CqJBnbpfTEgKPAnmc8Sbo/IA-gS5lOzCF65DW9C7l-3MYU/OKritNqY4ewLnzQ,R2dtBXzW
+../../../RSYdwqZh7kgnn3RSbEEx86ax/60jj4hZ60tqcDwSiXy-hHpD9/ebwg,0lJ7hi2iBbgF7HBfdqC/-muvnOVFmMIkfUtJAVyMGRUs/lRm4UHX0Dj2lW6IsCnnBBBSX/O9l1191uPE0a2D-FXhrOEG5,uWeGZHyJccAsw64vy16H3iTcRrxY-75YdRnnMzL27zpC5j0UUVnTaU0TBg0ze-xWCLpoJHZha48Uu8NaekYpn9C5QSSmUV08aZERdCdCfS3/GSOJ0Txna5LM9CLDD6Pw8x5pZ7D5YKFdNb-yx4APrKVm,EXauZiDQoXo6qOuVCMUI4KJB9kdnprlZ4Bw7h7w2jogW7Q1GDpqKVSgk7VYLuk5D7CpdaslquWbg0Ci5e9k9T7
+$ encfs decode ../../../RSYdwqZh7kgnn3RSbEEx86ax/60jj4hZ60tqcDwSiXy-hHpD9/ebwg,0lJ7hi2iBbgF7HBfdqC/-muvnOVFmMIkfUtJAVyMGRUs/lRm4UHX0Dj2lW6IsCnnBBBSX/O9l1191uPE0a2D-FXhrOEG5,uWeGZHyJccAsw64vy16H3iTcRrxY-75YdRnnMzL27zpC5j0UUVnTaU0TBg0ze-xWCLpoJHZha48Uu8NaekYpn9C5QSSmUV08aZERdCdCfS3/GSOJ0
+../../../.git/annex/objects/f8/gZ/SHA256E-s1455016--03aaa9bcccada56b6615d9e333b8ada2dd6d1fb14c4aacfac87271939377f537.JPG/SHA256E-s1455016--03aaa9bcccada56b6615d9e333b8ada2dd6d1fb14c4aacfac87271939377f537.JPG
+"""]]
+
+### What steps will reproduce the problem?
+Interruption of a git annex command, I guess an add or an import command.
+
+### What version of git-annex are you using? On what operating system?
+
+Android 4.3 Cyanogenmod/Samsung Galaxy S3, chrooted debian.
+
+[[!format sh """
+$ git annex version
+git-annex version: 5.20141125
+build flags: Assistant Pairing Testsuite S3 Inotify DBus DesktopNotify XMPP DNS Feeds Quvi TDFA CryptoHash
+key/value backends: SHA256E SHA1E SHA512E SHA224E SHA384E SKEIN256E SKEIN512E SHA256 SHA1 SHA512 SHA224 SHA384 SKEIN256 SKEIN512 WORM URL
+remote types: git gcrypt S3 bup directory rsync web tahoe glacier ddar hook external
+$ cat /etc/debian_version
+8.0
+"""]]
+
+### Please provide any additional information below.
+If you ask for additional information, I will gladly provide it.

Added a comment: any updates?
diff --git a/doc/forum/s3_special_remote_does_not_resume_uploads_even_with_new_chunking/comment_3_85989f505931ec695d7f3de74db0f5a1._comment b/doc/forum/s3_special_remote_does_not_resume_uploads_even_with_new_chunking/comment_3_85989f505931ec695d7f3de74db0f5a1._comment
new file mode 100644
index 0000000..aac24a0
--- /dev/null
+++ b/doc/forum/s3_special_remote_does_not_resume_uploads_even_with_new_chunking/comment_3_85989f505931ec695d7f3de74db0f5a1._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="digiuser"
+ subject="any updates?"
+ date="2015-06-29T03:05:53Z"
+ content="""
+Sorry to post again here but I was wondering if this message got lost. Anyone have a solution here? Thanks!
+"""]]

diff --git a/doc/forum/Storing_copies_on_LTO_tapes__63__.mdwn b/doc/forum/Storing_copies_on_LTO_tapes__63__.mdwn
index 317ffc6..175bc2b 100644
--- a/doc/forum/Storing_copies_on_LTO_tapes__63__.mdwn
+++ b/doc/forum/Storing_copies_on_LTO_tapes__63__.mdwn
@@ -6,8 +6,8 @@ Three alternatives I've come up with so far:
 
 1. Simply tar the repositories from the HDs to the tapes. Problem: no way to notify git annex of the existence of these manual copies. Or is there?
 2. Remote (special or normal) on LTFS (linear posix compatible file system on top of tape). Problems:
-    1. **git annex get**ing a dropped directory from there would cause files to be accessed in random order, right? Or is the retrieve guaranteed to happen in the same order as the files in the directory were written by **git annex copy**?
+    1. `git annex get`ing a dropped directory from there would cause files to be accessed in random order, right? Or is the retrieve guaranteed to happen in the same order as the files in the directory were written by `git annex copy`?
     2. LTFS has a big block size (512KB) => wasted space when lots of small files. (Not a major problem, though.)
-3. Write a special (read-only) remote hook for *tar*. Problem: **get** would make one *RETRIEVE* request per file, leading to random access again, while the only effective way would be to get a list of all files to be retrieved, and then returning them in the order they turn up from the tar package (or even ingest the whole tar file to .git/annex/).
+3. Write a special (read-only) remote hook for `tar`. Problem: `git annex get` would make one hook *RETRIEVE* request per file, leading to random access again, while the only effective way would be to get a list of all files to be retrieved, and then returning them in the order they turn up from the tar package (or even ingest the whole tar file to .git/annex/).
 
 Thoughts?

Added a comment
diff --git a/doc/forum/Adding_normal___40__non-annexed__41___files_in_Windows/comment_2_3f2556b0a0cd8b7523aed1bea1be8484._comment b/doc/forum/Adding_normal___40__non-annexed__41___files_in_Windows/comment_2_3f2556b0a0cd8b7523aed1bea1be8484._comment
new file mode 100644
index 0000000..96bc4f4
--- /dev/null
+++ b/doc/forum/Adding_normal___40__non-annexed__41___files_in_Windows/comment_2_3f2556b0a0cd8b7523aed1bea1be8484._comment
@@ -0,0 +1,29 @@
+[[!comment format=mdwn
+ username="chris.forum.email@596f849a9d27c1f0bcdd653d1d2dc992f21ce603"
+ nickname="chris.forum.email"
+ subject="comment 2"
+ date="2015-06-27T11:23:05Z"
+ content="""
+if I use `git annex proxy` I can't see the changes:
+
+    C:\Users\Chris\Projects\testing>git annex proxy -- git status
+    On branch annex/direct/master
+    nothing to commit, working directory clean
+
+and I noticed that I'm on a branch called `annex/direct/master`, not the `master` I'd expect...
+
+if I use `git -c core.bare=false`, I get the normal output:
+
+    C:\Users\Chris\Projects\testing>git -c core.bare=false status
+    On branch annex/direct/master
+    Untracked files:
+      (use \"git add <file>...\" to include in what will be committed)
+    
+            test.txt
+    
+    nothing added to commit but untracked files present (use \"git add\" to track)
+
+but I'm still on a \"wrong\" branch? what is this `annex/direct/master` branch and am I supposed to commit and push this branch?
+
+Thanks, Chris
+"""]]

Added a comment: Proxy command
diff --git a/doc/forum/Adding_normal___40__non-annexed__41___files_in_Windows/comment_1_e40e129fbdae305ad48f810c578fa69f._comment b/doc/forum/Adding_normal___40__non-annexed__41___files_in_Windows/comment_1_e40e129fbdae305ad48f810c578fa69f._comment
new file mode 100644
index 0000000..e2c1df6
--- /dev/null
+++ b/doc/forum/Adding_normal___40__non-annexed__41___files_in_Windows/comment_1_e40e129fbdae305ad48f810c578fa69f._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="https://me.yahoo.com/a/5j.FKrMpxZS.luSB.5ahyosMU6RcaYq2#74c60"
+ nickname="Jarno"
+ subject="Proxy command"
+ date="2015-06-26T17:32:42Z"
+ content="""
+Have you tried the `git annex proxy --` command? Another way might be to just bypass the annex checks with `git -c core.bare=false`.
+Check <http://git-annex.branchable.com/direct_mode/> for details.
+"""]]

diff --git a/doc/forum/Adding_normal___40__non-annexed__41___files_in_Windows.mdwn b/doc/forum/Adding_normal___40__non-annexed__41___files_in_Windows.mdwn
new file mode 100644
index 0000000..b9d118c
--- /dev/null
+++ b/doc/forum/Adding_normal___40__non-annexed__41___files_in_Windows.mdwn
@@ -0,0 +1,31 @@
+Hi,
+I'm working on a game project (Unity3D) which I want to use git-annex for all those binary assets,
+
+but I still want to be able to commit normal code files in git,
+
+is there a way to do that?
+
+below is what I tried (but failed) to do.
+
+Thanks.
+
+Chris
+
+
+
+    C:\Users\Chris\Projects\testing>git annex init "testing"
+    init testing
+      Detected a filesystem without fifo support.
+    
+      Disabling ssh connection caching.
+    
+      Detected a crippled filesystem.
+    
+      Enabling direct mode.
+    ok
+    (recording state in git...)
+    
+    C:\Users\Chris\Projects\testing>echo test > testing.txt
+    
+    C:\Users\Chris\Projects\testing>git add testing.txt
+    fatal: This operation must be run in a work tree

Added a comment
diff --git a/doc/forum/Question:_git-annex-only_repo___63__/comment_8_3e24c9f9042d6abdafaae45015645b11._comment b/doc/forum/Question:_git-annex-only_repo___63__/comment_8_3e24c9f9042d6abdafaae45015645b11._comment
new file mode 100644
index 0000000..0011ebb
--- /dev/null
+++ b/doc/forum/Question:_git-annex-only_repo___63__/comment_8_3e24c9f9042d6abdafaae45015645b11._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="boustanihani@93604388a6a2b8df16f3e34157232801a67c1021"
+ nickname="boustanihani"
+ subject="comment 8"
+ date="2015-06-25T21:13:01Z"
+ content="""
+Is it possible to force git-annex to keep all versions for some or all files??
+
+Or (maybe better) specify how many old versions to keep (for example keep the last 20 versions or so...) ?
+"""]]

diff --git a/doc/forum/Storing_copies_on_LTO_tapes__63__.mdwn b/doc/forum/Storing_copies_on_LTO_tapes__63__.mdwn
index 822b3c9..317ffc6 100644
--- a/doc/forum/Storing_copies_on_LTO_tapes__63__.mdwn
+++ b/doc/forum/Storing_copies_on_LTO_tapes__63__.mdwn
@@ -1,6 +1,6 @@
 I'm looking for a way to count/track annex data copied to LTO tapes.
 
-In my use case I'm splitting many terabytes of data to separate repositories on several hard drives, backing them up on tapes, and keeping track of all this with remotes in a central repository (with lots of dropped content). All good with the HDs, but I'm at a loss about how to handle copies stored on tapes.
+In my use case I'm splitting many terabytes of data to separate repositories on several hard drives, backing them up on tapes, and keeping track of all this with remotes in a central repository (with lots of dropped content). All good with the HDs, but I'm at a loss about how to handle the copies on tapes.
 
 Three alternatives I've come up with so far:
 

diff --git a/doc/forum/Storing_copies_on_LTO_tapes__63__.mdwn b/doc/forum/Storing_copies_on_LTO_tapes__63__.mdwn
index d67dd59..822b3c9 100644
--- a/doc/forum/Storing_copies_on_LTO_tapes__63__.mdwn
+++ b/doc/forum/Storing_copies_on_LTO_tapes__63__.mdwn
@@ -2,7 +2,7 @@ I'm looking for a way to count/track annex data copied to LTO tapes.
 
 In my use case I'm splitting many terabytes of data to separate repositories on several hard drives, backing them up on tapes, and keeping track of all this with remotes in a central repository (with lots of dropped content). All good with the HDs, but I'm at a loss about how to handle copies stored on tapes.
 
-Three alternatives I've come up so far:
+Three alternatives I've come up with so far:
 
 1. Simply tar the repositories from the HDs to the tapes. Problem: no way to notify git annex of the existence of these manual copies. Or is there?
 2. Remote (special or normal) on LTFS (linear posix compatible file system on top of tape). Problems:

diff --git a/doc/forum/Storing_copies_on_LTO_tapes__63__.mdwn b/doc/forum/Storing_copies_on_LTO_tapes__63__.mdwn
new file mode 100644
index 0000000..d67dd59
--- /dev/null
+++ b/doc/forum/Storing_copies_on_LTO_tapes__63__.mdwn
@@ -0,0 +1,13 @@
+I'm looking for a way to count/track annex data copied to LTO tapes.
+
+In my use case I'm splitting many terabytes of data to separate repositories on several hard drives, backing them up on tapes, and keeping track of all this with remotes in a central repository (with lots of dropped content). All good with the HDs, but I'm at a loss about how to handle copies stored on tapes.
+
+Three alternatives I've come up so far:
+
+1. Simply tar the repositories from the HDs to the tapes. Problem: no way to notify git annex of the existence of these manual copies. Or is there?
+2. Remote (special or normal) on LTFS (linear posix compatible file system on top of tape). Problems:
+    1. **git annex get**ing a dropped directory from there would cause files to be accessed in random order, right? Or is the retrieve guaranteed to happen in the same order as the files in the directory were written by **git annex copy**?
+    2. LTFS has a big block size (512KB) => wasted space when lots of small files. (Not a major problem, though.)
+3. Write a special (read-only) remote hook for *tar*. Problem: **get** would make one *RETRIEVE* request per file, leading to random access again, while the only effective way would be to get a list of all files to be retrieved, and then returning them in the order they turn up from the tar package (or even ingest the whole tar file to .git/annex/).
+
+Thoughts?

Added a comment
diff --git a/doc/forum/__34__du__34___equivalent_on_an_annex__63__/comment_9_a2bda4c74ef09a58709c0c5f6ee1b726._comment b/doc/forum/__34__du__34___equivalent_on_an_annex__63__/comment_9_a2bda4c74ef09a58709c0c5f6ee1b726._comment
new file mode 100644
index 0000000..0e344a4
--- /dev/null
+++ b/doc/forum/__34__du__34___equivalent_on_an_annex__63__/comment_9_a2bda4c74ef09a58709c0c5f6ee1b726._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="anarcat"
+ subject="comment 9"
+ date="2015-06-24T21:40:07Z"
+ content="""
+... but nowadays, i use `git annex info --fast *`.
+"""]]

Added a comment: somewhat
diff --git a/doc/forum/Question:_git-annex-only_repo___63__/comment_7_8278ee493da14aac86e928d2349d8173._comment b/doc/forum/Question:_git-annex-only_repo___63__/comment_7_8278ee493da14aac86e928d2349d8173._comment
new file mode 100644
index 0000000..56aae7d
--- /dev/null
+++ b/doc/forum/Question:_git-annex-only_repo___63__/comment_7_8278ee493da14aac86e928d2349d8173._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="anarcat"
+ subject="somewhat"
+ date="2015-06-24T16:28:42Z"
+ content="""
+git-annex doesn't deliberately keep all versions of the files. however, if you change a file (using [[git-annex-edit]]), it will keep the old copy, which will become [[walkthrough/unused_data/]]. that data will be purged by the assistant after a while (if configured to do so) but you can also archive it, etc... 
+
+so in a way, yes, it is versionned, but the unused data is somewhat more 'brittle' than the current dataset.
+"""]]

Add patch for "unrecognized argument: -raw" bug
diff --git a/doc/todo/__91__PATCH__93___Log.hs:_Add_missing_dash_to_--raw_option.mdwn b/doc/todo/__91__PATCH__93___Log.hs:_Add_missing_dash_to_--raw_option.mdwn
new file mode 100644
index 0000000..0a1ee55
--- /dev/null
+++ b/doc/todo/__91__PATCH__93___Log.hs:_Add_missing_dash_to_--raw_option.mdwn
@@ -0,0 +1,33 @@
+This commit is also available in the "log-raw-missing-dash" branch at <https://github.com/sunny256/git-annex.git>.
+
+[[!format hs """
+From 5e00265dae057e1846d5a256f450c8a1e1803c97 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?=C3=98yvind=20A=2E=20Holm?= <sunny@sunbase.org>
+Date: Wed, 24 Jun 2015 17:07:37 +0200
+Subject: [PATCH] Log.hs: Add missing dash to --raw option
+
+After commit eb33569f ("remove Params constructor from
+Utility.SafeCommand", 2015-06-01), git-annex aborted with the error
+message "fatal: unrecognized argument: -raw" when executing "git annex
+log".
+---
+ Command/Log.hs | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/Command/Log.hs b/Command/Log.hs
+index 9ee7f85..495c43c 100644
+--- a/Command/Log.hs
++++ b/Command/Log.hs
+@@ -151,7 +151,7 @@ getLog key os = do
+ 		[ Param "log"
+ 		, Param "-z"
+ 		, Param "--pretty=format:%ct"
+-		, Param "-raw"
++		, Param "--raw"
+ 		, Param "--abbrev=40"
+ 		, Param "--remove-empty"
+ 		] ++ os ++
+-- 
+2.4.4.408.g16da57c
+
+"""]]

add daemon logfile, nothing seems to be obviously wrong there
diff --git a/doc/bugs/assistant_memory_leak.mdwn b/doc/bugs/assistant_memory_leak.mdwn
index d15c861..ca23cf8 100644
--- a/doc/bugs/assistant_memory_leak.mdwn
+++ b/doc/bugs/assistant_memory_leak.mdwn
@@ -19,12 +19,4 @@ Unclear. The assistant has been running for a while and there's a big tansfer (~
 
 ### Please provide any additional information below.
 
-[[!format sh """
-# If you can, paste a complete transcript of the problem occurring here.
-# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
-
-
-# End of transcript or log.
-"""]]
-
---[[anarcat]]
+daemon.log: http://paste2.org/YJVGvpy5 --[[anarcat]]

wow, that's scary
diff --git a/doc/bugs/assistant_memory_leak.mdwn b/doc/bugs/assistant_memory_leak.mdwn
new file mode 100644
index 0000000..d15c861
--- /dev/null
+++ b/doc/bugs/assistant_memory_leak.mdwn
@@ -0,0 +1,30 @@
+### Please describe the problem.
+
+The assistant is using gruesome amounts of resident memory:
+
+<pre>
+USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
+www-data 23898 29.0 90.4 7842888 5536740 ?     Sl   Jun17 2810:08 /usr/lib/git-annex.linux/exe/git-annex --library-path /usr/lib/git-annex.linu
+</pre>
+
+I had to stop the assistant because it ended up using all memory.
+
+### What steps will reproduce the problem?
+
+Unclear. The assistant has been running for a while and there's a big tansfer (~800GB) of files in progress.
+
+### What version of git-annex are you using? On what operating system?
+
+5.20150610+gitg608172f-1~ndall+1 on Debian 7 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
+
+
+# End of transcript or log.
+"""]]
+
+--[[anarcat]]

Added a comment
diff --git a/doc/forum/Question:_git-annex-only_repo___63__/comment_6_32fb6930bcaac36d00b088d8ee09face._comment b/doc/forum/Question:_git-annex-only_repo___63__/comment_6_32fb6930bcaac36d00b088d8ee09face._comment
new file mode 100644
index 0000000..ce10012
--- /dev/null
+++ b/doc/forum/Question:_git-annex-only_repo___63__/comment_6_32fb6930bcaac36d00b088d8ee09face._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="boustanihani@93604388a6a2b8df16f3e34157232801a67c1021"
+ nickname="boustanihani"
+ subject="comment 6"
+ date="2015-06-24T14:06:35Z"
+ content="""
+cool thanks :)
+
+Is it also possible to version control large binary files using git-annex assistant ??
+
+I mean to be able to switch back to earlier versions when needed...
+
+Is there something like a way to specify how  many older versions should be kept in the repo? This would be a nice feature for preserving disk space...
+"""]]

Added a comment
diff --git a/doc/forum/Question:_git-annex-only_repo___63__/comment_5_36bd0a398b385e65df7eda26fa5c50d0._comment b/doc/forum/Question:_git-annex-only_repo___63__/comment_5_36bd0a398b385e65df7eda26fa5c50d0._comment
new file mode 100644
index 0000000..fe9c971
--- /dev/null
+++ b/doc/forum/Question:_git-annex-only_repo___63__/comment_5_36bd0a398b385e65df7eda26fa5c50d0._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="anarcat"
+ subject="comment 5"
+ date="2015-06-24T12:14:02Z"
+ content="""
+you are correct. \"git add\" *will* add a file into git directly. \"git annex add\" is like \"git track\"...
+"""]]

Added a comment
diff --git a/doc/forum/Question:_git-annex-only_repo___63__/comment_4_426160c2237db790b133b9c9f0abd4b2._comment b/doc/forum/Question:_git-annex-only_repo___63__/comment_4_426160c2237db790b133b9c9f0abd4b2._comment
new file mode 100644
index 0000000..ff771d1
--- /dev/null
+++ b/doc/forum/Question:_git-annex-only_repo___63__/comment_4_426160c2237db790b133b9c9f0abd4b2._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="boustanihani@93604388a6a2b8df16f3e34157232801a67c1021"
+ nickname="boustanihani"
+ subject="comment 4"
+ date="2015-06-24T10:14:18Z"
+ content="""
+Thanks I'll take a look at git-annex assistant, all new to me :)
+
+Never mind about track, I thought git-annex is similar to git-lfs where you should manually call \"track...\" on files whose content should not be added to git...
+"""]]

Added a comment
diff --git a/doc/bugs/Installation_on_ArchLinux_fails/comment_2_ff058ac51ee3bdd2b65a903716ea0d66._comment b/doc/bugs/Installation_on_ArchLinux_fails/comment_2_ff058ac51ee3bdd2b65a903716ea0d66._comment
new file mode 100644
index 0000000..4089228
--- /dev/null
+++ b/doc/bugs/Installation_on_ArchLinux_fails/comment_2_ff058ac51ee3bdd2b65a903716ea0d66._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="CandyAngel"
+ subject="comment 2"
+ date="2015-06-24T07:33:20Z"
+ content="""
+The AUR package isn't \"official\", so it isn't supported.
+
+It has an outdated checksum because there is some issue related to changes to curl which apparently causes problems if you use the webapp (which I don't, so I just deleted that bit and it seems to work fine).
+"""]]

Added a comment
diff --git a/doc/forum/Question:_git-annex-only_repo___63__/comment_3_0c0dad1ffa11f2f8708906d310a189db._comment b/doc/forum/Question:_git-annex-only_repo___63__/comment_3_0c0dad1ffa11f2f8708906d310a189db._comment
new file mode 100644
index 0000000..d61393d
--- /dev/null
+++ b/doc/forum/Question:_git-annex-only_repo___63__/comment_3_0c0dad1ffa11f2f8708906d310a189db._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="Marco"
+ subject="comment 3"
+ date="2015-06-24T07:23:28Z"
+ content="""
+What do you mean by track?
+
+If you are using the assistant, it will take care for you. It will add, commit and distribute files.
+
+If you are using the command line without the assistant, you should have a look at the [[walkthrough]]. You can play around with repositories in /tmp before you push all your important data into it ;)
+"""]]

Added a comment
diff --git a/doc/forum/security_risk_presented_by_remote.log__63__/comment_5_df1eab397c8e08698064391438bbff1b._comment b/doc/forum/security_risk_presented_by_remote.log__63__/comment_5_df1eab397c8e08698064391438bbff1b._comment
new file mode 100644
index 0000000..4076cd2
--- /dev/null
+++ b/doc/forum/security_risk_presented_by_remote.log__63__/comment_5_df1eab397c8e08698064391438bbff1b._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="anarcat"
+ subject="comment 5"
+ date="2015-06-24T01:34:11Z"
+ content="""
+interesting! i don't see that here, maybe that could be a problem there. my s3 remote doesn't use encryption, so maybe i don't have this problem...
+
+i don't know!
+"""]]

Added a comment
diff --git a/doc/forum/security_risk_presented_by_remote.log__63__/comment_4_428bbced6406a35eb093a27e35831f38._comment b/doc/forum/security_risk_presented_by_remote.log__63__/comment_4_428bbced6406a35eb093a27e35831f38._comment
new file mode 100644
index 0000000..0b653de
--- /dev/null
+++ b/doc/forum/security_risk_presented_by_remote.log__63__/comment_4_428bbced6406a35eb093a27e35831f38._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="digiuser"
+ subject="comment 4"
+ date="2015-06-24T01:30:26Z"
+ content="""
+What is `s3creds` in `remote.log` then? Something base64 encoded that is named suspiciously like creds for logging into s3?
+"""]]

Added a comment
diff --git a/doc/forum/security_risk_presented_by_remote.log__63__/comment_3_b1ddf06b34f750e9bbd88e6d5348e765._comment b/doc/forum/security_risk_presented_by_remote.log__63__/comment_3_b1ddf06b34f750e9bbd88e6d5348e765._comment
new file mode 100644
index 0000000..2bc041b
--- /dev/null
+++ b/doc/forum/security_risk_presented_by_remote.log__63__/comment_3_b1ddf06b34f750e9bbd88e6d5348e765._comment
@@ -0,0 +1,29 @@
+[[!comment format=mdwn
+ username="anarcat"
+ subject="comment 3"
+ date="2015-06-24T01:17:23Z"
+ content="""
+> I read the encryption page but I just want to know if I'm understanding it correctly.
+
+I think you are understanding this correctly... let's see..
+
+> Let's say I initiated my remote with this command:
+>
+>     git annex initremote myremote type=S3 chunk=256MiB keyid=XXXXXXXX bucket=mybucket
+>
+> And then, I handed out my remote.log file to people publicly. Does that expose any security hole at all?
+
+It won't expose your S3 credentials, if that's what your are asking. Those are stored in `.git/annex/creds/` and not in the git-annex branch. You can see the content of `remote.log` yourself with:
+
+    git cat-file -p git-annex:remote.log
+
+... if that helps you at all..
+
+>  Or is 100% of the information in remote.log secured using gpg?
+
+Well, it *would* expose the bucket name and the GPG key id (\"XXXXXXXX\") that you set there. The remote.log, itself, is *not* encrypted with gpg, from what I understand. Or to put it another way, the `remote.log` is not actually sent to the S3 remote there, and if you put the git repo publicly, then its content will be publicly readable. To protect against that, you would need a [[special_remotes/gcrypt]] remote.
+
+> I would believe that people couldn't decrypt my file contents, but could they get into my bucket or my S3 account?
+
+Not unless they have the S3 credentials, no. Furthermore, if the bucket is not publicly readable (see [[tips/public_Amazon_S3_remote/]] for that), they won't be able to get the file contents either. And *even* if it is public, they would get the *encrypted* content which they couldn't decrypt without the private key associated with the keyid you supplied.
+"""]]

Added a comment
diff --git a/doc/forum/security_risk_presented_by_remote.log__63__/comment_2_40383346237de0bae4760dc85fefc348._comment b/doc/forum/security_risk_presented_by_remote.log__63__/comment_2_40383346237de0bae4760dc85fefc348._comment
new file mode 100644
index 0000000..7dc3bd8
--- /dev/null
+++ b/doc/forum/security_risk_presented_by_remote.log__63__/comment_2_40383346237de0bae4760dc85fefc348._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="digiuser"
+ subject="comment 2"
+ date="2015-06-24T00:51:44Z"
+ content="""
+I read the encryption page but I just want to know if I'm understanding it correctly.
+
+Let's say I initiated my remote with this command:
+
+    git annex initremote myremote type=S3 chunk=256MiB keyid=XXXXXXXX bucket=mybucket
+
+And then, I handed out my remote.log file to people publicly. Does that expose *any* security hole at all? Or is 100% of the information in remote.log secured using gpg?
+
+I would believe that people couldn't decrypt my file contents, but could they get into my bucket or my S3 account?
+"""]]

Added a comment: yes
diff --git a/doc/forum/s3_special_remote_does_not_resume_uploads_even_with_new_chunking/comment_2_db57d14b983a957c454968477d9de634._comment b/doc/forum/s3_special_remote_does_not_resume_uploads_even_with_new_chunking/comment_2_db57d14b983a957c454968477d9de634._comment
new file mode 100644
index 0000000..df12abc
--- /dev/null
+++ b/doc/forum/s3_special_remote_does_not_resume_uploads_even_with_new_chunking/comment_2_db57d14b983a957c454968477d9de634._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="digiuser"
+ subject="yes"
+ date="2015-06-24T00:49:22Z"
+ content="""
+Yes, a single chunk did get transferred correctly.
+
+Actually, many times I've run this experiment, many chunks did get transferred correctly. I've even verified that they are in S3, but git-annex is trying to re-upload them. 
+
+(I haven't checked their contents in S3 but the filenames are there and the sizes are there)
+"""]]

Added a comment
diff --git a/doc/forum/s3_special_remote_does_not_resume_uploads_even_with_new_chunking/comment_1_f6b1991e259bf4b3d2c85a08f465aa4a._comment b/doc/forum/s3_special_remote_does_not_resume_uploads_even_with_new_chunking/comment_1_f6b1991e259bf4b3d2c85a08f465aa4a._comment
new file mode 100644
index 0000000..79f0fe8
--- /dev/null
+++ b/doc/forum/s3_special_remote_does_not_resume_uploads_even_with_new_chunking/comment_1_f6b1991e259bf4b3d2c85a08f465aa4a._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="anarcat"
+ subject="comment 1"
+ date="2015-06-24T00:31:43Z"
+ content="""
+did a single chunk get transfered correctly? i believe git-annex can only resume at the chunk granularity... that is what it is for, no? --[[anarcat]]
+"""]]

Added a comment
diff --git a/doc/forum/security_risk_presented_by_remote.log__63__/comment_1_9715488033f2a8939a32ed12259377ba._comment b/doc/forum/security_risk_presented_by_remote.log__63__/comment_1_9715488033f2a8939a32ed12259377ba._comment
new file mode 100644
index 0000000..2b2805a
--- /dev/null
+++ b/doc/forum/security_risk_presented_by_remote.log__63__/comment_1_9715488033f2a8939a32ed12259377ba._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="anarcat"
+ subject="comment 1"
+ date="2015-06-24T00:30:32Z"
+ content="""
+it depends how you configured encryption. this is pretty well described in the [[encryption]] page, but basically, unless you used \"shared\" encryption, only the holders of the GPG private key material will be able to decrypt the contents. Objects are encrypted with GPG using a symmetric key, and that key is then encrypted with OpenPGP public keys.
+
+This is all pretty well described in [[encryption]]. --[[anarcat]]
+"""]]

diff --git a/doc/forum/security_risk_presented_by_remote.log__63__.mdwn b/doc/forum/security_risk_presented_by_remote.log__63__.mdwn
new file mode 100644
index 0000000..c320c7e
--- /dev/null
+++ b/doc/forum/security_risk_presented_by_remote.log__63__.mdwn
@@ -0,0 +1,5 @@
+I am curious if remote.log in the repository (or anything in the repository for that matter) gives someone access to the data stored in the special remotes.
+
+If I'm using an encrypted s3 special remote, and someone gets access to the entire repository, will they be able to decrypt things? Or is the gpg stuff stored completely separately and therefore completely unaccessable, even if someone got access to the entire contents of the git repository?
+
+What is the cipher and the cipherkeys stored in git show git-annex:remote.log?

diff --git a/doc/forum/s3_special_remote_does_not_resume_uploads_even_with_new_chunking.mdwn b/doc/forum/s3_special_remote_does_not_resume_uploads_even_with_new_chunking.mdwn
new file mode 100644
index 0000000..bc0755c
--- /dev/null
+++ b/doc/forum/s3_special_remote_does_not_resume_uploads_even_with_new_chunking.mdwn
@@ -0,0 +1,88 @@
+I'm trying to upload large files into s3 remote.  I'm using a very recent version of git-annex:
+
+    git-annex version: 5.20150616-g4d7683b
+    build flags: Assistant Webapp Webapp-secure Pairing Testsuite S3 WebDAV FsEvents XMPP DNS Feeds Quvi TDFA TorrentParser
+    key/value backends: SHA256E SHA1E SHA512E SHA224E SHA384E SKEIN256E SKEIN512E MD5E SHA256 SHA1 SHA512 SHA224 SHA384 SKEIN256 SKEIN512 MD5 WORM URL
+    remote types: git gcrypt S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external
+
+Here's how my chunking is set up:
+
+    xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx bucket=mybucket chunk=256MiB cipher=xxxxxx cipherkeys=xxxxxx datacenter=US
+    host=s3.amazonaws.com name=mybucket port=80 s3creds=xxxxxx storageclass=STANDARD type=S3 timestamp=xxxxxx
+
+If I run an upload and `^C` it in the middle of the upload, then start it again, it will always resume from the beginning.
+
+I've proven this to myself by using the `--debug` switch, please see blow. I've renamed certain things for security reasons, however GPGHMACSHA1--1111111111 always refers to the same chunk and GPGHMACSHA1--2222222222 always refers to the same chunk, etc.
+
+You can see that even after it uploads the same chunk once, it tries again.
+
+This is consistent with the behavior of letting it sit there for an hour and upload half of the large file, and then interrupting it, and having it start from scratch again.
+
+    $ git annex copy --debug * --to mybucket
+
+    [2015-06-23 15:24:07 PDT] read: git ["--git-dir=../../.git","--work-tree=../..","--literal-pathspecs","show-ref","git-annex"]
+    [2015-06-23 15:24:07 PDT] read: git ["--git-dir=../../.git","--work-tree=../..","--literal-pathspecs","show-ref","--hash","refs/heads/git-annex"]
+    [2015-06-23 15:24:07 PDT] read: git ["--git-dir=../../.git","--work-tree=../..","--literal-pathspecs","log","refs/heads/git-annex..xxx","-n1","--pretty=%H"]
+    [2015-06-23 15:24:07 PDT] chat: git ["--git-dir=../../.git","--work-tree=../..","--literal-pathspecs","cat-file","--batch"]
+    [2015-06-23 15:24:07 PDT] read: git ["--git-dir=../../.git","--work-tree=../..","--literal-pathspecs","ls-files","--cached","-z","--","aaa.tgz","xxx.tgz","xxx.tgz","xxx.tgz","xxx.tgz","xxx.tgz"]
+    copy aaa.tgz [2015-06-23 15:24:07 PDT] chat: gpg ["--quiet","--trust-model","always","--decrypt"]
+    (checking mybucket...) [2015-06-23 15:24:07 PDT] String to sign: "HEAD\n\n\nTue, 23 Jun 2015 22:24:07 GMT\n/mybucket/GPGHMACSHA1--1111111111"
+    [2015-06-23 15:24:07 PDT] Host: "mybucket.s3.amazonaws.com"
+    [2015-06-23 15:24:07 PDT] Path: "/GPGHMACSHA1--1111111111"
+    [2015-06-23 15:24:07 PDT] Query string: ""
+    [2015-06-23 15:24:07 PDT] Response status: Status {statusCode = 404, statusMessage = "Not Found"}
+    [2015-06-23 15:24:07 PDT] Response header 'x-amz-request-id': 'xxx'
+    [2015-06-23 15:24:07 PDT] Response header 'x-amz-id-2': 'xxx'
+    [2015-06-23 15:24:07 PDT] Response header 'Content-Type': 'application/xml'
+    [2015-06-23 15:24:07 PDT] Response header 'Transfer-Encoding': 'chunked'
+    [2015-06-23 15:24:07 PDT] Response header 'Date': 'Tue, 23 Jun 2015 22:24:03 GMT'
+    [2015-06-23 15:24:07 PDT] Response header 'Server': 'AmazonS3'
+    [2015-06-23 15:24:07 PDT] Response metadata: S3: request ID=<none>, x-amz-id-2=<none>
+    (to mybucket...)
+    0%            0.0 B/s 0s[2015-06-23 15:24:07 PDT] chat: gpg ["--quiet","--trust-model","always","--batch","--passphrase-fd","18","--symmetric","--force-mdc","--no-textmode"]
+    [2015-06-23 15:24:19 PDT] String to sign: "PUT\n\n\nTue, 23 Jun 2015 22:24:19 GMT\nx-amz-storage-class:STANDARD\n/mybucket/GPGHMACSHA1--2222222222"
+    [2015-06-23 15:24:19 PDT] Host: "mybucket.s3.amazonaws.com"
+    [2015-06-23 15:24:19 PDT] Path: "/GPGHMACSHA1--2222222222"
+    [2015-06-23 15:24:19 PDT] Query string: ""
+    3%        636.3KB/s 3h0m[2015-06-23 15:31:01 PDT] Response status: Status {statusCode = 200, statusMessage = "OK"}
+    [2015-06-23 15:31:01 PDT] Response header 'x-amz-id-2': 'xxx'
+    [2015-06-23 15:31:01 PDT] Response header 'x-amz-request-id': 'xxx'
+    [2015-06-23 15:31:01 PDT] Response header 'Date': 'Tue, 23 Jun 2015 22:24:17 GMT'
+    [2015-06-23 15:31:01 PDT] Response header 'ETag': '"xxx"'
+    [2015-06-23 15:31:01 PDT] Response header 'Content-Length': '0'
+    [2015-06-23 15:31:01 PDT] Response header 'Server': 'AmazonS3'
+    [2015-06-23 15:31:01 PDT] Response metadata: S3: request ID=xxx, x-amz-id-2=xxx
+    3%        633.2KB/s 3h1m[2015-06-23 15:31:01 PDT] chat: gpg ["--quiet","--trust-model","always","--batch","--passphrase-fd","18","--symmetric","--force-mdc","--no-textmode"]
+    [2015-06-23 15:31:13 PDT] String to sign: "PUT\n\n\nTue, 23 Jun 2015 22:31:13 GMT\nx-amz-storage-class:STANDARD\n/mybucket/GPGHMACSHA1--3333333333"
+    [2015-06-23 15:31:13 PDT] Host: "mybucket.s3.amazonaws.com"
+    [2015-06-23 15:31:13 PDT] Path: "/GPGHMACSHA1--3333333333"
+    [2015-06-23 15:31:13 PDT] Query string: ""
+    3%        617.2KB/s 3h6m^C
+
+    $ git annex copy --debug * --to mybucket
+
+    [2015-06-23 15:31:25 PDT] read: git ["--git-dir=../../.git","--work-tree=../..","--literal-pathspecs","show-ref","git-annex"]
+    [2015-06-23 15:31:25 PDT] read: git ["--git-dir=../../.git","--work-tree=../..","--literal-pathspecs","show-ref","--hash","refs/heads/git-annex"]
+    [2015-06-23 15:31:25 PDT] read: git ["--git-dir=../../.git","--work-tree=../..","--literal-pathspecs","log","refs/heads/git-annex..xxx","-n1","--pretty=%H"]
+    [2015-06-23 15:31:25 PDT] chat: git ["--git-dir=../../.git","--work-tree=../..","--literal-pathspecs","cat-file","--batch"]
+    [2015-06-23 15:31:25 PDT] read: git ["--git-dir=../../.git","--work-tree=../..","--literal-pathspecs","ls-files","--cached","-z","--","aaa.tgz","xxx.tgz","xxx.tgz","xxx.tgz","xxx.tgz","xxx.tgz"]
+    copy aaa.tgz [2015-06-23 15:31:25 PDT] chat: gpg ["--quiet","--trust-model","always","--decrypt"]
+    (checking mybucket...) [2015-06-23 15:31:25 PDT] String to sign: "HEAD\n\n\nTue, 23 Jun 2015 22:31:25 GMT\n/mybucket/GPGHMACSHA1--1111111111"
+    [2015-06-23 15:31:25 PDT] Host: "mybucket.s3.amazonaws.com"
+    [2015-06-23 15:31:25 PDT] Path: "/GPGHMACSHA1--1111111111"
+    [2015-06-23 15:31:25 PDT] Query string: ""
+    [2015-06-23 15:31:25 PDT] Response status: Status {statusCode = 404, statusMessage = "Not Found"}
+    [2015-06-23 15:31:25 PDT] Response header 'x-amz-request-id': 'xxx'
+    [2015-06-23 15:31:25 PDT] Response header 'x-amz-id-2': 'xxx'
+    [2015-06-23 15:31:25 PDT] Response header 'Content-Type': 'application/xml'
+    [2015-06-23 15:31:25 PDT] Response header 'Transfer-Encoding': 'chunked'
+    [2015-06-23 15:31:25 PDT] Response header 'Date': 'Tue, 23 Jun 2015 22:31:21 GMT'
+    [2015-06-23 15:31:25 PDT] Response header 'Server': 'AmazonS3'
+    [2015-06-23 15:31:25 PDT] Response metadata: S3: request ID=<none>, x-amz-id-2=<none>
+    (to mybucket...)
+    0%            0.0 B/s 0s[2015-06-23 15:31:25 PDT] chat: gpg ["--quiet","--trust-model","always","--batch","--passphrase-fd","18","--symmetric","--force-mdc","--no-textmode"]
+    [2015-06-23 15:31:37 PDT] String to sign: "PUT\n\n\nTue, 23 Jun 2015 22:31:37 GMT\nx-amz-storage-class:STANDARD\n/mybucket/GPGHMACSHA1--2222222222"
+    [2015-06-23 15:31:37 PDT] Host: "mybucket.s3.amazonaws.com"
+    [2015-06-23 15:31:37 PDT] Path: "/GPGHMACSHA1--2222222222"
+    [2015-06-23 15:31:37 PDT] Query string: ""
+    0%       350.1KB/s 5h40m^C

Added a comment
diff --git a/doc/bugs/Installation_on_ArchLinux_fails/comment_1_17821bd94b52c8231059e4934b4131e4._comment b/doc/bugs/Installation_on_ArchLinux_fails/comment_1_17821bd94b52c8231059e4934b4131e4._comment
new file mode 100644
index 0000000..8823790
--- /dev/null
+++ b/doc/bugs/Installation_on_ArchLinux_fails/comment_1_17821bd94b52c8231059e4934b4131e4._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="tommi"
+ subject="comment 1"
+ date="2015-06-23T21:24:35Z"
+ content="""
+As a workaround, installing git-annex from the haskell-core repository works (see https://wiki.archlinux.org/index.php/ArchHaskell)
+"""]]

removed
diff --git a/doc/bugs/Installation_on_ArchLinux_fails/comment_1_b03af6de94cbd7508d5a4816f6af016a._comment b/doc/bugs/Installation_on_ArchLinux_fails/comment_1_b03af6de94cbd7508d5a4816f6af016a._comment
deleted file mode 100644
index 7c4ed5b..0000000
--- a/doc/bugs/Installation_on_ArchLinux_fails/comment_1_b03af6de94cbd7508d5a4816f6af016a._comment
+++ /dev/null
@@ -1,8 +0,0 @@
-[[!comment format=mdwn
- username="tspam+git-annex@93d4c46eaee63fe6c1a54cbf0fda9df37392a80d"
- nickname="tspam+git-annex"
- subject="comment 1"
- date="2015-06-23T21:19:43Z"
- content="""
-As a workaround, I could install it via pacman -S git-annex after adding the haskell-core repo (see https://wiki.archlinux.org/index.php/ArchHaskell)
-"""]]

Added a comment
diff --git a/doc/bugs/Installation_on_ArchLinux_fails/comment_1_b03af6de94cbd7508d5a4816f6af016a._comment b/doc/bugs/Installation_on_ArchLinux_fails/comment_1_b03af6de94cbd7508d5a4816f6af016a._comment
new file mode 100644
index 0000000..7c4ed5b
--- /dev/null
+++ b/doc/bugs/Installation_on_ArchLinux_fails/comment_1_b03af6de94cbd7508d5a4816f6af016a._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="tspam+git-annex@93d4c46eaee63fe6c1a54cbf0fda9df37392a80d"
+ nickname="tspam+git-annex"
+ subject="comment 1"
+ date="2015-06-23T21:19:43Z"
+ content="""
+As a workaround, I could install it via pacman -S git-annex after adding the haskell-core repo (see https://wiki.archlinux.org/index.php/ArchHaskell)
+"""]]

diff --git a/doc/bugs/Installation_on_ArchLinux_fails.mdwn b/doc/bugs/Installation_on_ArchLinux_fails.mdwn
new file mode 100644
index 0000000..a956e6a
--- /dev/null
+++ b/doc/bugs/Installation_on_ArchLinux_fails.mdwn
@@ -0,0 +1,33 @@
+### Please describe the problem.
+The packages provided on AUR fail to install. I've tried git-annex, git-annex-bin and git-annex-git.
+
+### What steps will reproduce the problem?
+
+    yaourt -S git-annex
+
+or
+
+    yaourt -S git-annex-bin
+
+or
+
+    yaourt -S git-annex-git
+
+### What version of git-annex are you using? On what operating system?
+
+None, on an up-to-date ArchLinux (Kernel 4.0.5-1)
+
+### Please provide any additional information below.
+
+
+The git-annex-bin package has outdated checksums. When updating these, yaourt fails with
+
+    rm: cannot remove ‘/tmp/yaourt-tmp-foo/aur-git-annex-bin/pkg/git-annex-bin/opt/git-annex.linux/usr/lib/x86_64-linux-gnu/libcurl.so.4’: No such file or directory
+
+Both git-annex and git-annex-git fail with
+
+    error: target not found: haskell-edit-distance
+    error: target not found: haskell-ifelse
+    error: target not found: haskell-hs3
+
+as these packages are not available on AUR.

Added a comment: I have the same issue, no special characters in path
diff --git a/doc/bugs/local_pair_fails_if_non-ascii_characters_present_on_annex_path/comment_3_74d65bd0edd92eb6acf6770d4b6e7826._comment b/doc/bugs/local_pair_fails_if_non-ascii_characters_present_on_annex_path/comment_3_74d65bd0edd92eb6acf6770d4b6e7826._comment
new file mode 100644
index 0000000..604f1f5
--- /dev/null
+++ b/doc/bugs/local_pair_fails_if_non-ascii_characters_present_on_annex_path/comment_3_74d65bd0edd92eb6acf6770d4b6e7826._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="https://me.yahoo.com/a/QeDOPmIryZqNyn0A84E.QmGJVazd_6_FpYa2nFtn#c7fa1"
+ nickname="Captain Kirk"
+ subject="I have the same issue, no special characters in path"
+ date="2015-06-23T20:24:30Z"
+ content="""
+I have the same issue like Horus described. Pairing fails in the LAN. 
+
+\"illegal control characters in pairing message; ignoring\" appears in the log over and over
+
+distributionUrl = \"https://downloads.kitenet.net/git-annex/OSX/current/10.10_Yosemite/git-annex.dmg
+distributionVersion = \"5.20150616\"
+distributionReleasedate = 2015-06-17 18:18:52.552448 
+
+Would be great to get help or a fix!
+"""]]

explicitely describe exit status in the standard section
diff --git a/doc/git-annex.mdwn b/doc/git-annex.mdwn
index c90ef5e..45b02ec 100644
--- a/doc/git-annex.mdwn
+++ b/doc/git-annex.mdwn
@@ -1239,6 +1239,14 @@ Also note that when using views, only the toplevel .gitattributes file is
 preserved in the view, so other settings in other files won't have any
 effect.
 
+# EXIT STATUS
+
+git-annex, when called as a git subcommand, may return exit codes 0 or 1
+for success or failures, or, more rarely, 127 or 128 for certain very
+specific failures.  git-annex itself should return 0 on success and 1 on
+failure, unless the `--time-limit=time` option is hit, in which case it
+returns with exit code 101.
+
 # FILES
 
 These files are used by git-annex:

Added a comment
diff --git a/doc/forum/Question:_git-annex-only_repo___63__/comment_2_941b62a63c11caa1ada5d544c2e926ca._comment b/doc/forum/Question:_git-annex-only_repo___63__/comment_2_941b62a63c11caa1ada5d544c2e926ca._comment
new file mode 100644
index 0000000..fdde45b
--- /dev/null
+++ b/doc/forum/Question:_git-annex-only_repo___63__/comment_2_941b62a63c11caa1ada5d544c2e926ca._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="boustanihani@93604388a6a2b8df16f3e34157232801a67c1021"
+ nickname="boustanihani"
+ subject="comment 2"
+ date="2015-06-23T12:42:46Z"
+ content="""
+you mean there is no need for track then ?
+"""]]

Added a comment: Repository groups
diff --git a/doc/forum/Git-annex_assistant:_where_are_deleted_files_and_older_versions_saved__63__/comment_1_d9acd44c00676d814e19613d6fd276a2._comment b/doc/forum/Git-annex_assistant:_where_are_deleted_files_and_older_versions_saved__63__/comment_1_d9acd44c00676d814e19613d6fd276a2._comment
new file mode 100644
index 0000000..a491572
--- /dev/null
+++ b/doc/forum/Git-annex_assistant:_where_are_deleted_files_and_older_versions_saved__63__/comment_1_d9acd44c00676d814e19613d6fd276a2._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="Marco"
+ subject="Repository groups"
+ date="2015-06-23T12:21:58Z"
+ content="""
+Have a look at the [[preferred_content/standard_groups]] page. Backup Repositories want to get hold of anything.
+
+> anything
+>
+>Matches any version of any file.
+
+So if you have the assistant running it will take care of pushing the old versions in the backup.
+"""]]

Added a comment: Yes
diff --git a/doc/forum/Question:_git-annex-only_repo___63__/comment_1_321632cc794c00181932f5737db9aff0._comment b/doc/forum/Question:_git-annex-only_repo___63__/comment_1_321632cc794c00181932f5737db9aff0._comment
new file mode 100644
index 0000000..b69abb3
--- /dev/null
+++ b/doc/forum/Question:_git-annex-only_repo___63__/comment_1_321632cc794c00181932f5737db9aff0._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Marco"
+ subject="Yes"
+ date="2015-06-23T12:12:52Z"
+ content="""
+Yes, you can do this. Simply set up a git annex repo and you are ready to go.
+If you have the assistant running in the background it will take care of committing and distributing the files around.
+"""]]

diff --git a/doc/forum/Question:_git-annex-only_repo___63__.mdwn b/doc/forum/Question:_git-annex-only_repo___63__.mdwn
new file mode 100644
index 0000000..e6b5ab6
--- /dev/null
+++ b/doc/forum/Question:_git-annex-only_repo___63__.mdwn
@@ -0,0 +1,3 @@
+Is there a way to declare (init) a git-annex-only repository?
+
+I mean if the repository will only contain large (or maybe binary) files without any source-code... In that case all files added to the repo should be managed by git-annex automatically. Is this currently possible?

diff --git a/doc/bugs/view_fails_with___34__invalid_character__34__.mdwn b/doc/bugs/view_fails_with___34__invalid_character__34__.mdwn
new file mode 100644
index 0000000..4b6e977
--- /dev/null
+++ b/doc/bugs/view_fails_with___34__invalid_character__34__.mdwn
@@ -0,0 +1,30 @@
+### Please describe the problem.
+I have a "person" attribute with the name of the people on the picture. I could create views and filter on that some time ago, but it looks like git annex now chokes on some illegal (accented?) characters. I have non-ASCII characters in names for sure.
+
+### What steps will reproduce the problem?
+Try to create a view using the "person" attribute.
+
+### What version of git-annex are you using? On what operating system?
+5.20150617-gac09445 on ArchLinux
+
+### Please provide any additional information below.
+
+[[!format sh """
+% git annex view person="*"
+/bin/sh: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
+view  (searching...)
+
+git-annex: fd:14: commitBuffer: invalid argument (invalid character)
+failed
+git-annex: view: 1 failed
+
+% git annex version
+/bin/sh: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
+git-annex version: 5.20150617-gac09445
+build flags: Assistant Webapp Webapp-secure Pairing Testsuite S3 WebDAV Inotify DBus DesktopNotify XMPP DNS Feeds Quvi TDFA
+key/value backends: SHA256E SHA1E SHA512E SHA224E SHA384E SKEIN256E SKEIN512E MD5E SHA256 SHA1 SHA512 SHA224 SHA384 SKEIN256 SKEIN512 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 version: 5
+upgrade supported from repository versions: 0 1 2 4
+"""]]

use real names used in the content expressions
diff --git a/doc/preferred_content/standard_groups.mdwn b/doc/preferred_content/standard_groups.mdwn
index 21a918c..b05394a 100644
--- a/doc/preferred_content/standard_groups.mdwn
+++ b/doc/preferred_content/standard_groups.mdwn
@@ -51,21 +51,21 @@ All content is wanted. Even content of old/deleted files.
 
 `anything`
 
-### incremental backup
+### incrementalbackup
 
 Only wants content that's not already backed up to another backup
 or incremental backup repository.
 
 `((not copies=backup:1) and (not copies=incrementalbackup:1)) or approxlackingcopies=1`
 
-### small archive
+### smallarchive
 
 Only wants content that's located in an "archive" directory, and
 only if it's not already been archived somewhere else.
 
 `((include=*/archive/* or include=archive/*) and not (copies=archive:1 or copies=smallarchive:1)) or approxlackingcopies=1`
 
-### full archive
+### archive
 
 All content is wanted, unless it's already been archived somewhere else.
 

Added a comment: it's git annex info, not status
diff --git a/doc/forum/gadu_-_git-annex_disk_usage/comment_14_d8f69914b88feb3f3ed4f72c26dd74e5._comment b/doc/forum/gadu_-_git-annex_disk_usage/comment_14_d8f69914b88feb3f3ed4f72c26dd74e5._comment
new file mode 100644
index 0000000..33fca77
--- /dev/null
+++ b/doc/forum/gadu_-_git-annex_disk_usage/comment_14_d8f69914b88feb3f3ed4f72c26dd74e5._comment
@@ -0,0 +1,231 @@
+[[!comment format=mdwn
+ username="anarcat"
+ subject="it's git annex info, not status"
+ date="2015-06-23T04:15:24Z"
+ content="""
+so the previous comments by joeyh were correct 2 years ago, but now git annex status behaves more like git-status than anything else, and will *not* give you disk usage.
+
+however, `git annex info` will, and if you use `--fast`, it works pretty fast as well. example, on my pictures collection:
+
+<pre>
+[1044]anarcat@marcos:Photos$ time git annex info --fast *
+directory: 1969
+local annex keys: 5
+local annex size: 10.95 megabytes
+annexed files in working tree: 5
+size of annexed files in working tree: 10.95 megabytes
+directory: 1970
+local annex keys: 26
+local annex size: 827.5 megabytes
+annexed files in working tree: 26
+size of annexed files in working tree: 827.5 megabytes
+directory: 1998
+local annex keys: 10
+local annex size: 3.31 megabytes
+annexed files in working tree: 10
+size of annexed files in working tree: 3.31 megabytes
+directory: 2004
+local annex keys: 49
+local annex size: 42.01 megabytes
+annexed files in working tree: 49
+size of annexed files in working tree: 42.01 megabytes
+directory: 2005
+local annex keys: 561
+local annex size: 379.23 megabytes
+annexed files in working tree: 561
+size of annexed files in working tree: 379.23 megabytes
+directory: 2006
+local annex keys: 932
+local annex size: 995.95 megabytes
+annexed files in working tree: 932
+size of annexed files in working tree: 995.95 megabytes
+directory: 2007
+local annex keys: 1162
+local annex size: 2.33 gigabytes
+annexed files in working tree: 1162
+size of annexed files in working tree: 2.33 gigabytes
+directory: 2008
+local annex keys: 658
+local annex size: 934.88 megabytes
+annexed files in working tree: 658
+size of annexed files in working tree: 934.88 megabytes
+directory: 2009
+local annex keys: 500
+local annex size: 836.65 megabytes
+annexed files in working tree: 500
+size of annexed files in working tree: 836.65 megabytes
+directory: 2010
+local annex keys: 1049
+local annex size: 1.85 gigabytes
+annexed files in working tree: 1049
+size of annexed files in working tree: 1.85 gigabytes
+directory: 2011
+local annex keys: 1206
+local annex size: 1.54 gigabytes
+annexed files in working tree: 1206
+size of annexed files in working tree: 1.54 gigabytes
+directory: 2012
+local annex keys: 2767
+local annex size: 10.52 gigabytes
+annexed files in working tree: 2767
+size of annexed files in working tree: 10.52 gigabytes
+directory: 2013
+local annex keys: 4071
+local annex size: 32.49 gigabytes
+annexed files in working tree: 4071
+size of annexed files in working tree: 32.49 gigabytes
+directory: 2014
+local annex keys: 6930
+local annex size: 27.34 gigabytes
+annexed files in working tree: 6930
+size of annexed files in working tree: 27.34 gigabytes
+directory: 2015
+local annex keys: 2134
+local annex size: 8.07 gigabytes
+annexed files in working tree: 2134
+size of annexed files in working tree: 8.07 gigabytes
+directory: rando-velo
+local annex keys: 184
+local annex size: 537.58 megabytes
+annexed files in working tree: 184
+size of annexed files in working tree: 537.58 megabytes
+directory: RMLL2008-Koumbit
+local annex keys: 11
+local annex size: 25.58 megabytes
+annexed files in working tree: 11
+size of annexed files in working tree: 25.58 megabytes
+5.47user 1.75system 0:14.70elapsed 49%CPU (0avgtext+0avgdata 30524maxresident)k
+121136inputs+0outputs (2major+18418minor)pagefaults 0swaps
+</pre>
+
+whereas without `--fast` is much slower, presumably because it's fetching the tracking information:
+
+<pre>
+[1045]anarcat@marcos:Photos$ time git annex info  *
+directory: 1969
+local annex keys: 5
+local annex size: 10.95 megabytes
+annexed files in working tree: 5
+size of annexed files in working tree: 10.95 megabytes
+numcopies stats:
+        numcopies +0: 5
+directory: 1970
+local annex keys: 26
+local annex size: 827.5 megabytes
+annexed files in working tree: 26
+size of annexed files in working tree: 827.5 megabytes
+numcopies stats:
+        numcopies +0: 26
+directory: 1998
+local annex keys: 10
+local annex size: 3.31 megabytes
+annexed files in working tree: 10
+size of annexed files in working tree: 3.31 megabytes
+numcopies stats:
+        numcopies +0: 10
+directory: 2004
+local annex keys: 49
+local annex size: 42.01 megabytes
+annexed files in working tree: 49
+size of annexed files in working tree: 42.01 megabytes
+numcopies stats:
+        numcopies +0: 49
+directory: 2005
+local annex keys: 561
+local annex size: 379.23 megabytes
+annexed files in working tree: 561
+size of annexed files in working tree: 379.23 megabytes
+numcopies stats:
+        numcopies +0: 561
+directory: 2006
+local annex keys: 932
+local annex size: 995.95 megabytes
+annexed files in working tree: 932
+size of annexed files in working tree: 995.95 megabytes
+numcopies stats:
+        numcopies +0: 932
+directory: 2007
+local annex keys: 1162
+local annex size: 2.33 gigabytes
+annexed files in working tree: 1162
+size of annexed files in working tree: 2.33 gigabytes
+numcopies stats:
+        numcopies +0: 1162
+directory: 2008
+local annex keys: 658
+local annex size: 934.88 megabytes
+annexed files in working tree: 658
+size of annexed files in working tree: 934.88 megabytes
+numcopies stats:
+        numcopies +0: 658
+directory: 2009
+local annex keys: 500
+local annex size: 836.65 megabytes
+annexed files in working tree: 500
+size of annexed files in working tree: 836.65 megabytes
+numcopies stats:
+        numcopies +0: 500
+directory: 2010
+local annex keys: 1049
+local annex size: 1.85 gigabytes
+annexed files in working tree: 1049
+size of annexed files in working tree: 1.85 gigabytes
+numcopies stats:
+        numcopies +0: 1049
+directory: 2011
+local annex keys: 1206
+local annex size: 1.54 gigabytes
+annexed files in working tree: 1206
+size of annexed files in working tree: 1.54 gigabytes
+numcopies stats:
+        numcopies +0: 1206
+directory: 2012
+local annex keys: 2767
+local annex size: 10.52 gigabytes
+annexed files in working tree: 2767
+size of annexed files in working tree: 10.52 gigabytes
+numcopies stats:
+        numcopies +0: 2767
+directory: 2013
+local annex keys: 4071
+local annex size: 32.49 gigabytes
+annexed files in working tree: 4071
+size of annexed files in working tree: 32.49 gigabytes
+numcopies stats:

(Diff truncated)
clarify issue
diff --git a/doc/todo/git-annex_info___34__du__34___remote_support.mdwn b/doc/todo/git-annex_info___34__du__34___remote_support.mdwn
index 2df6096..42aa5bd 100644
--- a/doc/todo/git-annex_info___34__du__34___remote_support.mdwn
+++ b/doc/todo/git-annex_info___34__du__34___remote_support.mdwn
@@ -1,4 +1,4 @@
-so i know about the various discussions around a `du` that follows git-annex symlinks (e.g. [[forum/__34__du__34___equivalent_on_an_annex__63__/]] or [[forum/gadu_-_git-annex_disk_usage/]]. this is not about that. :)
+so i know about the various discussions around a `du` that follows git-annex symlinks (e.g. [[forum/__34__du__34___equivalent_on_an_annex__63__/]] or [[forum/gadu_-_git-annex_disk_usage/]]. this is not about that, or at least not directly. :)
 
 i believe there's a distinct use-case for a simpler `du` subcommand that will calculate the disk space used locally (in case of the default `--in here`) but could also use the tracking log to determine the space usage in *other* locations. this would be especially useful on remotes that we don't have shell access to, s3 comes to mind. i thought that `git annex info` could output that, but it seems it doesn't:
 
@@ -34,6 +34,7 @@ bloom filter size: 16 mebibytes (0% full)
 backend usage:
 </pre>
 
-you can see the advantage of having a separate du command above: first off, it would give directly the information we're looking for. it could also work on remote repositories, use the powerful pattern matching, and so on...
+just to be clear here, the problem isn't as much providing `du-like output`, which `git annex info $path` does pretty well. the problem is that it doesn't work on remote servers, at least that is what i observed above.
+
+i still think it would be nice to have a `du` command, just because it's a command "WTF" situation users seem to get stuck into.. but this issue is only about having this work on remote repositories. thanks! -- [[anarcat]]
 
-thanks! [[anarcat]]

rename todo/git-annex_du.mdwn to todo/git-annex_info___34__du__34___remote_support.mdwn
diff --git a/doc/todo/git-annex_du.mdwn b/doc/todo/git-annex_du.mdwn
deleted file mode 100644
index 2df6096..0000000
--- a/doc/todo/git-annex_du.mdwn
+++ /dev/null
@@ -1,39 +0,0 @@
-so i know about the various discussions around a `du` that follows git-annex symlinks (e.g. [[forum/__34__du__34___equivalent_on_an_annex__63__/]] or [[forum/gadu_-_git-annex_disk_usage/]]. this is not about that. :)
-
-i believe there's a distinct use-case for a simpler `du` subcommand that will calculate the disk space used locally (in case of the default `--in here`) but could also use the tracking log to determine the space usage in *other* locations. this would be especially useful on remotes that we don't have shell access to, s3 comes to mind. i thought that `git annex info` could output that, but it seems it doesn't:
-
-<pre>
-$ git annex info . --in s3 --exclude='video/original/*'
-directory: .
-local annex keys: 0
-local annex size: 0 bytes
-annexed files in working tree: 0
-size of annexed files in working tree: 0 bytes
-numcopies stats:
-repositories containing these files:
-$ git annex info --in s3 --exclude='video/original/*'
-repository mode: indirect
-trusted repositories: 0
-semitrusted repositories: 6
-        00000000-0000-0000-0000-000000000002 -- bittorrent
-        2d61a8de-a24e-44e3-9aa0-54f033fec1e9 -- host-mp20120507-1.mp.isuma.tv
-        9401d7b3-44d2-48ab-a9f1-c77fac469a1a -- s3
-        c510ddad-24cd-4353-b5f4-03581f6f9dca -- cs.isuma.tv [here]
-        d2a7d4ff-1dbf-4bfa-bb97-ae593626daf6 -- sneakernet
-        e747d5c8-ea47-480f-8c5d-2986ce65ed89 -- isuma.tv
-untrusted repositories: 2
-        00000000-0000-0000-0000-000000000001 -- web
-        36d2cb94-e0a2-446a-87c9-02f73135b302 -- anarcat@desktop008:~/src/isuma/isuma-files
-transfers in progress: none
-available local disk space: 67.66 gigabytes (+1 megabyte reserved)
-local annex keys: 0
-local annex size: 0 bytes
-annexed files in working tree: 0
-size of annexed files in working tree: 0 bytes
-bloom filter size: 16 mebibytes (0% full)
-backend usage:
-</pre>
-
-you can see the advantage of having a separate du command above: first off, it would give directly the information we're looking for. it could also work on remote repositories, use the powerful pattern matching, and so on...
-
-thanks! [[anarcat]]
diff --git a/doc/todo/git-annex_info___34__du__34___remote_support.mdwn b/doc/todo/git-annex_info___34__du__34___remote_support.mdwn
new file mode 100644
index 0000000..2df6096
--- /dev/null
+++ b/doc/todo/git-annex_info___34__du__34___remote_support.mdwn
@@ -0,0 +1,39 @@
+so i know about the various discussions around a `du` that follows git-annex symlinks (e.g. [[forum/__34__du__34___equivalent_on_an_annex__63__/]] or [[forum/gadu_-_git-annex_disk_usage/]]. this is not about that. :)
+
+i believe there's a distinct use-case for a simpler `du` subcommand that will calculate the disk space used locally (in case of the default `--in here`) but could also use the tracking log to determine the space usage in *other* locations. this would be especially useful on remotes that we don't have shell access to, s3 comes to mind. i thought that `git annex info` could output that, but it seems it doesn't:
+
+<pre>
+$ git annex info . --in s3 --exclude='video/original/*'
+directory: .
+local annex keys: 0
+local annex size: 0 bytes
+annexed files in working tree: 0
+size of annexed files in working tree: 0 bytes
+numcopies stats:
+repositories containing these files:
+$ git annex info --in s3 --exclude='video/original/*'
+repository mode: indirect
+trusted repositories: 0
+semitrusted repositories: 6
+        00000000-0000-0000-0000-000000000002 -- bittorrent
+        2d61a8de-a24e-44e3-9aa0-54f033fec1e9 -- host-mp20120507-1.mp.isuma.tv
+        9401d7b3-44d2-48ab-a9f1-c77fac469a1a -- s3
+        c510ddad-24cd-4353-b5f4-03581f6f9dca -- cs.isuma.tv [here]
+        d2a7d4ff-1dbf-4bfa-bb97-ae593626daf6 -- sneakernet
+        e747d5c8-ea47-480f-8c5d-2986ce65ed89 -- isuma.tv
+untrusted repositories: 2
+        00000000-0000-0000-0000-000000000001 -- web
+        36d2cb94-e0a2-446a-87c9-02f73135b302 -- anarcat@desktop008:~/src/isuma/isuma-files
+transfers in progress: none
+available local disk space: 67.66 gigabytes (+1 megabyte reserved)
+local annex keys: 0
+local annex size: 0 bytes
+annexed files in working tree: 0
+size of annexed files in working tree: 0 bytes
+bloom filter size: 16 mebibytes (0% full)
+backend usage:
+</pre>
+
+you can see the advantage of having a separate du command above: first off, it would give directly the information we're looking for. it could also work on remote repositories, use the powerful pattern matching, and so on...
+
+thanks! [[anarcat]]

diff --git a/doc/bugs/Android_build_missing_webapp.mdwn b/doc/bugs/Android_build_missing_webapp.mdwn
new file mode 100644
index 0000000..8f18725
--- /dev/null
+++ b/doc/bugs/Android_build_missing_webapp.mdwn
@@ -0,0 +1,31 @@
+### Please describe the problem.
+
+Setting git-annex on an Android device (either the released version, or the autobuilder apk), I'm told:
+
+[[!format sh """
+git-annex: unknown command webapp
+"""]]
+
+Looking in the logs on the Android autobuilder I see many instances of:
+
+[[!format sh """
+#warning Building without the webapp. You probably need to install Yesod..
+"""]]
+
+### What steps will reproduce the problem?
+
+Run git-annex.
+
+### What version of git-annex are you using? On what operating system?
+
+v5.20150617~g031b85a
+
+### Please provide any additional information below.
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+
+
+# End of transcript or log.
+"""]]

diff --git a/doc/todo/Set_total_storage_limit_for_special_remotes..mdwn b/doc/todo/Set_total_storage_limit_for_special_remotes..mdwn
new file mode 100644
index 0000000..2b66e98
--- /dev/null
+++ b/doc/todo/Set_total_storage_limit_for_special_remotes..mdwn
@@ -0,0 +1 @@
+I'd like to be able to set a fixed limit on how much storage can be uploaded to a special remote. A use case for this may be that I want to spend no more than Y dollars, on a storage service that charges $X per gigabyte. I would thus set a limit where I a upload would be interrupted with a warning about the limit, and to continue I would need to use a --force option.

another idea...
diff --git a/doc/todo/git-annex_du.mdwn b/doc/todo/git-annex_du.mdwn
new file mode 100644
index 0000000..2df6096
--- /dev/null
+++ b/doc/todo/git-annex_du.mdwn
@@ -0,0 +1,39 @@
+so i know about the various discussions around a `du` that follows git-annex symlinks (e.g. [[forum/__34__du__34___equivalent_on_an_annex__63__/]] or [[forum/gadu_-_git-annex_disk_usage/]]. this is not about that. :)
+
+i believe there's a distinct use-case for a simpler `du` subcommand that will calculate the disk space used locally (in case of the default `--in here`) but could also use the tracking log to determine the space usage in *other* locations. this would be especially useful on remotes that we don't have shell access to, s3 comes to mind. i thought that `git annex info` could output that, but it seems it doesn't:
+
+<pre>
+$ git annex info . --in s3 --exclude='video/original/*'
+directory: .
+local annex keys: 0
+local annex size: 0 bytes
+annexed files in working tree: 0
+size of annexed files in working tree: 0 bytes
+numcopies stats:
+repositories containing these files:
+$ git annex info --in s3 --exclude='video/original/*'
+repository mode: indirect
+trusted repositories: 0
+semitrusted repositories: 6
+        00000000-0000-0000-0000-000000000002 -- bittorrent
+        2d61a8de-a24e-44e3-9aa0-54f033fec1e9 -- host-mp20120507-1.mp.isuma.tv
+        9401d7b3-44d2-48ab-a9f1-c77fac469a1a -- s3
+        c510ddad-24cd-4353-b5f4-03581f6f9dca -- cs.isuma.tv [here]
+        d2a7d4ff-1dbf-4bfa-bb97-ae593626daf6 -- sneakernet
+        e747d5c8-ea47-480f-8c5d-2986ce65ed89 -- isuma.tv
+untrusted repositories: 2
+        00000000-0000-0000-0000-000000000001 -- web
+        36d2cb94-e0a2-446a-87c9-02f73135b302 -- anarcat@desktop008:~/src/isuma/isuma-files
+transfers in progress: none
+available local disk space: 67.66 gigabytes (+1 megabyte reserved)
+local annex keys: 0
+local annex size: 0 bytes
+annexed files in working tree: 0
+size of annexed files in working tree: 0 bytes
+bloom filter size: 16 mebibytes (0% full)
+backend usage:
+</pre>
+
+you can see the advantage of having a separate du command above: first off, it would give directly the information we're looking for. it could also work on remote repositories, use the powerful pattern matching, and so on...
+
+thanks! [[anarcat]]

rename bugs/--raw.mdwn to bugs/log_fails_with_-raw_error.mdwn
diff --git a/doc/bugs/--raw.mdwn b/doc/bugs/--raw.mdwn
deleted file mode 100644
index 86abd5d..0000000
--- a/doc/bugs/--raw.mdwn
+++ /dev/null
@@ -1,45 +0,0 @@
-### Please describe the problem.
-
-`git-annex log` fails to run if git is an older version.
-
-### What steps will reproduce the problem?
-
-`git-annex log` :)
-
-i somewhat thought that this would work even if i had an older version of git because the standalone release would use the bundled git release...
-
-### What version of git-annex are you using? On what operating system?
-
-5.20150610+gitg608172f-1~ndall+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
-$ git annex log video/mp4_sd/TV23_-_TV_Show_Excerpts_-Research.mov.mp4
-fatal: unrecognized argument: -raw
-
-$ git annex --debug log video/mp4_sd/TV23_-_TV_Show_Excerpts_-Research.mov.mp4
-[2015-06-22 17:34:17 EDT] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","git-annex"]
-[2015-06-22 17:34:17 EDT] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","--hash","refs/heads/git-annex"]
-[2015-06-22 17:34:17 EDT] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","log","refs/heads/git-annex..8bf42e9c6e5b301f487a2d2d596d7cef12a3283d","-n1","--pretty=%H"]
-[2015-06-22 17:34:17 EDT] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","log","refs/heads/git-annex..9a7b6b197d5271c29034d47e908fec7de6ea7e5a","-n1","--pretty=%H"]
-[2015-06-22 17:34:17 EDT] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch"]
-[2015-06-22 17:34:17 EDT] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","ls-files","--cached","-z","--","video/mp4_sd/TV23_-_TV_Show_Excerpts_-Research.mov.mp4"]
-[2015-06-22 17:34:17 EDT] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","log","-z","--pretty=format:%ct","-raw","--abbrev=40","--remove-empty","refs/heads/git-annex","--","d65/b94/SHA256E-s493891859--5413dd9efe00cbc091e78a7ce6a7034be0e6e121b7faaa054ad2836f8a80aaad.mov.mp4.log"]
-fatal: unrecognized argument: -raw
-$ git --version
-git version 1.7.10.4
-$ git annex version
-git-annex version: 5.20150610+gitg608172f-1~ndall+1
-build flags: Assistant Webapp Webapp-secure Pairing Testsuite S3 WebDAV Inotify DBus DesktopNotify XMPP DNS Feeds Quvi TDFA
-key/value backends: SHA256E SHA1E SHA512E SHA224E SHA384E SKEIN256E SKEIN512E MD5E SHA256 SHA1 SHA512 SHA224 SHA384 SKEIN256 SKEIN512 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 version: 5
-upgrade supported from repository versions: 0 1 2 4
-# End of transcript or log.
-"""]]
-
---[[anarcat]]
diff --git a/doc/bugs/log_fails_with_-raw_error.mdwn b/doc/bugs/log_fails_with_-raw_error.mdwn
new file mode 100644
index 0000000..86abd5d
--- /dev/null
+++ b/doc/bugs/log_fails_with_-raw_error.mdwn
@@ -0,0 +1,45 @@
+### Please describe the problem.
+
+`git-annex log` fails to run if git is an older version.
+
+### What steps will reproduce the problem?
+
+`git-annex log` :)
+
+i somewhat thought that this would work even if i had an older version of git because the standalone release would use the bundled git release...
+
+### What version of git-annex are you using? On what operating system?
+
+5.20150610+gitg608172f-1~ndall+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
+$ git annex log video/mp4_sd/TV23_-_TV_Show_Excerpts_-Research.mov.mp4
+fatal: unrecognized argument: -raw
+
+$ git annex --debug log video/mp4_sd/TV23_-_TV_Show_Excerpts_-Research.mov.mp4
+[2015-06-22 17:34:17 EDT] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","git-annex"]
+[2015-06-22 17:34:17 EDT] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","--hash","refs/heads/git-annex"]
+[2015-06-22 17:34:17 EDT] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","log","refs/heads/git-annex..8bf42e9c6e5b301f487a2d2d596d7cef12a3283d","-n1","--pretty=%H"]
+[2015-06-22 17:34:17 EDT] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","log","refs/heads/git-annex..9a7b6b197d5271c29034d47e908fec7de6ea7e5a","-n1","--pretty=%H"]
+[2015-06-22 17:34:17 EDT] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch"]
+[2015-06-22 17:34:17 EDT] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","ls-files","--cached","-z","--","video/mp4_sd/TV23_-_TV_Show_Excerpts_-Research.mov.mp4"]
+[2015-06-22 17:34:17 EDT] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","log","-z","--pretty=format:%ct","-raw","--abbrev=40","--remove-empty","refs/heads/git-annex","--","d65/b94/SHA256E-s493891859--5413dd9efe00cbc091e78a7ce6a7034be0e6e121b7faaa054ad2836f8a80aaad.mov.mp4.log"]
+fatal: unrecognized argument: -raw
+$ git --version
+git version 1.7.10.4
+$ git annex version
+git-annex version: 5.20150610+gitg608172f-1~ndall+1
+build flags: Assistant Webapp Webapp-secure Pairing Testsuite S3 WebDAV Inotify DBus DesktopNotify XMPP DNS Feeds Quvi TDFA
+key/value backends: SHA256E SHA1E SHA512E SHA224E SHA384E SKEIN256E SKEIN512E MD5E SHA256 SHA1 SHA512 SHA224 SHA384 SKEIN256 SKEIN512 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 version: 5
+upgrade supported from repository versions: 0 1 2 4
+# End of transcript or log.
+"""]]
+
+--[[anarcat]]

weird git-annex log bug
diff --git a/doc/bugs/--raw.mdwn b/doc/bugs/--raw.mdwn
new file mode 100644
index 0000000..86abd5d
--- /dev/null
+++ b/doc/bugs/--raw.mdwn
@@ -0,0 +1,45 @@
+### Please describe the problem.
+
+`git-annex log` fails to run if git is an older version.
+
+### What steps will reproduce the problem?
+
+`git-annex log` :)
+
+i somewhat thought that this would work even if i had an older version of git because the standalone release would use the bundled git release...
+
+### What version of git-annex are you using? On what operating system?
+
+5.20150610+gitg608172f-1~ndall+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
+$ git annex log video/mp4_sd/TV23_-_TV_Show_Excerpts_-Research.mov.mp4
+fatal: unrecognized argument: -raw
+
+$ git annex --debug log video/mp4_sd/TV23_-_TV_Show_Excerpts_-Research.mov.mp4
+[2015-06-22 17:34:17 EDT] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","git-annex"]
+[2015-06-22 17:34:17 EDT] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","--hash","refs/heads/git-annex"]
+[2015-06-22 17:34:17 EDT] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","log","refs/heads/git-annex..8bf42e9c6e5b301f487a2d2d596d7cef12a3283d","-n1","--pretty=%H"]
+[2015-06-22 17:34:17 EDT] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","log","refs/heads/git-annex..9a7b6b197d5271c29034d47e908fec7de6ea7e5a","-n1","--pretty=%H"]
+[2015-06-22 17:34:17 EDT] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch"]
+[2015-06-22 17:34:17 EDT] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","ls-files","--cached","-z","--","video/mp4_sd/TV23_-_TV_Show_Excerpts_-Research.mov.mp4"]
+[2015-06-22 17:34:17 EDT] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","log","-z","--pretty=format:%ct","-raw","--abbrev=40","--remove-empty","refs/heads/git-annex","--","d65/b94/SHA256E-s493891859--5413dd9efe00cbc091e78a7ce6a7034be0e6e121b7faaa054ad2836f8a80aaad.mov.mp4.log"]
+fatal: unrecognized argument: -raw
+$ git --version
+git version 1.7.10.4
+$ git annex version
+git-annex version: 5.20150610+gitg608172f-1~ndall+1
+build flags: Assistant Webapp Webapp-secure Pairing Testsuite S3 WebDAV Inotify DBus DesktopNotify XMPP DNS Feeds Quvi TDFA
+key/value backends: SHA256E SHA1E SHA512E SHA224E SHA384E SKEIN256E SKEIN512E MD5E SHA256 SHA1 SHA512 SHA224 SHA384 SKEIN256 SKEIN512 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 version: 5
+upgrade supported from repository versions: 0 1 2 4
+# End of transcript or log.
+"""]]
+
+--[[anarcat]]

diff --git a/doc/bugs/migrate_and_move_duplicates_data.mdwn b/doc/bugs/migrate_and_move_duplicates_data.mdwn
new file mode 100644
index 0000000..4f962cd
--- /dev/null
+++ b/doc/bugs/migrate_and_move_duplicates_data.mdwn
@@ -0,0 +1,36 @@
+### Please describe the problem.
+
+I have a main annex with ~2TB of data. In the past is was using SHA256 then I migrated to SHA256E . Recently it was becoming quite full so I took some spare HD and cloned it and moved data from the main to the spares. To my surprise, the main annex disk usage did not go down a bit.
+
+It took me some time to understand why . The problem is exemplified by the  shell script  <http://mennucc1.debian.net/git-annex/git-annex-no-dedup.sh> .
+
+In short, if a annex is migrated to a new backend and afterwards files are moved, then the hardlinks are broken, and disk usage doubles.
+
+### What steps will reproduce the problem?
+
+run above script
+
+### What version of git-annex are you using? On what operating system?
+
+ 5.20141125  on Debian Jessie amd64
+
+### Please provide any additional information below.
+
+Of course a simple solution would be to drop all unused files. This is ugly , though, because it does not distinguish between
+(1) unused files that are previous copies of files I care about (2) unused files that are due to the problem described in the example, and that I do not care about.
+
+A more complex but more elegant solution would be:
+
+(a) when a file is migrated , the old and new objects in the annex are hardlinked; moreover two symlinks should be creates, so that git-annex knows at a glance which two files are hardlinked (see <http://mennucc1.debian.net/git-annex/cross_links.txt> for example)
+
+(b) when moving of copying files, all hardlinked versions whould be move/copied
+
+(c) when dropping , an option may be used to specify if all hardlinked versions should be dropped alltogether
+
+### bye
+
+and thanks, A.
+
+### ps
+
+I tried to attach two files to this bug report but failed

diff --git a/doc/bugs/git-annex_sync_under_windows_fails_by_using_itself_as_the_ssh_command.mdwn b/doc/bugs/git-annex_sync_under_windows_fails_by_using_itself_as_the_ssh_command.mdwn
index 4da5d45..edfa5f1 100644
--- a/doc/bugs/git-annex_sync_under_windows_fails_by_using_itself_as_the_ssh_command.mdwn
+++ b/doc/bugs/git-annex_sync_under_windows_fails_by_using_itself_as_the_ssh_command.mdwn
@@ -12,6 +12,17 @@ Thanks,
 
 Johannes
 
+PS:
+
+I found that after reverting commit a6d54e49a0676e1c8e4b3202b29c7725f45fa784 the git fetch command will work, but git push origin will fail:
+
+push origin [2015-06-21 00:25:32 ric] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","core.bare=false","push","origin","+git-annex:synced/git-annex","annex/direct/master:synced/master"]
+Bad port ''
+fatal: Could not read from remote repository.
+
+Please make sure you have the correct access rights
+and the repository exists.
+
 
 ### What steps will reproduce the problem?
 

diff --git a/doc/forum/Git-annex_assistant:_where_are_deleted_files_and_older_versions_saved__63__.mdwn b/doc/forum/Git-annex_assistant:_where_are_deleted_files_and_older_versions_saved__63__.mdwn
index 125c780..7771403 100644
--- a/doc/forum/Git-annex_assistant:_where_are_deleted_files_and_older_versions_saved__63__.mdwn
+++ b/doc/forum/Git-annex_assistant:_where_are_deleted_files_and_older_versions_saved__63__.mdwn
@@ -3,6 +3,7 @@ Hello,
 first of all thank you very much for Git-annex: I think it is a great tool to keep files in sync. The feature I like most is the possibility of setting multiple remote servers and execute syncs in a decentralized fashion; this is great for me since I have multiple computers spreaded around but not all of them are always up and almost none is "99.99% guaranteed" and I need high availability.
 
 Getting to the poing: I set up git-annex manually on my computers (most remote are only accessible via ssh tunnels) and I am using it in direct mode, with the assistant running in background on every node. From time to time I open the webapp to check if everything looks fine. Finally, I set a couple of nodes (with plenty of storage) as 'full backup' even if I don't really understand what that setting is really for.
+
 My question is: in my setup, where do deleted files and older versions go? If I ever need one in the future where should I look for it?
 
 Thanks a million!

diff --git a/doc/forum/Git-annex_assistant:_where_are_deleted_files_and_older_versions_saved__63__.mdwn b/doc/forum/Git-annex_assistant:_where_are_deleted_files_and_older_versions_saved__63__.mdwn
new file mode 100644
index 0000000..125c780
--- /dev/null
+++ b/doc/forum/Git-annex_assistant:_where_are_deleted_files_and_older_versions_saved__63__.mdwn
@@ -0,0 +1,8 @@
+Hello,
+
+first of all thank you very much for Git-annex: I think it is a great tool to keep files in sync. The feature I like most is the possibility of setting multiple remote servers and execute syncs in a decentralized fashion; this is great for me since I have multiple computers spreaded around but not all of them are always up and almost none is "99.99% guaranteed" and I need high availability.
+
+Getting to the poing: I set up git-annex manually on my computers (most remote are only accessible via ssh tunnels) and I am using it in direct mode, with the assistant running in background on every node. From time to time I open the webapp to check if everything looks fine. Finally, I set a couple of nodes (with plenty of storage) as 'full backup' even if I don't really understand what that setting is really for.
+My question is: in my setup, where do deleted files and older versions go? If I ever need one in the future where should I look for it?
+
+Thanks a million!

diff --git a/doc/bugs/git-annex_sync_under_windows_fails_by_using_itself_as_the_ssh_command.mdwn b/doc/bugs/git-annex_sync_under_windows_fails_by_using_itself_as_the_ssh_command.mdwn
index 04090bd..4da5d45 100644
--- a/doc/bugs/git-annex_sync_under_windows_fails_by_using_itself_as_the_ssh_command.mdwn
+++ b/doc/bugs/git-annex_sync_under_windows_fails_by_using_itself_as_the_ssh_command.mdwn
@@ -7,6 +7,12 @@ It appears that git-annex sync invokes the git-annex executable with parameters
 
 git config.sshcaching is false.
 
+
+Thanks,
+
+Johannes
+
+
 ### What steps will reproduce the problem?
 
 I tried setting up the repository many different ways, using git bash, cmd.exe or cygwin bash and always get the same error after git annex sync.

diff --git a/doc/bugs/git-annex_sync_under_windows_fails_by_using_itself_as_the_ssh_command.mdwn b/doc/bugs/git-annex_sync_under_windows_fails_by_using_itself_as_the_ssh_command.mdwn
new file mode 100644
index 0000000..04090bd
--- /dev/null
+++ b/doc/bugs/git-annex_sync_under_windows_fails_by_using_itself_as_the_ssh_command.mdwn
@@ -0,0 +1,198 @@
+### Please describe the problem.
+I am cloning a remote annex repository to my Windows machine using git clone user@server:/home/user/data
+
+After I perform git annex init, git annex sync fails with an error complaining that user@server is an invalid command (complete log below).
+
+It appears that git-annex sync invokes the git-annex executable with parameters for the ssh command.
+
+git config.sshcaching is false.
+
+### What steps will reproduce the problem?
+
+I tried setting up the repository many different ways, using git bash, cmd.exe or cygwin bash and always get the same error after git annex sync.
+
+
+### What version of git-annex are you using? On what operating system?
+C:\data_organization\data>git annex version
+git-annex version: 5.20150611-g256b86b
+build flags: Assistant Webapp Webapp-secure Pairing Testsuite S3 WebDAV DNS Feed
+s Quvi TDFA TorrentParser
+key/value backends: SHA256E SHA1E SHA512E SHA224E SHA384E SKEIN256E SKEIN512E MD
+5E SHA256 SHA1 SHA512 SHA224 SHA384 SKEIN256 SKEIN512 MD5 WORM URL
+remote types: git gcrypt S3 bup directory rsync web bittorrent webdav tahoe glac
+ier ddar hook external
+local repository version: 5
+supported repository version: 5
+upgrade supported from repository versions: 2 3 4
+
+I am using Windows 8.1
+
+### Please provide any additional information below.
+
+[[!format sh """
+
+C:\data_organization\data>git annex sync
+commit  ok
+pull origin
+git-annex.exe: unknown command user@55.89.78.37
+
+Usage: git-annex command [option ...]
+
+Commonly used commands:
+
+add             [PATH ...]         add files to annex
+addurl          URL ...            add urls to annex
+assistant                          automatically sync changes
+copy            [PATH ...]         copy content of files to/from another reposit
+ory
+drop            [PATH ...]         indicate content of files not currently wante
+d
+edit            [PATH ...]         same as unlock
+get             [PATH ...]         make content of annexed files available
+help            [COMMAND]          display help
+import          [PATH ...]         move and add files from outside git working c
+opy
+importfeed      URL ...            import files from podcast feeds
+lock            [PATH ...]         undo unlock command
+mirror          [PATH ...]         mirror content of files to/from another repos
+itory
+move            [PATH ...]         move content of files to/from another reposit
+ory
+rmurl           FILE URL           record file is not available at url
+status          [PATH ...]         show the working tree status
+sync            [REMOTE ...]       synchronize local repository with remotes
+undo            [PATH ...]         undo last change to a file or directory
+unlock          [PATH ...]         unlock files for modification
+watch                              watch for changes and autocommit
+webapp                             launch webapp
+
+Repository setup commands:
+
+dead            REMOTE ...         hide a lost repository or key
+describe        REMOTE DESC        change description of a repository
+direct                             switch repository to direct mode
+enableremote    NAME [K=V ...]     enables use of an existing special remote
+group           REMOTE DESC        add a repository to a group
+groupwanted     GROUP [EXPR]       get or set groupwanted expression
+indirect                           switch repository to indirect mode
+init            DESC               initialize git-annex
+initremote      NAME [K=V ...]     creates a special (non-git) remote
+numcopies       NUMBER             configure desired number of copies
+required        REMOTE [EXPR]      get or set required content expression
+schedule        REMOTE [EXPR]      get or set scheduled jobs
+semitrust       REMOTE ...         return repository to default trust level
+trust           REMOTE ...         trust a repository
+ungroup         REMOTE DESC        remove a repository from a group
+untrust         REMOTE ...         do not trust a repository
+vicfg                              edit git-annex's configuration
+wanted          REMOTE [EXPR]      get or set preferred content expression
+
+Repository maintenance commands:
+
+addunused       NUM|RANGE ...      add back unused files
+dropunused      NUM|RANGE ...      drop unused file content
+expire          [REMOTE]:TIME ...  expire inactive repositories
+fix             [PATH ...]         fix up symlinks to point to annexed content
+forget                             prune git-annex branch history
+fsck            [PATH ...]         check for problems
+merge                              automatically merge changes from remotes
+repair                             recover broken git repository
+unused                             look for unused file content
+upgrade                            upgrade repository layout
+
+Query commands:
+
+find            [PATH ...]         lists available files
+info            [ITEM ...]         shows information about the specified item or
+ the repository as a whole
+list            [PATH ...]         show which remotes contain files
+log             [PATH ...]         shows location log
+map                                generate map of repositories
+version                            show version info
+whereis         [PATH ...]         lists repositories that have file content
+
+Metadata commands:
+
+metadata        [PATH ...]         sets or gets metadata of a file
+vadd            FIELD=GLOB ...     add subdirs to current view
+vcycle                             switch view to next layout
+vfilter         FIELD=VALUE ...    filter current view
+view            FIELD=VALUE ...    enter a view branch
+vpop            [NUMBER]           switch back to previous view
+
+Utility commands:
+
+migrate         [PATH ...]         switch data to different backend
+reinit          UUID|DESC          initialize repository, reusing old UUID
+reinject        SRC DEST           sets content of annexed file
+unannex         [PATH ...]         undo accidential add command
+uninit          [PATH ...]         de-initialize git-annex and clean out reposit
+ory
+
+Plumbing commands:
+
+checkpresentkey KEY REMOTE         check if key is present in remote
+contentlocation KEY ...            looks up content for a key
+diffdriver      [-- cmd --]        external git diff driver shim
+dropkey         KEY ...            drops annexed content for specified keys
+examinekey      KEY ...            prints information from a key
+findref         REF                lists files in a git ref
+fromkey         KEY PATH           adds a file using a specific key
+lookupkey       FILE ...           looks up key used for file
+pre-commit      [PATH ...]         run by git pre-commit hook
+proxy           -- git command     safely bypass direct mode guard
+readpresentkey  KEY UUID           read records of where key is present
+registerurl     KEY URL            registers an url for a key
+rekey           [PATH KEY ...]     change keys used for files
+remotedaemon                       detects when remotes have changed, and fetche
+s from them
+resolvemerge                       resolve merge conflicts
+setpresentkey   KEY UUID [1|0]     change records of where key is present
+transferkey     KEY                transfers a key from or to a remote
+transferkeys                       transfers keys
+
+Testing commands:
+
+fuzztest                           generates fuzz test files
+test                               run built-in test suite
+testremote      REMOTE             test transfers to/from a remote
+
+fatal: Could not read from remote repository.
+
+Please make sure you have the correct access rights
+and the repository exists.
+failed
+push origin
+git-annex.exe: unrecognized option `-p'
+
+Usage: git-annex add [PATH ...] [option ...]
+           --include-dotfiles  don't skip dotfiles
+  -x GLOB  --exclude=GLOB      skip files matching the glob pattern
+  -I GLOB  --include=GLOB      limit to files matching the glob pattern
+           --largerthan=SIZE   match files larger than a size
+           --smallerthan=SIZE  match files smaller than a size
+           --not               negate next option
+           --and               both previous and next option must match
+           --or                either previous or next option must match
+  -(                           open group of options
+  -)                           close group of options
+
+To see additional options common to all commands, run: git annex help options
+
+
+fatal: Could not read from remote repository.
+
+Please make sure you have the correct access rights
+and the repository exists.
+
+  Pushing to origin failed.
+
+  (non-fast-forward problems can be solved by setting receive.denyNonFastforward
+s to false in the remote's git config)
+failed
+git-annex: sync: 2 failed
+

(Diff truncated)
proper way to override the download command?
diff --git a/doc/todo/easy_way_to_reproduce_normal_download_command.mdwn b/doc/todo/easy_way_to_reproduce_normal_download_command.mdwn
new file mode 100644
index 0000000..6846bc8
--- /dev/null
+++ b/doc/todo/easy_way_to_reproduce_normal_download_command.mdwn
@@ -0,0 +1,24 @@
+so there's a `annex.web-download-command` settings, great! i have used
+it to do bandwidth limitations with:
+
+    wget --limit-rate=$download -O %file %url
+
+...and it works well.. however, i notice the output is different, and
+that's because once we override that setting, git-annex doesn't add
+other magic settings it uses. so by turning that thing on and off and
+inspecting the process list, i was able to figure out that the command
+is actually:
+
+    wget -q --show-progress --clobber -c --limit-rate=$download -O %file %url
+
+that gets me closer to the command generated by git-annex. however, i
+am not sure the `--clobber` and `-c` flags should always be
+present. furthermore, the `--user-agent
+git-annex/5.20150610+gitg608172f-1~ndall+1` flag is missing.
+
+could there be an (optional) %useragent interpolation to fix that?
+
+what about the other settings, is it okay to hardcode those?
+
+maybe this would be easier if there would be an options override just
+like rsync, but separate ones for curl and wget... --[[anarcat]]