Recent changes to this wiki:

Added a comment: Bug still valid
diff --git a/doc/bugs/googlemail/comment_1_5614fa85029f9f97be03cb74899a7099._comment b/doc/bugs/googlemail/comment_1_5614fa85029f9f97be03cb74899a7099._comment
new file mode 100644
index 0000000..eb3c388
--- /dev/null
+++ b/doc/bugs/googlemail/comment_1_5614fa85029f9f97be03cb74899a7099._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawm8BAEUyzYhORZmMuocRTk4M-3IumDm5VU"
+ nickname="luciusf0"
+ subject="Bug still valid"
+ date="2014-07-31T08:35:29Z"
+ content="""
+The bug is still valid. A lot of german users had to use the @googlemail.com extension as google couldn't get the gmail domain in Germany. 
+So it might be bothering not just a few people, but a whole country! Now, if that doesn't count ...
+
+	Mac OSX 10.9.4
+	Version: 5.20140717-g5a7d4ff 
+	Build flags: Assistant Webapp Webapp-secure Pairing Testsuite S3 WebDAV FsEvents XMPP DNS Feeds Quvi TDFA CryptoHash
+
+This is the message I get
+
+	Unable to connect to the Jabber server. Maybe you entered the wrong password? (Error message: host xmpp.l.google.com.:5222 failed: AuthenticationFailure (Element {elementName = Name {nameLocalName = \"failure\", nameNamespace = Just \"urn:ietf:params:xml:ns:xmpp-sasl\", namePrefix = Nothing}, elementAttributes = [], elementNodes = [NodeElement (Element {elementName = Name {nameLocalName = \"not-authorized\", nameNamespace = Just \"urn:ietf:params:xml:ns:xmpp-sasl\", namePrefix = Nothing}, elementAttributes = [], elementNodes = []})]}); host alt2.xmpp.l.google.com.:5222 failed: AuthenticationFailure (Element {elementName = Name {nameLocalName = \"failure\", nameNamespace = Just \"urn:ietf:params:xml:ns:xmpp-sasl\", namePrefix = Nothing}, elementAttributes = [], elementNodes = [NodeElement (Element {elementName = Name {nameLocalName = \"not-authorized\", nameNamespace = Just \"urn:ietf:params:xml:ns:xmpp-sasl\", namePrefix = Nothing}, elementAttributes = [], elementNodes = []})]}); host alt1.xmpp.l.google.com.:5222 failed: AuthenticationFailure (Element {elementName = Name {nameLocalName = \"failure\", nameNamespace = Just \"urn:ietf:params:xml:ns:xmpp-sasl\", namePrefix = Nothing}, elementAttributes = [], elementNodes = [NodeElement (Element {elementName = Name {nameLocalName = \"not-authorized\", nameNamespace = Just \"urn:ietf:params:xml:ns:xmpp-sasl\", namePrefix = Nothing}, elementAttributes = [], elementNodes = []})]}); host alt4.xmpp.l.google.com.:5222 failed: AuthenticationFailure (Element {elementName = Name {nameLocalName = \"failure\", nameNamespace = Just \"urn:ietf:params:xml:ns:xmpp-sasl\", namePrefix = Nothing}, elementAttributes = [], elementNodes = [NodeElement (Element {elementName = Name {nameLocalName = \"not-authorized\", nameNamespace = Just \"urn:ietf:params:xml:ns:xmpp-sasl\", namePrefix = Nothing}, elementAttributes = [], elementNodes = []})]}); host alt3.xmpp.l.google.com.:5222 failed: AuthenticationFailure (Element {elementName = Name {nameLocalName = \"failure\", nameNamespace = Just \"urn:ietf:params:xml:ns:xmpp-sasl\", namePrefix = Nothing}, elementAttributes = [], elementNodes = [NodeElement (Element {elementName = Name {nameLocalName = \"not-authorized\", nameNamespace = Just \"urn:ietf:params:xml:ns:xmpp-sasl\", namePrefix = Nothing}, elementAttributes = [], elementNodes = []})]}))
+	
+
+"""]]

typo
diff --git a/doc/tips/metadata_driven_views.mdwn b/doc/tips/metadata_driven_views.mdwn
index 5128c18..1826ed1 100644
--- a/doc/tips/metadata_driven_views.mdwn
+++ b/doc/tips/metadata_driven_views.mdwn
@@ -6,7 +6,7 @@ keeps track of.
 
 One nice way to use the metadata is through **views**. You can ask
 git-annex to create a view of files in the currently checked out branch
-that have certian metadata. Once you're in a view, you can move and copy
+that have certain metadata. Once you're in a view, you can move and copy
 files to adjust their metadata further. Rather than the traditional
 hierarchical directory structure, views are dynamic; you can easily
 refine or reorder a view.

Added a comment
diff --git a/doc/forum/Central_git_annex_server_that_always_keeps_one_copy/comment_1_e786c8df6e48d88cf15b555af1b8639a._comment b/doc/forum/Central_git_annex_server_that_always_keeps_one_copy/comment_1_e786c8df6e48d88cf15b555af1b8639a._comment
new file mode 100644
index 0000000..19339a3
--- /dev/null
+++ b/doc/forum/Central_git_annex_server_that_always_keeps_one_copy/comment_1_e786c8df6e48d88cf15b555af1b8639a._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawn-TDneVW-8kwb1fyTRAJfH3l1xs2VSEmk"
+ nickname="James"
+ subject="comment 1"
+ date="2014-07-30T20:37:27Z"
+ content="""
+It might not suit all your needs but you could try using gitolite and set permissions on the git-annex branch of your repository
+http://gitolite.com/gitolite/conf.html#write-types
+
+"""]]

Added a comment
diff --git a/doc/bugs/runs_of_of_memory_adding_2_million_files/comment_8_7264b57f309d6e824c612eed8a088327._comment b/doc/bugs/runs_of_of_memory_adding_2_million_files/comment_8_7264b57f309d6e824c612eed8a088327._comment
new file mode 100644
index 0000000..c4d7721
--- /dev/null
+++ b/doc/bugs/runs_of_of_memory_adding_2_million_files/comment_8_7264b57f309d6e824c612eed8a088327._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmwjQzWgiD7_I3zw-_91rMRf_6qoThupis"
+ nickname="Mike"
+ subject="comment 8"
+ date="2014-07-30T20:33:44Z"
+ content="""
+Great work Joeyh :-) I will install the new version soon. I is fantastic that you fixed this so thoroughly.
+"""]]

Added a comment: interesting idea
diff --git a/doc/todo/Speed_up___39__import_--clean-duplicates__39__/comment_1_9268c639d3d21cce4ca7b60d08e9cb65._comment b/doc/todo/Speed_up___39__import_--clean-duplicates__39__/comment_1_9268c639d3d21cce4ca7b60d08e9cb65._comment
new file mode 100644
index 0000000..8584d5a
--- /dev/null
+++ b/doc/todo/Speed_up___39__import_--clean-duplicates__39__/comment_1_9268c639d3d21cce4ca7b60d08e9cb65._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="24.159.78.125"
+ subject="interesting idea"
+ date="2014-07-30T15:03:46Z"
+ content="""
+This could be done in constant space using a bloom filter of known file sizes. Files with wrong sizes would sometimes match, but no problem, it would then just do the work it does now.
+
+However, to build such a filter, git-annex would need to do a scan of all keys it knows about. This would take approximately as long to run as `git annex unused` does. It might make sense to only build the filter if it runs into a fairly large file. Alternatively, a bloom filter of file sizes could be cached and updated on the fly as things change (but this gets pretty complex).
+"""]]

Added a comment
diff --git a/doc/forum/local_subtree_and_broken_symlinks/comment_1_779cc4e49cb4da8aea7f5743e6257f21._comment b/doc/forum/local_subtree_and_broken_symlinks/comment_1_779cc4e49cb4da8aea7f5743e6257f21._comment
new file mode 100644
index 0000000..e6ccb81
--- /dev/null
+++ b/doc/forum/local_subtree_and_broken_symlinks/comment_1_779cc4e49cb4da8aea7f5743e6257f21._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="24.159.78.125"
+ subject="comment 1"
+ date="2014-07-30T14:55:16Z"
+ content="""
+Known bug: [[bugs/Git_annexed_files_symlink_are_wrong_when_submodule_is_not_in_the_same_path]]
+
+I don't think there's much likelyhood of a fix though. Using direct mode probably works around the problem. Or you can use something like myrepos instead of git subtrees.
+"""]]

mention possibility of parallel chunk upload/download
diff --git a/doc/design/assistant/chunks.mdwn b/doc/design/assistant/chunks.mdwn
index 52ddf07..48a1876 100644
--- a/doc/design/assistant/chunks.mdwn
+++ b/doc/design/assistant/chunks.mdwn
@@ -249,3 +249,14 @@ checking hasKey.
 Note that this is safe to do only as long as the Key being transferred
 cannot possibly have 2 different contents in different repos. Notably not
 necessarily the case for the URL keys generated for quvi.
+
+Both **done**.
+
+## parallel
+
+If 2 remotes both support chunking, uploading could upload different chunks
+to them in parallel. However, the chunk log does not currently allow
+representing the state where some chunks are on one remote and others on
+another remote.
+
+Parallel downloading of chunks from different remotes is a bit more doable.

devblog
diff --git a/doc/devblog/day_207__at_last.mdwn b/doc/devblog/day_207__at_last.mdwn
new file mode 100644
index 0000000..936ac98
--- /dev/null
+++ b/doc/devblog/day_207__at_last.mdwn
@@ -0,0 +1,34 @@
+It took 9 hours, but I finally got to make [[!commit c0dc134cded6078bb2e5fa2d4420b9cc09a292f7]],
+which both removes 35 lines of code, and adds chunking support to all
+external special remotes!
+
+The groundwork for that commit involved taking the type scheme I sketched
+out yesterday, completely failing to make it work with such high-ranked
+types, and falling back to a simpler set of types that both I and GHC seem
+better at getting our heads around.
+
+Then I also had more fun with types, when it turned out I needed to
+run encryption in the Annex monad. So I had to go convert several parts of
+the utility libraries to use MonadIO and exception lifting. Yurk.
+
+The final and most fun stumbling block caused git-annex to crash when
+retriving a file from an external special remote that had neither
+encryption not chunking. Amusingly it was because I had not put in an
+optimation (namely, just renaming the file that was retrieved in this case,
+rather than unnecessarily reading it in and writing it back out). It's
+not often that a lack of an optimisation causes code to crash!
+
+So, fun day, great result, and it should now be very simple to convert
+the bup, ddar, gcrypt, glacier, rsync, S3, and WebDAV special remotes
+to the new system. Fingers crossed.
+
+But first, I will probably take half a day or so and write a 
+`git annex testremote` that can be run in a repository and does live
+testing of a special remote including uploading and downloading files.
+There are quite a lot of cases to test now, and it seems best to get
+that in place before I start changing a lot of remotes without a way to
+test everything.
+
+----
+
+Today's work was sponsored by Daniel Callahan.

diff --git a/doc/forum/Central_git_annex_server_that_always_keeps_one_copy.mdwn b/doc/forum/Central_git_annex_server_that_always_keeps_one_copy.mdwn
new file mode 100644
index 0000000..166a22d
--- /dev/null
+++ b/doc/forum/Central_git_annex_server_that_always_keeps_one_copy.mdwn
@@ -0,0 +1 @@
+Is there a way to configure a central git repository that keeps track of large files with git annex so that multiple users can clone the repository but no repository clone can drop files from the server. Essentially, I'm looking for a way to have one repository that is always populated with at least one copy of each file. Other users shouldn't be able to tell that repository to drop any files (but would be able to add files it). The term "user" in that last sentence really refers to other clones...

diff --git a/doc/todo/Speed_up___39__import_--clean-duplicates__39__.mdwn b/doc/todo/Speed_up___39__import_--clean-duplicates__39__.mdwn
new file mode 100644
index 0000000..34c21ab
--- /dev/null
+++ b/doc/todo/Speed_up___39__import_--clean-duplicates__39__.mdwn
@@ -0,0 +1,7 @@
+I'm currently in the process of gutting old (some broken) git-annex's and cleaning out download directories from before I started using git-annex.
+
+To do this, I am running `git annex import --clean--duplicates $PATH` on the directories I want to clear out but sometimes, this takes a unnecessarily long time.
+
+For example, git-annex will calculate the digest for a huge file (30GB+) in $TARGET, even though there are no files in the annex of that size.
+
+It's a common shortcut to check for duplicate sizes first to eliminate definite non-matches really quickly. Can this be added to git-annex's `import` in some way or is this a no-go due to the constant memory constraint?

new wish: add repository name to commit messages
diff --git a/doc/todo/wishlist:_add_repository_name_to_commit_messages.mdwn b/doc/todo/wishlist:_add_repository_name_to_commit_messages.mdwn
new file mode 100644
index 0000000..1c37cc1
--- /dev/null
+++ b/doc/todo/wishlist:_add_repository_name_to_commit_messages.mdwn
@@ -0,0 +1,3 @@
+The commit messages made by git-annex are quite spartan, especially in direct mode where one cannot enter its own commit messages. This means that all that the messages say is "branch created", "git-annex automatic sync", "update", "merging" or little more.
+
+It would be nice if git-annex could add at least the name of the repository/remote to the commit message. This would make the log a lot more clear, especially when dealing with problems or bugs.

new bug: whereis does not work in direct mode
diff --git a/doc/bugs/whereis_does_not_work_in_direct_mode.mdwn b/doc/bugs/whereis_does_not_work_in_direct_mode.mdwn
new file mode 100644
index 0000000..1dbbbbb
--- /dev/null
+++ b/doc/bugs/whereis_does_not_work_in_direct_mode.mdwn
@@ -0,0 +1,84 @@
+### Please describe the problem.
+
+`git annex whereis` says that there are no copies of any of the files annexed in repositories running in direct mode.
+
+This is the error received:
+
+    $ git annex whereis
+    whereis fileA (0 copies) failed
+    whereis fileB (0 copies) failed
+    git-annex: whereis: 2 failed
+
+### What steps will reproduce the problem?
+
+The following script (available at <https://gist.github.com/gioele/dde462df89edfe17c5e3>) will reproduce this problem.
+
+[[!format sh """
+#!/bin/sh -x
+ 
+set -e ; set -u
+export LC_ALL=C
+ 
+direct=true # set to false to make the problem disappear
+ 
+h=${h:-localhost}
+dr="/tmp/annex"
+ 
+sync='sync -c annex.alwayscommit=true'
+ 
+chmod a+rwx -R pc1 pc2 || true
+rm -Rf pc1 pc2
+ 
+# create central git repo
+ssh $h "chmod a+rwx -R ${dr}/Docs.git" || true
+ssh $h "rm -Rf ${dr}/Docs.git"
+ssh $h "mkdir -p ${dr}/Docs.git"
+ssh $h "cd ${dr}/Docs.git ; git init --bare"
+ 
+d=$(pwd)
+ 
+# populate repo in PC1
+mkdir -p pc1/Docs
+cd pc1/Docs
+echo AAA > fileA
+echo BBB > fileB
+ 
+git init
+git remote add origin $h:$dr/Docs.git
+git fetch --all
+ 
+# simulate a host without git-annex
+git config remote.origin.annex-ignore true
+ 
+git annex init "pc1"
+git annex info
+ 
+$direct && git annex direct
+ 
+git annex add .
+git annex $sync origin
+ 
+# re-create repo on PC2
+cd $d
+mkdir -p pc2
+cd pc2
+git clone $h:$dr/Docs.git
+cd Docs
+ 
+git config remote.origin.annex-ignore true
+ 
+git annex init "pc2"
+git annex info
+ 
+git annex whereis || true
+echo "I was expecting location info to be available after info (press Enter)" ; read enter
+ 
+git annex $sync origin
+ 
+git annex whereis || true
+echo "Why isn't location info available even after sync? (press Enter)"
+"""]]
+
+### What version of git-annex are you using? On what operating system?
+
+git-annex version: 5.20140708-g42df533

Added a comment
diff --git a/doc/bugs/sync_does_not_commit_with_alwasycommit___61___false/comment_1_e6dc7fa1b0a131bb7533f8407e1b5510._comment b/doc/bugs/sync_does_not_commit_with_alwasycommit___61___false/comment_1_e6dc7fa1b0a131bb7533f8407e1b5510._comment
new file mode 100644
index 0000000..ee99576
--- /dev/null
+++ b/doc/bugs/sync_does_not_commit_with_alwasycommit___61___false/comment_1_e6dc7fa1b0a131bb7533f8407e1b5510._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://svario.it/gioele"
+ nickname="gioele"
+ subject="comment 1"
+ date="2014-07-29T14:25:19Z"
+ content="""
+For the records, the solution Joey suggested works but the correct option to pass to `sync` is `-c annex.alwayscommit=true`.
+"""]]

i hope this is not too silly
diff --git a/doc/forum/usability:_what_are_those_arrow_things__63__.mdwn b/doc/forum/usability:_what_are_those_arrow_things__63__.mdwn
new file mode 100644
index 0000000..ac83430
--- /dev/null
+++ b/doc/forum/usability:_what_are_those_arrow_things__63__.mdwn
@@ -0,0 +1,21 @@
+i want to relate a usability story that happens fairly regularly when I show git-annex to people. the story goes like this.
+
+----
+
+Antoine sat down at his computer saying, "i have this great movie collection I want to share with you, my friend, because the fair use provisions allow for that, and I use this great git-annex tool that allows me to sync my movie collection between different places". His friend Charlie, a Linux user only vaguely familiar with the internals of how his operating system or legal system actually works, reads this as "yay free movies" and wholeheartedly agrees to lend himself to the experiment.
+
+Antoine creates a user account for Charlie on his home computer, because he doesn't want to have to do everything himself. "That way you can choose which movies you want, because you probably don't want my complete movie collection!" Charlie emphatically responds: "right, I only have my laptop and this USB key here, so I don't think I can get it all".
+
+Charlie logs into Antoine's computer, named `marcos`. Antoine shows Charlie where the movies are located (`/srv/video`) through the file browser (Thunar, for the record). Charlie inserts his USB key into `marcos` and a new icon for the USB key shows up. Then Charlie finds a video he likes, copies and pastes it into the USB key. But instead of a familiar progress bar, Charlie is prompted with a dialog that says "Le système de fichiers ne gère pas les liens symboliques." (Antoine is french, so excuse him, this weird message says that the filesystem doesn't support symbolic links.) Puzzled, Charlie tries to copy the file to his home directory instead. This works better, but the file has a little arrow on it, which seems odd to Charlie. He then asks Antoine for advice.
+
+Antoine then has no solution but to convert the git-annex repository into direct mode, something which takes a significant amount of time and is actually [[designated as "untrusted"|direct_mode]] in the documentation. In fact, so much so that he actually did [[screw up his repository magnificently|bugs/direct_command_leaves_repository_inconsistent_if_interrupted]] because he freaked out when `git-annex direct` started and interrupted it because he tought it would take too long.
+
+----
+
+Now I understand it is not necessarily `git-annex`'s responsability if Thunar (or Nautilus, for that matter), doesn't know how to properly deal with symlinks (hint: just dereference the damn thing already). Maybe I should file a bug about this against thunar? I also understand that symlinks are useful to ensure the security of the data hosted in `git-annex`, and that I could have used direct mode in the first place. But I like to track changes in git to those files, and direct mode makes that really difficult.
+
+I didn't file this as a bug because I want to start the conversation, but maybe it should qualify as a usability bug. As things stand, this is one of the biggest hurdle in teaching people about git annex.
+
+(The other being "how do i actually use git annex to sync those files instead of just copying them by hand", but that's for another story!)
+
+-- [[anarcat]]

found some files in misctmp
diff --git a/doc/bugs/direct_command_leaves_repository_inconsistent_if_interrupted.mdwn b/doc/bugs/direct_command_leaves_repository_inconsistent_if_interrupted.mdwn
index 222e97f..0d81c67 100644
--- a/doc/bugs/direct_command_leaves_repository_inconsistent_if_interrupted.mdwn
+++ b/doc/bugs/direct_command_leaves_repository_inconsistent_if_interrupted.mdwn
@@ -33,7 +33,7 @@ fsck films/God Hates Cartoons/VIDEO_TS/VTS_15_0.BUP (fixing location log)
   Back it up with git-annex copy.
 """]]
 
-Yet the files are present in .git/annex/objects...
+Oddly enough, the repo still uses hundreds of gigs, because all the files ended up in `.git/annex/misctmp`. Not sure I remember what happened there.
 
 Similar issues and discussions:
 

diff --git a/doc/bugs/direct_command_leaves_repository_inconsistent_if_interrupted.mdwn b/doc/bugs/direct_command_leaves_repository_inconsistent_if_interrupted.mdwn
index b139771..222e97f 100644
--- a/doc/bugs/direct_command_leaves_repository_inconsistent_if_interrupted.mdwn
+++ b/doc/bugs/direct_command_leaves_repository_inconsistent_if_interrupted.mdwn
@@ -4,7 +4,7 @@ When `git annex direct` is interrupted (either through a power outage or deliber
 
 A typical situation is `git-annex` believing that the repo is in `indirect` mode while the files are not symlinks anymore.
 
-I believe I have described this problem here before, but the bug report was deleted as part of the may 29th purge (222f78e9eadd3d2cc40ec94ab22241823a7d50d9), file `doc/bugs/git_annex_indirect_can_fail_catastrophically.mdwn`.
+I believe I have described this problem here before, but the bug report was deleted as part of the may 29th purge (222f78e9eadd3d2cc40ec94ab22241823a7d50d9,  [[bugs/git_annex_indirect_can_fail_catastrophically]]).
 
 ### What steps will reproduce the problem?
 
@@ -14,7 +14,7 @@ Observe how a lot of files are now considered to be in the famous [[typechange s
 
 ### What version of git-annex are you using? On what operating system?
 
-5.20140717 on Debian Jessie.
+5.20140717 on Debian Jessie, ext4 filesystem.
 
 ### Please provide any additional information below.
 
@@ -34,3 +34,10 @@ fsck films/God Hates Cartoons/VIDEO_TS/VTS_15_0.BUP (fixing location log)
 """]]
 
 Yet the files are present in .git/annex/objects...
+
+Similar issues and discussions:
+
+* [[bugs/direct_mode_merge_interrupt/]]
+* [[forum/Cleaning_up_after_aborted_sync_in_direct_mode/]]
+* [[bugs/failure_to_return_to_indirect_mode_on_usb/]]
+* [[forum/git-status_typechange_in_direct_mode/]]

diff --git a/doc/bugs/direct_command_leaves_repository_inconsistent_if_interrupted.mdwn b/doc/bugs/direct_command_leaves_repository_inconsistent_if_interrupted.mdwn
index c526eaa..b139771 100644
--- a/doc/bugs/direct_command_leaves_repository_inconsistent_if_interrupted.mdwn
+++ b/doc/bugs/direct_command_leaves_repository_inconsistent_if_interrupted.mdwn
@@ -21,3 +21,16 @@ Observe how a lot of files are now considered to be in the famous [[typechange s
 I wish i could resume the `git annex direct` command, but this will do a `git commit -a` and therefore commit all those files to git directly. It still seems to me that `git annex` should never run `git commit -a` for exactly that kind of situations.
 
 I think that's it for now. -- [[anarcat]]
+
+Update: i was able to get rid of the `typechange` situation by running `git annex lock` on the repository, but then all files are found to be missing by `git annex fsck`:
+
+[[!format txt """
+fsck films/God Hates Cartoons/VIDEO_TS/VTS_15_0.BUP (fixing location log)
+  ** Based on the location log, films/God Hates Cartoons/VIDEO_TS/VTS_15_0.BUP
+  ** was expected to be present, but its content is missing.
+
+  Only 1 of 2 trustworthy copies exist of films/God Hates Cartoons/VIDEO_TS/VTS_15_0.BUP
+  Back it up with git-annex copy.
+"""]]
+
+Yet the files are present in .git/annex/objects...

back from the dead, or not
diff --git a/doc/bugs/direct_command_leaves_repository_inconsistent_if_interrupted.mdwn b/doc/bugs/direct_command_leaves_repository_inconsistent_if_interrupted.mdwn
new file mode 100644
index 0000000..c526eaa
--- /dev/null
+++ b/doc/bugs/direct_command_leaves_repository_inconsistent_if_interrupted.mdwn
@@ -0,0 +1,23 @@
+### Please describe the problem.
+
+When `git annex direct` is interrupted (either through a power outage or deliberate `control-c`) it may leave the repository in an inconsistent state.
+
+A typical situation is `git-annex` believing that the repo is in `indirect` mode while the files are not symlinks anymore.
+
+I believe I have described this problem here before, but the bug report was deleted as part of the may 29th purge (222f78e9eadd3d2cc40ec94ab22241823a7d50d9), file `doc/bugs/git_annex_indirect_can_fail_catastrophically.mdwn`.
+
+### What steps will reproduce the problem?
+
+`git annex direct` on a large repository, `control-c` before it finishes.
+
+Observe how a lot of files are now considered to be in the famous [[typechange status|forum/git-status_typechange_in_direct_mode/]] in git.
+
+### What version of git-annex are you using? On what operating system?
+
+5.20140717 on Debian Jessie.
+
+### Please provide any additional information below.
+
+I wish i could resume the `git annex direct` command, but this will do a `git commit -a` and therefore commit all those files to git directly. It still seems to me that `git annex` should never run `git commit -a` for exactly that kind of situations.
+
+I think that's it for now. -- [[anarcat]]

devbog
diff --git a/doc/devblog/day_206__zap.mdwn b/doc/devblog/day_206__zap.mdwn
new file mode 100644
index 0000000..eccee24
--- /dev/null
+++ b/doc/devblog/day_206__zap.mdwn
@@ -0,0 +1,83 @@
+Zap! ... My internet gateway was [destroyed by lightning](https://identi.ca/joeyh/note/xogvXTFDR9CZaCPsmKZipA).
+Limping along regardless, and replacement ordered.
+
+Got resuming of uploads to chunked remotes working. Easy!
+
+----
+
+Next I want to convert the external special remotes to have these nice
+new features. But there is a wrinkle: The new chunking interface works
+entirely on ByteStrings containing the content, but the external special
+remote interface passes content around in files.
+
+I could just make it write the ByteString to a temp file, and pass the temp
+file to the external special remote to store. But then, when chunking is
+not being used, it would pointlessly read a file's content, only to write
+it back out to a temp file.
+
+Similarly, when retrieving a key, the external special remote saves it to a
+file. But we want a ByteString. Except, when not doing chunking or
+encryption, letting the external special remote save the content directly
+to a file is optimal.
+
+One approach would be to change the protocol for external special
+remotes, so that the content is sent over the protocol rather than in temp
+files. But I think this would not be ideal for some kinds of external
+special remotes, and it would probably be quite a lot slower and more
+complicated.
+
+Instead, I am playing around with some type class trickery:
+
+[[!format haskell """
+{-# LANGUAGE Rank2Types TypeSynonymInstances FlexibleInstances MultiParamTypeClasses #-}
+
+type Storer p = Key -> p -> MeterUpdate -> IO Bool
+
+-- For Storers that want to be provided with a file to store.
+type FileStorer a = Storer (ContentPipe a FilePath)
+
+-- For Storers that want to be provided with a ByteString to store
+type ByteStringStorer a = Storer (ContentPipe a L.ByteString)
+
+class ContentPipe src dest where
+        contentPipe :: src -> (dest -> IO a) -> IO a
+
+instance ContentPipe L.ByteString L.ByteString where
+        contentPipe b a = a b
+
+-- This feels a lot like I could perhaps use pipes or conduit...
+instance ContentPipe FilePath FilePath where
+        contentPipe f a = a f
+
+instance ContentPipe L.ByteString FilePath where
+        contentPipe b a = withTmpFile "tmpXXXXXX" $ \f h -> do
+                L.hPut h b
+                hClose h
+                a f
+
+instance ContentPipe FilePath L.ByteString where
+        contentPipe f a = a =<< L.readFile f
+"""]]
+
+The external special remote would be a FileStorer, so when a non-chunked,
+non-encrypted file is provided, it just runs on the FilePath with no extra
+work. While when a ByteString is provided, it's swapped out to a temp file
+and the temp file provided. And many other special remotes are ByteStorers,
+so they will just pass the provided ByteStream through, or read in the
+content of a file.
+
+I think that would work. Thoigh it is not optimal for external special
+remotes that are chunked but not encrypted. For that case, it might be worth
+extending the special remote protocol with a way to say "store a chunk of
+this file from byte N to byte M".
+
+---
+
+Also, talked with ion about what would be involved in using rolling checksum
+based chunks. That would allow for rsync or zsync like behavior, where
+when a file changed, git-annex uploads only the chunks that changed, and the
+unchanged chunks are reused.
+
+I am not ready to work on that yet, but I made some changes to the parsing
+of the chunk log, so that additional chunking schemes like this can be added
+to git-annex later without breaking backwards compatability.

expand to rolling hash based design
diff --git a/doc/design/assistant/deltas.mdwn b/doc/design/assistant/deltas.mdwn
index ff4185a..0f7d308 100644
--- a/doc/design/assistant/deltas.mdwn
+++ b/doc/design/assistant/deltas.mdwn
@@ -4,6 +4,24 @@ One simple way is to find the key of the old version of a file that's
 being transferred, so it can be used as the basis for rsync, or any
 other similar transfer protocol.
 
-For remotes that don't use rsync, a poor man's version could be had by
-chunking each object into multiple parts. Only modified parts need be
-transferred. Sort of sub-keys to the main key being stored.
+For remotes that don't use rsync, use a rolling checksum based chunker,
+such as BuzHash. This will produce [[chunks]], which can be stored on the
+remote as regular Keys -- where unlike the fixed size chunk keys, the
+SHA256 part of these keys is the checksum of the chunk they contain.
+
+Once that's done, it's easy to avoid uploading chunks that have been sent
+to the remote before.
+
+When retriving a new version of a file, there would need to be a way to get
+the list of chunk keys that constitute the new version. Probably best to
+store this list on the remote. Then there needs to be a way to find which
+of those chunks are available in locally present files, so that the locally
+available chunks can be extracted, and combined with the chunks that need
+to be downloaded, to reconstitute the file.
+
+To find which chucks are locally available, here are 2 ideas:
+
+1. Use a single basis file, eg an old version of the file. Re-chunk it, and
+   use its chunks.  Slow, but simple.
+2. Some kind of database of locally available chunks. Would need to be kept
+   up-to-date as files are added, and as files are downloaded.

Added a comment: One snag
diff --git a/doc/forum/remote_server_client_repositories_are_bare__33____63__/comment_3_32bf10cf837db16566dcc99d0b9aaf67._comment b/doc/forum/remote_server_client_repositories_are_bare__33____63__/comment_3_32bf10cf837db16566dcc99d0b9aaf67._comment
new file mode 100644
index 0000000..bf302f7
--- /dev/null
+++ b/doc/forum/remote_server_client_repositories_are_bare__33____63__/comment_3_32bf10cf837db16566dcc99d0b9aaf67._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkftzaCvV7EDKVDfJhsQZ3E1Vn-0db516w"
+ nickname="Edward"
+ subject="One snag"
+ date="2014-07-28T19:37:04Z"
+ content="""
+I setup a non-bare repo on a server by following the above steps (git init, git annex init, then add it as a Remote Server from elsewhere and combine repos). It worked, but I hit a snag and needed to add another step.
+
+After git init, you're not sitting on any branch yet, and that seems to have prevented the assistant from doing anything to synchronize the working tree on the server. After I did \"git checkout synced/master\", it started working.
+"""]]

diff --git a/doc/bugs/Permission_problem_in_second_user_account_on_Android.mdwn b/doc/bugs/Permission_problem_in_second_user_account_on_Android.mdwn
new file mode 100644
index 0000000..8b73082
--- /dev/null
+++ b/doc/bugs/Permission_problem_in_second_user_account_on_Android.mdwn
@@ -0,0 +1,15 @@
+I get the following error message upon starting git-annex in a second user account on Android:
+
+    Falling back to hardcoded app location: cannot find expected files in /data/app-lib
+    git annex webapp
+    lib/lib.runshell.so: line 133: git: Permission denied
+
+    [Terminal session finished]
+
+The same version of git-annex works just fine for the primary user.
+(The primary user has root access which unfortunately can't be enabled for other user accounts.)
+
+### What version of git-annex are you using? On what operating system?
+
+  * git-annex: 5.20140710
+  * OS: CyanogenMod 10.1.3-p3110

chunk log format should be extensible to allow for eg, logging when rolling hash chunks are used
diff --git a/doc/design/assistant/chunks.mdwn b/doc/design/assistant/chunks.mdwn
index 51fd721..52ddf07 100644
--- a/doc/design/assistant/chunks.mdwn
+++ b/doc/design/assistant/chunks.mdwn
@@ -160,17 +160,11 @@ Instead of storing the chunk count in the special remote, store it in
 the git-annex branch. 
 
 The location log does not record locations of individual chunk keys
-(too space-inneficient).
-Instead, look at git-annex:aaa/bbb/SHA256-s12345--xxxxxxx.log.cnk to get
-the chunk count and size for a key.
+(too space-inneficient). Instead, look at a chunk log in the
+git-annex branch to get the chunk count and size for a key.
 
-Note that a given remote uuid might have multiple chunk sizes logged, if a
-key was stored on it twice using different chunk sizes. Also note that even
-when this file exists for a key, the object may be stored non-chunked on
-the remote too.
-
-`hasKey` would check if any one (chunksize, chunkcount) is satisfied by
-the files on the remote. It would also check if the non-chunked key is
+`hasKey` would check if any of the logged sets of chunks is 
+present on the remote. It would also check if the non-chunked key is
 present, as a fallback.
 
 When dropping a key from the remote, drop all logged chunk sizes.
@@ -185,6 +179,31 @@ remote doesn't know anything about chunk sizes. It uses a little more
 data in the git-annex branch, although with care (using the same timestamp
 as the location log), it can compress pretty well.
 
+## chunk log
+
+Stored in the git-annex branch, this provides a mapping `Key -> [[Key]]`.
+
+Note that a given remote uuid might have multiple sets of chunks (with
+different sizes) logged, if a key was stored on it twice using different
+chunk sizes. Also note that even when the log indicates a key is chunked,
+the object may be stored non-chunked on the remote too.
+
+For fixed size chunks, there's no need to store the list of chunk keys,
+instead the log only records the number of chunks (needed because the size
+of the parent Key may not be known), and the chunk size.
+
+Example:
+
+	1287290776.765152s e605dca6-446a-11e0-8b2a-002170d25c55:10240 9
+
+Later, might want to support other kinds of chunks, for example ones made
+using a rsync-style rolling checksum. It would probably not make sense to
+store the full [Key] list for such chunks in the log. Instead, it might be
+stored in a file on the remote.
+
+To support such future developments, when updating the chunk log, 
+git-annex should preserve unparsable values (the part after the colon).
+
 ## chunk then encrypt
 
 Rather than encrypting the whole object 1st and then chunking, chunk and

diff --git a/doc/bugs/present_files__47__directories_are_dropped_after_a_sync.mdwn b/doc/bugs/present_files__47__directories_are_dropped_after_a_sync.mdwn
index cff4300..432ab90 100644
--- a/doc/bugs/present_files__47__directories_are_dropped_after_a_sync.mdwn
+++ b/doc/bugs/present_files__47__directories_are_dropped_after_a_sync.mdwn
@@ -1,6 +1,6 @@
 ### Please describe the problem.
 
-This is a followup from the discussion on https://git-annex.branchable.com/forum/Standard_groups__47__preferred_contents/ where I unfortunately got complete answer.
+This is a followup from the discussion on https://git-annex.branchable.com/forum/Standard_groups__47__preferred_contents/ where I unfortunately did not get a complete answer.
 I don't know if it is really a bug but at least it does not work as I would expect and the documentation provides no clear discussion on that.
 
 Now to the problem:

diff --git a/doc/bugs/present_files__47__directories_are_dropped_after_a_sync.mdwn b/doc/bugs/present_files__47__directories_are_dropped_after_a_sync.mdwn
new file mode 100644
index 0000000..cff4300
--- /dev/null
+++ b/doc/bugs/present_files__47__directories_are_dropped_after_a_sync.mdwn
@@ -0,0 +1,38 @@
+### Please describe the problem.
+
+This is a followup from the discussion on https://git-annex.branchable.com/forum/Standard_groups__47__preferred_contents/ where I unfortunately got complete answer.
+I don't know if it is really a bug but at least it does not work as I would expect and the documentation provides no clear discussion on that.
+
+Now to the problem:
+My annex is in "manual" mode (or equivalently "exclude="*" and present" or an expression which contains "present".
+Then I get a file using "git annex get file".
+I would expect that this file is now synced because it is "present".
+But it is not. When I change the file it is synced to the remotes. This is what it should be.
+However, when a remote changes that file, the content is NOT synced, the file is silently dropped.
+
+Similarly, when I get a complete directory tree in manual mode, I would expect that it is synced. That means, when a remote adds a file or changes a file in that directory, it is also synced to the local machine. But it is not. If it is changed, it is silently dropped (as written above). If a file is added, only the metadata is added but the content is not synced.
+
+### What steps will reproduce the problem?
+
+ - Create a file 'file' on the server, git annex add/sync etc.
+ - On the client: git annex wanted here 'exclude="*" and present'
+ - On the client: git annex get file . The file is now present on the client
+ - Change the file on the server, git annex sync
+ - git annex sync --content on the client
+ - Result: File is dropped again on client
+
+Similarly for directories:
+
+ - Create a (sub-)directory 'subdir' with files and sync everything
+ - On the client: git annex get subdir . The subdirectory is now present, all files under it downloaded.
+ - On the server create a new file in 'subdir' and git annex add; git annex sync --content
+ - git annex sync --content on the client
+ - Result: Content of the files is not synced to client
+
+### What version of git-annex are you using? On what operating system?
+
+    git-annex version: 5.20140717-g5a7d4ff
+    build flags: Assistant Webapp Webapp-secure Pairing Testsuite S3 WebDAV 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 webdav tahoe glacier ddar hook external
+

devblog
diff --git a/doc/devblog/day_205__incremental.mdwn b/doc/devblog/day_205__incremental.mdwn
new file mode 100644
index 0000000..c8535d4
--- /dev/null
+++ b/doc/devblog/day_205__incremental.mdwn
@@ -0,0 +1,21 @@
+Last night, went over the new chunking interface, tightened up exception
+handling, and improved the API so that things like WebDAV will be able to
+reuse a single connection while all of a key's chunks are being downloaded.
+I am pretty happy with the interface now, and except to convert more
+special remotes to use it soon.
+
+Just finished adding a killer feature: Automatic resuming of interrupted
+downloads from chunked remotes. Sort of a poor man's rsync, that while less
+efficient and awesome, is going to work on *every* remote that gets the new
+chunking interface, from S3 to WebDAV, to all of Tobias's external special
+remotes! Even allows for things like starting a download
+from one remote, interrupting, and resuming from another one, and so on.
+
+I had forgotten about resuming while designing the chunking API. Luckily, I
+got the design right anyway. Implementation was almost trivial, and only
+took about 2 hours! (See [[!commit 9d4a766cd7b8e8b0fc7cd27b08249e4161b5380a]])
+
+I'll later add resuming of interrupted uploads. It's not hard to detect
+such uploads with only one extra query of the remote, but in principle,
+it should be possible to do it with no extra overhead, since git-annex
+already checks if all the chunks are there before starting an upload.

update
diff --git a/doc/design/assistant/chunks.mdwn b/doc/design/assistant/chunks.mdwn
index d751724..51fd721 100644
--- a/doc/design/assistant/chunks.mdwn
+++ b/doc/design/assistant/chunks.mdwn
@@ -6,15 +6,17 @@ May be a useful starting point for [[deltas]].
 May also allow for downloading different chunks of a file concurrently from
 multiple remotes.
 
-# currently
+Also, can allow resuming of interrupted uploads and downloads.
 
-Currently, only the webdav and directory special remotes support chunking.
+# legacy chunking
+
+Supported by only the webdav and directory special remotes.
 
 Filenames are used for the chunks that make it easy to see which chunks
 belong together, even when encryption is used. There is also a chunkcount
 file, that similarly leaks information.
 
-It is not currently possible to enable chunking on a non-chunked remote.
+It is not possible to enable chunking on a non-chunked remote.
 
 Problem: Two uploads of the same key from repos with different chunk sizes
 could lead to data loss. For example, suppose A is 10 mb chunksize, and B
@@ -39,9 +41,9 @@ on in the webapp when configuring an existing remote).
 Two concurrent uploaders of the same object to a remote should be safe,
 even if they're using different chunk sizes.
 
-The old chunk method needs to be supported for back-compat, so
-keep the chunksize= setting to enable that mode, and add a new setting
-for the new mode.
+The legacy chunk method needs to be supported for back-compat, so
+keep the chunksize= setting to enable that mode, and add a new chunk=
+setting for the new mode.
 
 # obscuring file sizes
 
@@ -209,3 +211,22 @@ cannot check exact file sizes.
 
 If padding is enabled, gpg compression should be disabled, to not leak
 clues about how well the files compress and so what kind of file it is.
+
+## resuming interupted transfers
+
+Resuming interrupted downloads, and uploads are both possible.
+
+Downloads: If the tmp file for a key exists, round it to the chunk size,
+and skip forward to the next needed chunk. Easy.
+
+Uploads: Check if the 1st chunk is present. If so, check the second chunk,
+etc. Once the first missing chunk is found, start uploading from there.
+
+That adds one extra hasKey call per upload. Probably a win in most cases.
+Can be improved by making special remotes open a persistent
+connection that is used for transferring all chunks, as well as for
+checking hasKey.
+
+Note that this is safe to do only as long as the Key being transferred
+cannot possibly have 2 different contents in different repos. Notably not
+necessarily the case for the URL keys generated for quvi.

devblog
diff --git a/doc/devblog/day_204__mowing.mdwn b/doc/devblog/day_204__mowing.mdwn
new file mode 100644
index 0000000..b34f1ba
--- /dev/null
+++ b/doc/devblog/day_204__mowing.mdwn
@@ -0,0 +1,64 @@
+Remained frustratingly stuck until 3 pm on the same stuff that puzzled
+me yesterday. However, 6 hours later, I have the directory
+special remote 100% working with both new chunk= and legacy chunksize=
+configuration, both with and without encryption.
+
+----
+
+So, the root of why this is was hard, since I thought about it a lot today
+in between beating my head into the wall: git-annex's internal API for remotes
+is really, really simple. It basically comes down to:
+
+[[!format haskell """
+	Remote
+		{ storeKey :: Key -> AssociatedFile -> MeterUpdate -> Annex Bool
+		, retrieveKeyFile :: Key -> AssociatedFile -> FilePath -> MeterUpdate -> Annex Bool
+		, removeKey :: Key -> Annex Bool
+		, hasKey :: Key -> Annex (Either String Bool)
+		}
+"""]]
+
+This simplicity is a Good Thing, because it maps very well to REST-type
+services. And it allows for quite a lot of variety in implementations of
+remotes. Ranging from reguar git remotes, that rsync files around without
+git-annex ever loading them itself, to remotes like webdav that load
+and store files themselves, to remotes like tahoe that intentionally do not
+support git-annex's built-in encryption methods.
+
+However, the simplicity of that API means that lots of complicated stuff,
+like handling chunking, encryption, etc, has to be handled on a per-remote
+basis. Or, more generally, by `Remote -> Remote` transformers that take
+a remote and add some useful feature to it.
+
+One problem is that the API is so simple that a remote transformer that adds
+encryption is not feasible. In fact, every encryptable remote has
+had its own code that loads a file from local disk, encrypts it, and sends
+it to the remote. Because there's no way to make a remote transformer that
+converts a `storeKey` into an encrypted `storeKey`. (Ditto for retrieving
+keys.)
+
+I almost made the API more complicated today. Twice. But both times
+I ended up not, and I think that was the right choice, even though
+it meant I had to write some quite painful code.
+
+----
+
+In the end, I instead wrote a little module that pulls together supporting
+both encryption and chunking. I'm not completely happy because those
+two things should be independent, and so separate. But, 120 lines of
+code that don't keep them separate is not the end of the world.
+
+That module also contains some more powerful, less general APIs, 
+that will work well with the kinds of remotes that will use it.
+
+The really nice result, is that the implementation of the directory
+special remote melts down from 267 lines of code to just 172! (Plus some
+legacy code for the old style chunking, refactored out into a file I can
+delete one day.) It's a lot cleaner too.
+
+With all this done, I expect I can pretty easily add the new style chunking
+to most git-annex remotes, and remove code from them while doing it!
+
+----
+
+Today's work was sponsored by Mark Hepburn.

added output of ls -lb in git directory to show that the file is not added to the annex
diff --git a/doc/bugs/git_annex_import_fails_on_filenames_with_newlines_in_them.mdwn b/doc/bugs/git_annex_import_fails_on_filenames_with_newlines_in_them.mdwn
index 3b86198..8727d3d 100644
--- a/doc/bugs/git_annex_import_fails_on_filenames_with_newlines_in_them.mdwn
+++ b/doc/bugs/git_annex_import_fails_on_filenames_with_newlines_in_them.mdwn
@@ -18,6 +18,9 @@ drwxr-xr-x 3 bram bram 4096 Jul 26 18:20 annex/
 bram@durian% git annex import ../foo$'\n'bar
 import foo
 bar git-annex: unknown response from git cat-file ("HEAD:./foo missing","HEAD:./foo\nbar")
+bram@durian% ls -lb
+total 4
+-r--r--r-- 2 bram bram 4 Jul 26 18:20 foo\nbar
 bram@durian% git status
 On branch master
 

diff --git a/doc/bugs/git_annex_import_fails_on_filenames_with_newlines_in_them.mdwn b/doc/bugs/git_annex_import_fails_on_filenames_with_newlines_in_them.mdwn
new file mode 100644
index 0000000..3b86198
--- /dev/null
+++ b/doc/bugs/git_annex_import_fails_on_filenames_with_newlines_in_them.mdwn
@@ -0,0 +1,41 @@
+### Please describe the problem.
+I am importing a lot of old documents into my annex.  Some of these old files apparently have newlines in their filename.  A run of `git annex import` aborts when it encounters such a file; the file is moved to the annex, but it is left unstaged.
+
+### What steps will reproduce the problem?
+[[!format sh """
+bram@durian% mkdir annex
+bram@durian% cd annex
+bram@durian% git init
+Initialized empty Git repository in /home/bram/tmp/t/annex/.git/
+bram@durian% git annex init
+init  ok
+(Recording state in git...)
+bram@durian% echo foo > ../$'foo\nbar'
+bram@durian% ls -lb ..
+total 8
+drwxr-xr-x 3 bram bram 4096 Jul 26 18:20 annex/
+-rw-r--r-- 1 bram bram    4 Jul 26 18:20 foo\nbar
+bram@durian% git annex import ../foo$'\n'bar
+import foo
+bar git-annex: unknown response from git cat-file ("HEAD:./foo missing","HEAD:./foo\nbar")
+bram@durian% git status
+On branch master
+
+Initial commit
+
+Untracked files:
+  (use "git add <file>..." to include in what will be committed)
+
+	"foo\nbar"
+
+nothing added to commit but untracked files present (use "git add" to track)
+bram@durian% cat $'foo\nbar'
+foo
+"""]]
+
+
+### What version of git-annex are you using? On what operating system?
+    Debian unstable
+    git-annex version: 5.20140717
+    git version 2.0.1
+    Linux durian 3.14-1-amd64 #1 SMP Debian 3.14.9-1 (2014-06-30) x86_64 GNU/Linux

Added a comment
diff --git a/doc/bugs/Assistant_merge_loop/comment_13_c88d26bc73eefa628037f88efb108368._comment b/doc/bugs/Assistant_merge_loop/comment_13_c88d26bc73eefa628037f88efb108368._comment
new file mode 100644
index 0000000..c6cc340
--- /dev/null
+++ b/doc/bugs/Assistant_merge_loop/comment_13_c88d26bc73eefa628037f88efb108368._comment
@@ -0,0 +1,234 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawk9nck8WX8-ADF3Fdh5vFo4Qrw1I_bJcR8"
+ nickname="Jon Ander"
+ subject="comment 13"
+ date="2014-07-26T14:57:53Z"
+ content="""
+The empty merge commits are a lot less common lately, but still happen.
+
+I post a log of today's merges. I have empty merge commit at 11:44:02, 11:44:03 and 11:54:34.
+
+
+[2014-07-26 11:41:35 CEST] main: starting assistant version 5.20140717
+[2014-07-26 11:41:36 CEST] read: git [\"--git-dir=/home/jonan/Sync/.git\",\"--work-tree=/home/jonan/Sync\",\"-c\",\"core.bare=false\",\"show-ref\",\"git-annex\"]
+[2014-07-26 11:41:36 CEST] read: git [\"--git-dir=/home/jonan/Sync/.git\",\"--work-tree=/home/jonan/Sync\",\"-c\",\"core.bare=false\",\"show-ref\",\"--hash\",\"refs/heads/git-annex\"]
+[2014-07-26 11:41:36 CEST] read: git [\"--git-dir=/home/jonan/Sync/.git\",\"--work-tree=/home/jonan/Sync\",\"-c\",\"core.bare=false\",\"log\",\"refs/heads/git-annex..c0620bd57bd1230fe9282b582bf65cd8ef39f59b\",\"-n1\",\"--pretty=%H\"]
+[2014-07-26 11:41:36 CEST] chat: git [\"--git-dir=/home/jonan/Sync/.git\",\"--work-tree=/home/jonan/Sync\",\"-c\",\"core.bare=false\",\"cat-file\",\"--batch\"]
+[2014-07-26 11:41:36 CEST] Cronner: You should enable consistency checking to protect your data. 
+[2014-07-26 11:43:46 CEST] read: git [\"--git-dir=/home/jonan/Sync/.git\",\"--work-tree=/home/jonan/Sync\",\"-c\",\"core.bare=false\",\"ls-files\",\"--stage\",\"-z\",\"--\",\"/home/jonan/Sync\"]
+[2014-07-26 11:43:49 CEST] read: git [\"--git-dir=/home/jonan/Sync/.git\",\"--work-tree=/home/jonan/Sync\",\"-c\",\"core.bare=false\",\"ls-files\",\"--stage\",\"-z\",\"--\",\"/home/jonan/Sync\"]
+[2014-07-26 11:43:56 CEST] chat: nice [\"ionice\",\"-c3\",\"git-annex\",\"remotedaemon\"]
+[2014-07-26 11:43:56 CEST] read: git [\"config\",\"--null\",\"--list\"]
+[2014-07-26 11:43:56 CEST] chat: ssh [\"-S\",\".git/annex/ssh/cdb5368d318ce8939cedf7b343eb95a9\",\"-o\",\"ControlMaster=auto\",\"-o\",\"ControlPersist=yes\",\"-T\",\"admin@ec2-54-86-238-253.compute-1.amazonaws.com\",\"git-annex-shell 'notifychanges' '/~/annex-sync/' --uuid 3ff8a15c-33d8-49e4-ae8f-a9b830a7dc5f\"]
+[2014-07-26 11:43:56 CEST] chat: ssh [\"-S\",\".git/annex/ssh/git@github.com\",\"-o\",\"ControlMaster=auto\",\"-o\",\"ControlPersist=yes\",\"-T\",\"git@github.com\",\"git-annex-shell 'notifychanges' '/~/Jonan88/annex-sync.git'\"]
+[2014-07-26 11:43:56 CEST] chat: ssh [\"-S\",\".git/annex/ssh/git@gitlab.com\",\"-o\",\"ControlMaster=auto\",\"-o\",\"ControlPersist=yes\",\"-T\",\"git@gitlab.com\",\"git-annex-shell 'notifychanges' '/~/jonan/annex-sync.git'\"]
+[2014-07-26 11:43:56 CEST] read: git [\"--git-dir=/home/jonan/Sync/.git\",\"--work-tree=/home/jonan/Sync\",\"-c\",\"core.bare=false\",\"ls-tree\",\"--full-tree\",\"-z\",\"--\",\"refs/heads/git-annex\",\"uuid.log\",\"remote.log\",\"trust.log\",\"group.log\",\"numcopies.log\",\"schedule.log\",\"preferred-content.log\",\"required-content.log\",\"group-preferred-content.log\"]
+[2014-07-26 11:43:56 CEST] TransferScanner: Syncing with gitlab, github 
+[2014-07-26 11:43:57 CEST] MountWatcher: Using running DBUS service org.kde.DeviceNotifications to monitor mount events.
+[2014-07-26 11:43:57 CEST] NetWatcher: Using running DBUS service org.freedesktop.NetworkManager to monitor network connection events.
+[2014-07-26 11:43:57 CEST] read: git [\"--git-dir=/home/jonan/Sync/.git\",\"--work-tree=/home/jonan/Sync\",\"-c\",\"core.bare=false\",\"symbolic-ref\",\"HEAD\"]
+[2014-07-26 11:43:57 CEST] read: git [\"--git-dir=/home/jonan/Sync/.git\",\"--work-tree=/home/jonan/Sync\",\"-c\",\"core.bare=false\",\"show-ref\",\"refs/heads/annex/direct/master\"]
+[2014-07-26 11:43:57 CEST] read: git [\"--git-dir=/home/jonan/Sync/.git\",\"--work-tree=/home/jonan/Sync\",\"-c\",\"core.bare=false\",\"symbolic-ref\",\"HEAD\"]
+[2014-07-26 11:43:57 CEST] read: git [\"--git-dir=/home/jonan/Sync/.git\",\"--work-tree=/home/jonan/Sync\",\"-c\",\"core.bare=false\",\"show-ref\",\"refs/heads/annex/direct/master\"]
+[2014-07-26 11:43:57 CEST] read: git [\"--git-dir=/home/jonan/Sync/.git\",\"--work-tree=/home/jonan/Sync\",\"-c\",\"core.bare=false\",\"log\",\"refs/heads/annex/direct/master..refs/remotes/github/synced/master\",\"-n1\",\"--pretty=%H\"]
+[2014-07-26 11:43:57 CEST] call: git [\"--git-dir=/home/jonan/Sync/.git\",\"--work-tree=/home/jonan/Sync\",\"-c\",\"core.bare=false\",\"fetch\",\"gitlab\"]
+[2014-07-26 11:43:57 CEST] read: git [\"--git-dir=/home/jonan/Sync/.git\",\"--work-tree=/home/jonan/Sync\",\"-c\",\"core.bare=false\",\"show-ref\",\"git-annex\"]
+[2014-07-26 11:43:57 CEST] read: git [\"--git-dir=/home/jonan/Sync/.git\",\"--work-tree=/home/jonan/Sync\",\"-c\",\"core.bare=false\",\"show-ref\",\"--hash\",\"refs/heads/git-annex\"]
+[2014-07-26 11:43:57 CEST] read: git [\"--git-dir=/home/jonan/Sync/.git\",\"--work-tree=/home/jonan/Sync\",\"-c\",\"core.bare=false\",\"log\",\"refs/heads/git-annex..c0620bd57bd1230fe9282b582bf65cd8ef39f59b\",\"-n1\",\"--pretty=%H\"]
+[2014-07-26 11:43:57 CEST] read: git [\"--git-dir=/home/jonan/Sync/.git\",\"--work-tree=/home/jonan/Sync\",\"-c\",\"core.bare=false\",\"ls-tree\",\"--full-tree\",\"-z\",\"--\",\"refs/heads/git-annex\",\"uuid.log\",\"remote.log\",\"trust.log\",\"group.log\",\"numcopies.log\",\"schedule.log\",\"preferred-content.log\",\"required-content.log\",\"group-preferred-content.log\"]
+[2014-07-26 11:43:57 CEST] read: git [\"--git-dir=/home/jonan/Sync/.git\",\"--work-tree=/home/jonan/Sync\",\"-c\",\"core.bare=false\",\"symbolic-ref\",\"HEAD\"]
+[2014-07-26 11:43:57 CEST] read: git [\"--git-dir=/home/jonan/Sync/.git\",\"--work-tree=/home/jonan/Sync\",\"-c\",\"core.bare=false\",\"show-ref\",\"refs/heads/annex/direct/master\"]
+[2014-07-26 11:43:57 CEST] read: git [\"--git-dir=/home/jonan/Sync/.git\",\"--work-tree=/home/jonan/Sync\",\"-c\",\"core.bare=false\",\"log\",\"refs/heads/annex/direct/master..refs/remotes/ec25486238253.compute1.amazonaws.com_annexsync/synced/master\",\"-n1\",\"--pretty=%H\"]
+[2014-07-26 11:43:57 CEST] RemoteControl: DISCONNECTED ssh://git@gitlab.com/~/jonan/annex-sync.git
+[2014-07-26 11:43:57 CEST] RemoteControl: fromList []
+(scanning...) [2014-07-26 11:43:58 CEST] Watcher: Performing startup scan
+[2014-07-26 11:43:58 CEST] read: git [\"--git-dir=/home/jonan/Sync/.git\",\"--work-tree=/home/jonan/Sync\",\"-c\",\"core.bare=false\",\"show-ref\",\"git-annex\"]
+[2014-07-26 11:43:58 CEST] read: git [\"--git-dir=/home/jonan/Sync/.git\",\"--work-tree=/home/jonan/Sync\",\"-c\",\"core.bare=false\",\"show-ref\",\"--hash\",\"refs/heads/git-annex\"]
+[2014-07-26 11:43:58 CEST] read: git [\"--git-dir=/home/jonan/Sync/.git\",\"--work-tree=/home/jonan/Sync\",\"-c\",\"core.bare=false\",\"log\",\"refs/heads/git-annex..c0620bd57bd1230fe9282b582bf65cd8ef39f59b\",\"-n1\",\"--pretty=%H\"]
+[2014-07-26 11:43:58 CEST] chat: git [\"--git-dir=/home/jonan/Sync/.git\",\"--work-tree=/home/jonan/Sync\",\"-c\",\"core.bare=false\",\"cat-file\",\"--batch\"]
+Invalid command: 'git-annex-shell 'notifychanges' '/~/Jonan88/annex-sync.git''
+  You appear to be using ssh to clone a git:// URL.
+  Make sure your core.gitProxy config option and the
+  GIT_PROXY_COMMA[2014-07-26 11:43:58 CEST] RemoteControl: DISCONNECTED ssh://git@github.com/~/Jonan88/annex-sync.git
+[2014-07-26 11:43:58 CEST] RemoteControl: fromList []
+[2014-07-26 11:43:58 CEST] read: git [\"--git-dir=/home/jonan/Sync/.git\",\"--work-tree=/home/jonan/Sync\",\"-c\",\"core.bare=false\",\"show-ref\",\"git-annex\"]
+[2014-07-26 11:43:58 CEST] read: git [\"--git-dir=/home/jonan/Sync/.git\",\"--work-tree=/home/jonan/Sync\",\"-c\",\"core.bare=false\",\"show-ref\",\"--hash\",\"refs/heads/git-annex\"]
+[2014-07-26 11:43:58 CEST] read: git [\"--git-dir=/home/jonan/Sync/.git\",\"--work-tree=/home/jonan/Sync\",\"-c\",\"core.bare=false\",\"log\",\"refs/heads/git-annex..c0620bd57bd1230fe9282b582bf65cd8ef39f59b\",\"-n1\",\"--pretty=%H\"]
+[2014-07-26 11:43:58 CEST] read: git [\"--git-dir=/home/jonan/Sync/.git\",\"--work-tree=/home/jonan/Sync\",\"-c\",\"core.bare=false\",\"symbolic-ref\",\"HEAD\"]
+[2014-07-26 11:43:58 CEST] read: git [\"--git-dir=/home/jonan/Sync/.git\",\"--work-tree=/home/jonan/Sync\",\"-c\",\"core.bare=false\",\"show-ref\",\"refs/heads/annex/direct/master\"]
+[2014-07-26 11:43:58 CEST] read: git [\"--git-dir=/home/jonan/Sync/.git\",\"--work-tree=/home/jonan/Sync\",\"-c\",\"core.bare=false\",\"log\",\"refs/heads/annex/direct/master..refs/remotes/ec2548437158.compute1.amazonaws.com_annexsync/synced/master\",\"-n1\",\"--pretty=%H\"]
+[2014-07-26 11:43:58 CEST] read: git [\"--git-dir=/home/jonan/Sync/.git\",\"--work-tree=/home/jonan/Sync\",\"-c\",\"core.bare=false\",\"show-ref\",\"git-annex\"]
+[2014-07-26 11:43:58 CEST] read: git [\"--git-dir=/home/jonan/Sync/.git\",\"--work-tree=/home/jonan/Sync\",\"-c\",\"core.bare=false\",\"show-ref\",\"--hash\",\"refs/heads/git-annex\"]
+[2014-07-26 11:43:58 CEST] read: git [\"--git-dir=/home/jonan/Sync/.git\",\"--work-tree=/home/jonan/Sync\",\"-c\",\"core.bare=false\",\"log\",\"refs/heads/git-annex..c0620bd57bd1230fe9282b582bf65cd8ef39f59b\",\"-n1\",\"--pretty=%H\"]
+[2014-07-26 11:43:58 CEST] read: git [\"--git-dir=/home/jonan/Sync/.git\",\"--work-tree=/home/jonan/Sync\",\"-c\",\"core.bare=false\",\"show-ref\",\"git-annex\"]
+[2014-07-26 11:43:58 CEST] read: git [\"--git-dir=/home/jonan/Sync/.git\",\"--work-tree=/home/jonan/Sync\",\"-c\",\"core.bare=false\",\"show-ref\",\"--hash\",\"refs/heads/git-annex\"]
+[2014-07-26 11:43:58 CEST] read: git [\"--git-dir=/home/jonan/Sync/.git\",\"--work-tree=/home/jonan/Sync\",\"-c\",\"core.bare=false\",\"log\",\"refs/heads/git-annex..c0620bd57bd1230fe9282b582bf65cd8ef39f59b\",\"-n1\",\"--pretty=%H\"]
+[2014-07-26 11:43:58 CEST] read: git [\"--git-dir=/home/jonan/Sync/.git\",\"--work-tree=/home/jonan/Sync\",\"-c\",\"core.bare=false\",\"symbolic-ref\",\"HEAD\"]
+[2014-07-26 11:43:58 CEST] read: git [\"--git-dir=/home/jonan/Sync/.git\",\"--work-tree=/home/jonan/Sync\",\"-c\",\"core.bare=false\",\"show-ref\",\"refs/heads/annex/direct/master\"]
+[2014-07-26 11:43:58 CEST] read: git [\"--git-dir=/home/jonan/Sync/.git\",\"--work-tree=/home/jonan/Sync\",\"-c\",\"core.bare=false\",\"log\",\"refs/heads/annex/direct/master..refs/remotes/ec25486248131.compute1.amazonaws.com_annexsync/synced/master\",\"-n1\",\"--pretty=%H\"]
+[2014-07-26 11:43:58 CEST] TransferWatcher: watching for transfers
+[2014-07-26 11:43:58 CEST] read: git [\"--git-dir=/home/jonan/Sync/.git\",\"--work-tree=/home/jonan/Sync\",\"-c\",\"core.bare=false\",\"show-ref\",\"git-annex\"]
+[2014-07-26 11:43:58 CEST] read: git [\"--git-dir=/home/jonan/Sync/.git\",\"--work-tree=/home/jonan/Sync\",\"-c\",\"core.bare=false\",\"show-ref\",\"--hash\",\"refs/heads/git-annex\"]
+[2014-07-26 11:43:58 CEST] read: git [\"--git-dir=/home/jonan/Sync/.git\",\"--work-tree=/home/jonan/Sync\",\"-c\",\"core.bare=false\",\"log\",\"refs/heads/git-annex..c0620bd57bd1230fe9282b582bf65cd8ef39f59b\",\"-n1\",\"--pretty=%H\"]
+[2014-07-26 11:43:58 CEST] read: git [\"--git-dir=/home/jonan/Sync/.git\",\"--work-tree=/home/jonan/Sync\",\"-c\",\"core.bare=false\",\"show-ref\",\"git-annex\"]
+[2014-07-26 11:43:58 CEST] read: git [\"--git-dir=/home/jonan/Sync/.git\",\"--work-tree=/home/jonan/Sync\",\"-c\",\"core.bare=false\",\"show-ref\",\"--hash\",\"refs/heads/git-annex\"]
+[2014-07-26 11:43:58 CEST] read: git [\"--git-dir=/home/jonan/Sync/.git\",\"--work-tree=/home/jonan/Sync\",\"-c\",\"core.bare=false\",\"log\",\"refs/heads/git-annex..c0620bd57bd1230fe9282b582bf65cd8ef39f59b\",\"-n1\",\"--pretty=%H\"]
+[2014-07-26 11:43:58 CEST] read: git [\"--git-dir=/home/jonan/Sync/.git\",\"--work-tree=/home/jonan/Sync\",\"-c\",\"core.bare=false\",\"symbolic-ref\",\"HEAD\"]
+[2014-07-26 11:43:58 CEST] read: git [\"--git-dir=/home/jonan/Sync/.git\",\"--work-tree=/home/jonan/Sync\",\"-c\",\"core.bare=false\",\"show-ref\",\"refs/heads/annex/direct/master\"]
+[2014-07-26 11:43:58 CEST] read: git [\"--git-dir=/home/jonan/Sync/.git\",\"--work-tree=/home/jonan/Sync\",\"-c\",\"core.bare=false\",\"log\",\"refs/heads/annex/direct/master..refs/remotes/gitlab/synced/master\",\"-n1\",\"--pretty=%H\"]
+[2014-07-26 11:43:58 CEST] read: git [\"--git-dir=/home/jonan/Sync/.git\",\"--work-tree=/home/jonan/Sync\",\"-c\",\"core.bare=false\",\"show-ref\",\"git-annex\"]
+[2014-07-26 11:43:58 CEST] read: git [\"--git-dir=/home/jonan/Sync/.git\",\"--work-tree=/home/jonan/Sync\",\"-c\",\"core.bare=false\",\"show-ref\",\"--hash\",\"refs/heads/git-annex\"]
+[2014-07-26 11:43:58 CEST] read: git [\"--git-dir=/home/jonan/Sync/.git\",\"--work-tree=/home/jonan/Sync\",\"-c\",\"core.bare=false\",\"log\",\"refs/heads/git-annex..c0620bd57bd1230fe9282b582bf65cd8ef39f59b\",\"-n1\",\"--pretty=%H\"]
+[2014-07-26 11:43:58 CEST] read: git [\"--git-dir=/home/jonan/Sync/.git\",\"--work-tree=/home/jonan/Sync\",\"-c\",\"core.bare=false\",\"symbolic-ref\",\"HEAD\"]
+[2014-07-26 11:43:58 CEST] read: git [\"--git-dir=/home/jonan/Sync/.git\",\"--work-tree=/home/jonan/Sync\",\"-c\",\"core.bare=false\",\"show-ref\",\"refs/heads/annex/direct/master\"]
+[2014-07-26 11:43:58 CEST] read: git [\"--git-dir=/home/jonan/Sync/.git\",\"--work-tree=/home/jonan/Sync\",\"-c\",\"core.bare=false\",\"log\",\"refs/heads/annex/direct/master..refs/heads/synced/master\",\"-n1\",\"--pretty=%H\"]
+[2014-07-26 11:43:58 CEST] read: git [\"--git-dir=/home/jonan/Sync/.git\",\"--work-tree=/home/jonan/Sync\",\"-c\",\"core.bare=false\",\"show-ref\",\"git-annex\"]
+[2014-07-26 11:43:58 CEST] read: git [\"--git-dir=/home/jonan/Sync/.git\",\"--work-tree=/home/jonan/Sync\",\"-c\",\"core.bare=false\",\"show-ref\",\"--hash\",\"refs/heads/git-annex\"]
+[2014-07-26 11:43:58 CEST] read: git [\"--git-dir=/home/jonan/Sync/.git\",\"--work-tree=/home/jonan/Sync\",\"-c\",\"core.bare=false\",\"log\",\"refs/heads/git-annex..c0620bd57bd1230fe9282b582bf65cd8ef39f59b\",\"-n1\",\"--pretty=%H\"]
+[2014-07-26 11:43:58 CEST] Merger: watching /home/jonan/Sync/.git/refs
+[2014-07-26 11:43:59 CEST] chat: ssh [\"-S\",\".git/annex/ssh/git@github.com\",\"-o\",\"ControlMaster=auto\",\"-o\",\"ControlPersist=yes\",\"-T\",\"git@github.com\",\"git-annex-shell 'notifychanges' '/~/Jonan88/annex-sync.git'\"]
+Invalid command: 'git-annex-shel[2014-07-26 11:43:59 CEST] RemoteControl: DISCONNECTED ssh://git@github.com/~/Jonan88/annex-sync.git
+[2014-07-26 11:43:59 CEST] RemoteControl: fromList []
+[2014-07-26 11:44:00 CEST] call: git [\"--git-dir=/home/jonan/Sync/.git\",\"--work-tree=/home/jonan/Sync\",\"-c\",\"core.bare=false\",\"fetch\",\"github\"]
+[2014-07-26 11:44:01 CEST] chat: ssh [\"-S\",\".git/annex/ssh/git@github.com\",\"-o\",\"ControlMaster=auto\",\"-o\",\"ControlPersist=yes\",\"-T\",\"git@github.com\",\"git-annex-shell 'notifychanges' '/~/Jonan88/annex-sync.git'\"]
+Invalid command: 'git-annex-shell 'notifychanges' '/~[2014-07-26 11:44:01 CEST] RemoteControl: DISCONNECTED ssh://git@github.com/~/Jonan88/annex-sync.git
+[2014-07-26 11:44:01 CEST] RemoteControl: fromList []
+[2014-07-26 11:44:02 CEST] read: git [\"--git-dir=/home/jonan/Sync/.git\",\"--work-tree=/home/jonan/Sync\",\"-c\",\"core.bare=false\",\"show-ref\",\"git-annex\"]
+[2014-07-26 11:44:02 CEST] read: git [\"--git-dir=/home/jonan/Sync/.git\",\"--work-tree=/home/jonan/Sync\",\"-c\",\"core.bare=false\",\"show-ref\",\"--hash\",\"refs/heads/git-annex\"]
+[2014-07-26 11:44:02 CEST] read: git [\"--git-dir=/home/jonan/Sync/.git\",\"--work-tree=/home/jonan/Sync\",\"-c\",\"core.bare=false\",\"log\",\"refs/heads/git-annex..c0620bd57bd1230fe9282b582bf65cd8ef39f59b\",\"-n1\",\"--pretty=%H\"]
+[2014-07-26 11:44:02 CEST] call: git [\"--git-dir=/home/jonan/Sync/.git\",\"--work-tree=/home/jonan/Sync\",\"-c\",\"core.bare=false\",\"show-ref\",\"--verify\",\"-q\",\"refs/remotes/gitlab/annex/direct/master\"]
+[2014-07-26 11:44:02 CEST] call: git [\"--git-dir=/home/jonan/Sync/.git\",\"--work-tree=/home/jonan/Sync\",\"-c\",\"core.bare=false\",\"show-ref\",\"--verify\",\"-q\",\"refs/remotes/gitlab/synced/master\"]
+[2014-07-26 11:44:02 CEST] read: git [\"--git-dir=/home/jonan/Sync/.git\",\"--work-tree=/home/jonan/Sync\",\"-c\",\"core.bare=false\",\"log\",\"refs/heads/synced/master..refs/remotes/gitlab/synced/master\",\"-n1\",\"--pretty=%H\"]
+[2014-07-26 11:44:02 CEST] read: git [\"--git-dir=/home/jonan/Sync/.git\",\"--work-tree=/home/jonan/Sync\",\"-c\",\"core.bare=false\",\"show-ref\",\"--hash\",\"refs/heads/annex/direct/master\"]
+[2014-07-26 11:44:02 CEST] call: git [\"--git-dir=/home/jonan/Sync/.git\",\"--work-tree=/home/jonan/Sync/.git/annex/merge/\",\"-c\",\"core.bare=false\",\"merge\",\"--quiet\",\"--no-commit\",\"--no-ff\",\"refs/remotes/gitlab/synced/master\"]
+[2014-07-26 11:44:02 CEST] read: git [\"--git-dir=/home/jonan/Sync/.git\",\"--work-tree=/home/jonan/Sync\",\"-c\",\"core.bare=false\",\"show-ref\",\"--head\"]
+[2014-07-26 11:44:02 CEST] read: git [\"--git-dir=/home/jonan/Sync/.git\",\"--work-tree=/home/jonan/Sync\",\"-c\",\"core.bare=false\",\"diff-index\",\"-z\",\"--raw\",\"--no-renames\",\"-l0\",\"--cached\",\"72953c0d32d121b75dde10570aa25632641f2a54\"]
+[2014-07-26 11:44:02 CEST] read: git [\"--git-dir=/home/jonan/Sync/.git\",\"--work-tree=/home/jonan/Sync\",\"-c\",\"core.bare=false\",\"show-ref\",\"--head\"]
+[2014-07-26 11:44:02 CEST] read: git [\"--git-dir=/home/jonan/Sync/.git\",\"--work-tree=/home/jonan/Sync\",\"-c\",\"core.bare=false\",\"diff-index\",\"-z\",\"--raw\",\"--no-renames\",\"-l0\",\"--cached\",\"HEAD\"]
+[2014-07-26 11:44:02 CEST] read: git [\"--git-dir=/home/jonan/Sync/.git\",\"--work-tree=/home/jonan/Sync\",\"-c\",\"core.bare=false\",\"log\",\"refs/heads/annex/direct/master..refs/remotes/gitlab/synced/master\",\"-n1\",\"--pretty=%H\",\"--ancestry-path\"]
+[2014-07-26 11:44:02 CEST] read: git [\"--git-dir=/home/jonan/Sync/.git\",\"--work-tree=/home/jonan/Sync\",\"-c\",\"core.bare=false\",\"write-tree\"]
+[2014-07-26 11:44:02 CEST] chat: git [\"--git-dir=/home/jonan/Sync/.git\",\"--work-tree=/home/jonan/Sync\",\"-c\",\"core.bare=false\",\"commit-tree\",\"53de8f3b86ec1b57ab58e7e849d7b38004616dd6\",\"-p\",\"HEAD\",\"-p\",\"refs/remotes/gitlab/synced/master\"]
+[2014-07-26 11:44:02 CEST] call: git [\"--git-dir=/home/jonan/Sync/.git\",\"--work-tree=/home/jonan/Sync\",\"-c\",\"core.bare=false\",\"update-ref\",\"HEAD\",\"073a007b04d28be9439ba847429c53681152af53\"]
+[2014-07-26 11:44:03 CEST] call: git [\"--git-dir=/home/jonan/Sync/.git\",\"--work-tree=/home/jonan/Sync\",\"-c\",\"core.bare=false\",\"show-ref\",\"--verify\",\"-q\",\"refs/remotes/github/annex/direct/master\"]
+[2014-07-26 11:44:03 CEST] call: git [\"--git-dir=/home/jonan/Sync/.git\",\"--work-tree=/home/jonan/Sync\",\"-c\",\"core.bare=false\",\"show-ref\",\"--verify\",\"-q\",\"refs/remotes/github/synced/master\"]
+[2014-07-26 11:44:03 CEST] read: git [\"--git-dir=/home/jonan/Sync/.git\",\"--work-tree=/home/jonan/Sync\",\"-c\",\"core.bare=false\",\"log\",\"refs/heads/synced/master..refs/remotes/github/synced/master\",\"-n1\",\"--pretty=%H\"]
+[2014-07-26 11:44:03 CEST] read: git [\"--git-dir=/home/jonan/Sync/.git\",\"--work-tree=/home/jonan/Sync\",\"-c\",\"core.bare=false\",\"show-ref\",\"--hash\",\"refs/heads/annex/direct/master\"]
+[2014-07-26 11:44:03 CEST] call: git [\"--git-dir=/home/jonan/Sync/.git\",\"--work-tree=/home/jonan/Sync/.git/annex/merge/\",\"-c\",\"core.bare=false\",\"merge\",\"--quiet\",\"--no-commit\",\"--no-ff\",\"refs/remotes/github/synced/master\"]
+[2014-07-26 11:44:03 CEST] read: git [\"--git-dir=/home/jonan/Sync/.git\",\"--work-tree=/home/jonan/Sync\",\"-c\",\"core.bare=false\",\"show-ref\",\"--head\"]
+[2014-07-26 11:44:03 CEST] read: git [\"--git-dir=/home/jonan/Sync/.git\",\"--work-tree=/home/jonan/Sync\",\"-c\",\"core.bare=false\",\"diff-index\",\"-z\",\"--raw\",\"--no-renames\",\"-l0\",\"--cached\",\"073a007b04d28be9439ba847429c53681152af53\"]
+[2014-07-26 11:44:03 CEST] read: git [\"--git-dir=/home/jonan/Sync/.git\",\"--work-tree=/home/jonan/Sync\",\"-c\",\"core.bare=false\",\"show-ref\",\"--head\"]
+[2014-07-26 11:44:03 CEST] read: git [\"--git-dir=/home/jonan/Sync/.git\",\"--work-tree=/home/jonan/Sync\",\"-c\",\"core.bare=false\",\"diff-index\",\"-z\",\"--raw\",\"--no-renames\",\"-l0\",\"--cached\",\"HEAD\"]
+[2014-07-26 11:44:03 CEST] read: git [\"--git-dir=/home/jonan/Sync/.git\",\"--work-tree=/home/jonan/Sync\",\"-c\",\"core.bare=false\",\"log\",\"refs/heads/annex/direct/master..refs/remotes/github/synced/master\",\"-n1\",\"--pretty=%H\",\"--ancestry-path\"]
+[2014-07-26 11:44:03 CEST] read: git [\"--git-dir=/home/jonan/Sync/.git\",\"--work-tree=/home/jonan/Sync\",\"-c\",\"core.bare=false\",\"write-tree\"]
+[2014-07-26 11:44:03 CEST] chat: git [\"--git-dir=/home/jonan/Sync/.git\",\"--work-tree=/home/jonan/Sync\",\"-c\",\"core.bare=false\",\"commit-tree\",\"53de8f3b86ec1b57ab58e7e849d7b38004616dd6\",\"-p\",\"HEAD\",\"-p\",\"refs/remotes/github/synced/master\"]
+[2014-07-26 11:44:03 CEST] call: git [\"--git-dir=/home/jonan/Sync/.git\",\"--work-tree=/home/jonan/Sync\",\"-c\",\"core.bare=false\",\"update-ref\",\"HEAD\",\"aa25ea14ffcb0837e5eaa3d725228c300655f7c1\"]
+[2014-07-26 11:44:03 CEST] read: git [\"--git-dir=/home/jonan/Sync/.git\",\"--work-tree=/home/jonan/Sync\",\"-c\",\"core.bare=false\",\"symbolic-ref\",\"HEAD\"]
+[2014-07-26 11:44:03 CEST] read: git [\"--git-dir=/home/jonan/Sync/.git\",\"--work-tree=/home/jonan/Sync\",\"-c\",\"core.bare=false\",\"show-ref\",\"refs/heads/annex/direct/master\"]
+[2014-07-26 11:44:03 CEST] TransferScanner: pushing to [Remote { name =\"gitlab\" },Remote { name =\"github\" }]
+[2014-07-26 11:44:03 CEST] call: git [\"--git-dir=/home/jonan/Sync/.git\",\"--work-tree=/home/jonan/Sync\",\"-c\",\"core.bare=false\",\"push\",\"gitlab\",\"+git-annex:synced/git-annex\",\"annex/direct/master:synced/master\"]
+[2014-07-26 11:44:03 CEST] call: git [\"--git-dir=/home/jonan/Sync/.git\",\"--work-tree=/home/jonan/Sync\",\"-c\",\"core.bare=false\",\"push\",\"github\",\"+git-annex:synced/git-annex\",\"annex/direct/master:synced/master\"]
+[2014-07-26 11:44:05 CEST] chat: ssh [\"-S\",\".git/annex/ssh/git@github.com\",\"-o\",\"ControlMaster=auto\",\"-o\",\"ControlPersist=yes\",\"-T\",\"git@github.com\",\"git-annex-shell 'notifychanges' '/~/Jonan88/annex-sync.git'\"]
+Invalid command: 'git-annex-shell 'notifychanges' '/~/[2014-07-26 11:44:05 CEST] RemoteControl: DISCONNECTED ssh://git@github.com/~/Jonan88/annex-sync.git
+[2014-07-26 11:44:05 CEST] RemoteControl: fromList []
+[2014-07-26 11:44:14 CEST] chat: ssh [\"-S\",\".git/annex/ssh/git@github.com\",\"-o\",\"ControlMaster=auto\",\"-o\",\"ControlPersist=yes\",\"-T\",\"git@github.com\",\"git-annex-shell 'notifychanges' '/~/Jonan88/annex-sync.git'\"]
+Invalid command: 'git-annex-shell 'notifychanges' '/~[2014-07-26 11:44:14 CEST] RemoteControl: DISCONNECTED ssh://git@github.com/~/Jonan88/annex-sync.git
+[2014-07-26 11:44:14 CEST] RemoteControl: fromList []
+[2014-07-26 11:44:30 CEST] chat: ssh [\"-S\",\".git/annex/ssh/git@github.com\",\"-o\",\"ControlMaster=auto\",\"-o\",\"ControlPersist=yes\",\"-T\",\"git@github.com\",\"git-annex-shell 'notifychanges' '/~/Jonan88/annex-sync.git'\"]
+Invalid command: 'git-annex-shell 'notifychanges'[2014-07-26 11:44:30 CEST] RemoteControl: DISCONNECTED ssh://git@github.com/~/Jonan88/annex-sync.git
+[2014-07-26 11:44:30 CEST] RemoteControl: fromList []
+[2014-07-26 11:45:02 CEST] read: git [\"--git-dir=/home/jonan/Sync/.git\",\"--work-tree=/home/jonan/Sync\",\"-c\",\"core.bare=false\",\"ls-tree\",\"--full-tree\",\"-z\",\"--\",\"refs/heads/git-annex\",\"uuid.log\",\"remote.log\",\"trust.log\",\"group.log\",\"numcopies.log\",\"schedule.log\",\"preferred-content.log\",\"required-content.log\",\"group-preferred-content.log\"]
+[2014-07-26 11:45:02 CEST] chat: ssh [\"-S\",\".git/annex/ssh/git@github.com\",\"-o\",\"ControlMaster=auto\",\"-o\",\"ControlPersist=yes\",\"-T\",\"git@github.com\",\"git-annex-shell 'notifychanges' '/~/Jonan88/annex-sync.git'\"]
+Invalid command: 'git-annex-shell 'notifychanges'[2014-07-26 11:45:02 CEST] RemoteControl: DISCONNECTED ssh://git@github.com/~/Jonan88/annex-sync.git
+[2014-07-26 11:45:02 CEST] RemoteControl: fromList []
+ssh: connect to host ec2-54-86-238-253.comput[2014-07-26 11:46:04 CEST] RemoteControl: DISCONNECTED ssh://admin@ec2-54-86-238-253.compute-1.amazonaws.com/~/annex-sync/
+[2014-07-26 11:46:04 CEST] RemoteControl: fromList []
+[2014-07-26 11:46:05 CEST] chat: ssh [\"-S\",\".git/annex/ssh/cdb5368d318ce8939cedf7b343eb95a9\",\"-o\",\"ControlMaster=auto\",\"-o\",\"ControlPersist=yes\",\"-T\",\"admin@ec2-54-86-238-253.compute-1.amazonaws.com\",\"git-annex-shell 'notifychanges' '/~/annex-sync/' --uuid 3ff8a15c-33d8-49e4-ae8f-a9b830a7dc5f\"]
+[2014-07-26 11:46:06 CEST] chat: ssh [\"-S\",\".git/annex/ssh/git@github.com\",\"-o\",\"ControlMaster=auto\",\"-o\",\"ControlPersist=yes\",\"-T\",\"git@github.com\",\"git-annex-shell 'notifychanges' '/~/Jonan88/annex-sync.git'\"]
+Invalid command: 'git-annex-shell 'notifychange[2014-07-26 11:46:07 CEST] RemoteControl: DISCONNECTED ssh://git@github.com/~/Jonan88/annex-sync.git
+[2014-07-26 11:46:07 CEST] RemoteControl: fromList []
+ssh: connect to host ec2-54-86-238-253.com[2014-07-26 11:48:12 CEST] RemoteControl: DISCONNECTED ssh://admin@ec2-54-86-238-253.compute-1.amazonaws.com/~/annex-sync/
+[2014-07-26 11:48:12 CEST] RemoteControl: fromList []
+[2014-07-26 11:48:14 CEST] chat: ssh [\"-S\",\".git/annex/ssh/cdb5368d318ce8939cedf7b343eb95a9\",\"-o\",\"ControlMaster=auto\",\"-o\",\"ControlPersist=yes\",\"-T\",\"admin@ec2-54-86-238-253.compute-1.amazonaws.com\",\"git-annex-shell 'notifychanges' '/~/annex-sync/' --uuid 3ff8a15c-33d8-49e4-ae8f-a9b830a7dc5f\"]
+[2014-07-26 11:48:15 CEST] chat: ssh [\"-S\",\".git/annex/ssh/git@github.com\",\"-o\",\"ControlMaster=auto\",\"-o\",\"ControlPersist=yes\",\"-T\",\"git@github.com\",\"git-annex-shell 'notifychanges' '/~/Jonan88/annex-sync.git'\"]
+Invalid command: 'git-annex-shell 'notifychanges' [2014-07-26 11:48:15 CEST] RemoteControl: DISCONNECTED ssh://git@github.com/~/Jonan88/annex-sync.git
+[2014-07-26 11:48:15 CEST] RemoteControl: fromList []
+ssh: connect to host ec2-54-86-238-253.compute[2014-07-26 11:50:21 CEST] RemoteControl: DISCONNECTED ssh://admin@ec2-54-86-238-253.compute-1.amazonaws.com/~/annex-sync/
+[2014-07-26 11:50:21 CEST] RemoteControl: fromList []
+[2014-07-26 11:50:25 CEST] chat: ssh [\"-S\",\".git/annex/ssh/cdb5368d318ce8939cedf7b343eb95a9\",\"-o\",\"ControlMaster=auto\",\"-o\",\"ControlPersist=yes\",\"-T\",\"admin@ec2-54-86-238-253.compute-1.amazonaws.com\",\"git-annex-shell 'notifychanges' '/~/annex-sync/' --uuid 3ff8a15c-33d8-49e4-ae8f-a9b830a7dc5f\"]
+[2014-07-26 11:52:31 CEST] chat: ssh [\"-S\",\".git/annex/ssh/git@github.com\",\"-o\",\"ControlMaster=auto\",\"-o\",\"ControlPersist=yes\",\"-T\",\"git@github.com\",\"git-annex-shell 'notifychanges' '/~/Jonan88/annex-sync.git'\"]
+Invalid command: 'git-annex-shell 'notifychanges' '/~/[2014-07-26 11:52:31 CEST] RemoteControl: DISCONNECTED ssh://git@github.com/~/Jonan88/annex-sync.git
+[2014-07-26 11:52:31 CEST] RemoteControl: fromList []
+ssh: connect to host ec2-54-86-238-253.compute-1.a[2014-07-26 11:52:33 CEST] RemoteControl: DISCONNECTED ssh://admin@ec2-54-86-238-253.compute-1.amazonaws.com/~/annex-sync/
+[2014-07-26 11:52:34 CEST] RemoteControl: fromList []
+[2014-07-26 11:52:41 CEST] chat: ssh [\"-S\",\".git/annex/ssh/cdb5368d318ce8939cedf7b343eb95a9\",\"-o\",\"ControlMaster=auto\",\"-o\",\"ControlPersist=yes\",\"-T\",\"admin@ec2-54-86-238-253.compute-1.amazonaws.com\",\"git-annex-shell 'notifychanges' '/~/annex-sync/' --uuid 3ff8a15c-33d8-49e4-ae8f-a9b830a7dc5f\"]
+To git@gitlab.com:jonan/annex-sync.git
+   01dd6e8..aa25ea1  annex/direct/master -> synced/master
+[2014-07-26 11:53:57 CEST] read: git [\"--git-dir=/home/jonan/Sync/.git\",\"--work-tree=/home/jonan/Sync\",\"-c\",\"core.bare=false\",\"push\",\"gitlab\",\"master\"]
+[2014-07-26 11:53:57 CEST] read: git [\"--git-dir=/home/jonan/Sync/.git\",\"--work-tree=/home/jonan/Sync\",\"-c\",\"core.bare=false\",\"symbolic-ref\",\"HEAD\"]
+[2014-07-26 11:53:57 CEST] read: git [\"--git-dir=/home/jonan/Sync/.git\",\"--work-tree=/home/jonan/Sync\",\"-c\",\"core.bare=false\",\"show-ref\",\"refs/heads/annex/direct/master\"]
+[2014-07-26 11:53:57 CEST] read: git [\"--git-dir=/home/jonan/Sync/.git\",\"--work-tree=/home/jonan/Sync\",\"-c\",\"core.bare=false\",\"log\",\"refs/heads/annex/direct/master..refs/remotes/gitlab/synced/master\",\"-n1\",\"--pretty=%H\"]
+Connection to github.com closed by remote host.
+fatal: The remote end hung up unexpectedly
+fatal: The remote end hung up unexpectedly
+[2014-07-26 11:54:07 CEST] read: git [\"--git-dir=/home/jonan/Sync/.git\",\"--work-tree=/home/jonan/Sync\",\"-c\",\"core.bare=false\",\"push\",\"github\",\"master\"]
+[2014-07-26 11:54:32 CEST] TransferScanner: trying manual pull to resolve failed pushes
+[2014-07-26 11:54:32 CEST] call: git [\"--git-dir=/home/jonan/Sync/.git\",\"--work-tree=/home/jonan/Sync\",\"-c\",\"core.bare=false\",\"fetch\",\"github\"]
+[2014-07-26 11:54:34 CEST] read: git [\"--git-dir=/home/jonan/Sync/.git\",\"--work-tree=/home/jonan/Sync\",\"-c\",\"core.bare=false\",\"show-ref\",\"git-annex\"]
+[2014-07-26 11:54:34 CEST] read: git [\"--git-dir=/home/jonan/Sync/.git\",\"--work-tree=/home/jonan/Sync\",\"-c\",\"core.bare=false\",\"show-ref\",\"--hash\",\"refs/heads/git-annex\"]
+[2014-07-26 11:54:34 CEST] read: git [\"--git-dir=/home/jonan/Sync/.git\",\"--work-tree=/home/jonan/Sync\",\"-c\",\"core.bare=false\",\"log\",\"refs/heads/git-annex..c0620bd57bd1230fe9282b582bf65cd8ef39f59b\",\"-n1\",\"--pretty=%H\"]
+[2014-07-26 11:54:34 CEST] call: git [\"--git-dir=/home/jonan/Sync/.git\",\"--work-tree=/home/jonan/Sync\",\"-c\",\"core.bare=false\",\"show-ref\",\"--verify\",\"-q\",\"refs/remotes/github/annex/direct/master\"]
+[2014-07-26 11:54:34 CEST] call: git [\"--git-dir=/home/jonan/Sync/.git\",\"--work-tree=/home/jonan/Sync\",\"-c\",\"core.bare=false\",\"show-ref\",\"--verify\",\"-q\",\"refs/remotes/github/synced/master\"]
+[2014-07-26 11:54:34 CEST] read: git [\"--git-dir=/home/jonan/Sync/.git\",\"--work-tree=/home/jonan/Sync\",\"-c\",\"core.bare=false\",\"log\",\"refs/heads/synced/master..refs/remotes/github/synced/master\",\"-n1\",\"--pretty=%H\"]
+[2014-07-26 11:54:34 CEST] read: git [\"--git-dir=/home/jonan/Sync/.git\",\"--work-tree=/home/jonan/Sync\",\"-c\",\"core.bare=false\",\"show-ref\",\"--hash\",\"refs/heads/annex/direct/master\"]
+[2014-07-26 11:54:34 CEST] call: git [\"--git-dir=/home/jonan/Sync/.git\",\"--work-tree=/home/jonan/Sync/.git/annex/merge/\",\"-c\",\"core.bare=false\",\"merge\",\"--quiet\",\"--no-commit\",\"--no-ff\",\"refs/remotes/github/synced/master\"]
+[2014-07-26 11:54:34 CEST] read: git [\"--git-dir=/home/jonan/Sync/.git\",\"--work-tree=/home/jonan/Sync\",\"-c\",\"core.bare=false\",\"show-ref\",\"--head\"]
+[2014-07-26 11:54:34 CEST] read: git [\"--git-dir=/home/jonan/Sync/.git\",\"--work-tree=/home/jonan/Sync\",\"-c\",\"core.bare=false\",\"diff-index\",\"-z\",\"--raw\",\"--no-renames\",\"-l0\",\"--cached\",\"aa25ea14ffcb0837e5eaa3d725228c300655f7c1\"]
+[2014-07-26 11:54:34 CEST] read: git [\"--git-dir=/home/jonan/Sync/.git\",\"--work-tree=/home/jonan/Sync\",\"-c\",\"core.bare=false\",\"show-ref\",\"--head\"]
+[2014-07-26 11:54:34 CEST] read: git [\"--git-dir=/home/jonan/Sync/.git\",\"--work-tree=/home/jonan/Sync\",\"-c\",\"core.bare=false\",\"diff-index\",\"-z\",\"--raw\",\"--no-renames\",\"-l0\",\"--cached\",\"HEAD\"]
+[2014-07-26 11:54:34 CEST] read: git [\"--git-dir=/home/jonan/Sync/.git\",\"--work-tree=/home/jonan/Sync\",\"-c\",\"core.bare=false\",\"log\",\"refs/heads/annex/direct/master..refs/remotes/github/synced/master\",\"-n1\",\"--pretty=%H\",\"--ancestry-path\"]
+[2014-07-26 11:54:34 CEST] read: git [\"--git-dir=/home/jonan/Sync/.git\",\"--work-tree=/home/jonan/Sync\",\"-c\",\"core.bare=false\",\"write-tree\"]
+[2014-07-26 11:54:34 CEST] chat: git [\"--git-dir=/home/jonan/Sync/.git\",\"--work-tree=/home/jonan/Sync\",\"-c\",\"core.bare=false\",\"commit-tree\",\"53de8f3b86ec1b57ab58e7e849d7b38004616dd6\",\"-p\",\"HEAD\",\"-p\",\"refs/remotes/github/synced/master\"]
+[2014-07-26 11:54:34 CEST] call: git [\"--git-dir=/home/jonan/Sync/.git\",\"--work-tree=/home/jonan/Sync\",\"-c\",\"core.bare=false\",\"update-ref\",\"HEAD\",\"28cad03424f199957d616ecd78f208a24eedf955\"]
+[2014-07-26 11:54:34 CEST] TransferScanner: pushing to [Remote { name =\"github\" }]
+[2014-07-26 11:54:34 CEST] call: git [\"--git-dir=/home/jonan/Sync/.git\",\"--work-tree=/home/jonan/Sync\",\"-c\",\"core.bare=false\",\"push\",\"github\",\"+git-annex:synced/git-annex\",\"annex/direct/master:synced/master\"]
+To git@github.com:Jonan88/annex-sync.git

(Diff truncated)
devblog
diff --git a/doc/devblog/day_203__in_the_weeds.mdwn b/doc/devblog/day_203__in_the_weeds.mdwn
new file mode 100644
index 0000000..a8cf178
--- /dev/null
+++ b/doc/devblog/day_203__in_the_weeds.mdwn
@@ -0,0 +1,39 @@
+A lil bit in the weeds on the chunking rewrite right now. I did succeed in
+writing the core chunk generation code, which can be used for every special
+remote. It was pretty hairy (needs to stream large files in constant
+memory, separating into chunks, and get the progress display right
+across operations on chunks, etc). That took most of the day.
+
+Ended up getting stuck in integrating the encryptable remote code, and had
+to revert changes that could have led to rewriting (or perhaps
+eliminating?) most of the per-remote encryption specific code.
+
+Up till now, this has supported both encrypted and non-encrypted remotes;
+it was simply passed encrypted keys for an encrypted remote:
+
+[[!format haskell """
+remove :: Key -> Annex Bool
+"""]]
+
+But with chunked encrypted keys, it seems it needs to be more complicated:
+
+[[!format haskell """
+remove' :: Maybe (Key -> Key) -> ChunkConfig -> Key -> Annex Bool
+"""]]
+
+So that when the remote is configured to use chunking, it can look up
+the chunk keys, and then encrypt them, in order to remove all the encrypted
+chunk keys.
+
+I don't like that complication, so want to find a cleaner
+abstraction. Will sleep on it.
+
+----
+
+While I was looking at the encryptable remote generator, I realized
+the remote cost was being calculated wrongly for special 
+remotes that are not encrypted. Fixed that bug.
+
+----
+
+Today's work was sponsored by bak.

Added a comment
diff --git a/doc/bugs/Out_of_memory_error_in_fsck_whereis_find_and_status_cmds/comment_8_cf1f9d0be5da4ba874209d981ff8afc6._comment b/doc/bugs/Out_of_memory_error_in_fsck_whereis_find_and_status_cmds/comment_8_cf1f9d0be5da4ba874209d981ff8afc6._comment
new file mode 100644
index 0000000..976664a
--- /dev/null
+++ b/doc/bugs/Out_of_memory_error_in_fsck_whereis_find_and_status_cmds/comment_8_cf1f9d0be5da4ba874209d981ff8afc6._comment
@@ -0,0 +1,38 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlVUq_c3-lrQBculOEUu3yjvdavE7JbvEI"
+ nickname="Stig"
+ subject="comment 8"
+ date="2014-07-25T10:02:53Z"
+ content="""
+\"git annex sync\" or \"git annex fsck\" gives me the same problem.  This is an annex which has previously been running with the git annex assistant.
+
+Output is first:
+
+    $ git annex sync
+    (merging synced/git-annex into git-annex...)
+
+…then the workstation starts swapping, and after eating 16 GB RAM, and all of 16 GB swap, OOM killer komes for \"git\".
+
+The process which eats up all the memory is:
+
+    git --git-dir=/home/ssm/annex/.git --work-tree=/home/ssm/annex \
+      -c core.bare=false log \
+      7bed443dc22961214f86e65aedb8861affd215d3..refs/heads/git-annex \
+      -n1 --pretty=%H
+
+I _think_ that since a \"-n1\" argument is given, it will only show the log for the last commit in the range, and one could specify \"refs/heads/git-annex\" instead of the range.  With just \"refs/heads/git-annex\" instead of the range, it returns a reference instantly.
+
+The output of git count-objects is
+
+    $ git count-objects -H -v
+    count: 334758
+    size: 6.27 GiB
+    in-pack: 16600
+    packs: 1
+    size-pack: 1.70 MiB
+    prune-packable: 0
+    garbage: 0
+    size-garbage: 0 bytes
+
+…and there is 1043 files in the annex.
+"""]]

add a note about direct mode
diff --git a/doc/walkthrough/renaming_files.mdwn b/doc/walkthrough/renaming_files.mdwn
index 85964d1..7ae5f63 100644
--- a/doc/walkthrough/renaming_files.mdwn
+++ b/doc/walkthrough/renaming_files.mdwn
@@ -11,3 +11,9 @@ Notice that, since annexed files are represented by symlinks,
 the symlink will break when the file is moved into a subdirectory.
 But, git-annex will fix this up for you when you commit --
 it has a pre-commit hook that watches for and corrects broken symlinks.
+
+## Direct mode
+
+Note that these git commands only work when git-annex is using indirect mode. Repositories created by the [[assistant]] are in [[direct_mode]]. Running 'git mv' in direct mode will give you an error:
+
+    fatal: This operation must be run in a work tree

file a bug
diff --git a/doc/bugs/youtube_web_download_gives_Prelude.undefined_in_webapp.mdwn b/doc/bugs/youtube_web_download_gives_Prelude.undefined_in_webapp.mdwn
new file mode 100644
index 0000000..7112818
--- /dev/null
+++ b/doc/bugs/youtube_web_download_gives_Prelude.undefined_in_webapp.mdwn
@@ -0,0 +1,25 @@
+### Please describe the problem.
+
+I'm downloading a video with 'git annex addurl' from youtube. The webapp shows the transfer, but when I click the 'web' link it takes me to a page that says "internal server error" and "Prelude.undefined"
+
+### What steps will reproduce the problem?
+
+1. start webapp
+2. download youtube video
+3. click 'web' link on transfer in git-annex
+
+### What version of git-annex are you using? On what operating system?
+
+* Version: 5.20140717
+* OS: Debian sid
+
+### Please provide any additional information below.
+
+Not much in the logs, I see this:
+
+[[!format sh """
+
+[2014-07-25 08:40:14 BST] TransferWatcher: transfer starting: Download UUID "00000000-0000-0000-0000-000000000001" URL--quvi:https://www.youtube.com/watch,63v,61Z8_8jNLsZms Nothing
+[2014-07-25 08:40:14 BST] TransferWatcher: transfer starting: Download UUID "00000000-0000-0000-0000-000000000001" Chase_Adam_at_Startup_School_NY_2014.mp4 Nothing
+
+"""]]

devblog
diff --git a/doc/devblog/day_202__new_chunk_groundwork.mdwn b/doc/devblog/day_202__new_chunk_groundwork.mdwn
new file mode 100644
index 0000000..c8e0ce7
--- /dev/null
+++ b/doc/devblog/day_202__new_chunk_groundwork.mdwn
@@ -0,0 +1,6 @@
+The design for new style chunks seems done, and I laid the groundwork for it
+today. Added chunk metadata to keys, reorganized the legacy chunking code
+for directory and webdav so it won't get (too badly) in the way, and
+implemented the chunk logs in the git-annex branch.
+
+Today's work was sponsored by LeastAuthority.com.

implement chunk logs
Slightly tricky as they are not normal UUIDBased logs, but are instead maps
from (uuid, chunksize) to chunkcount.
This commit was sponsored by Frank Thomas.
diff --git a/Annex/Branch/Transitions.hs b/Annex/Branch/Transitions.hs
index 5c2c145..4c39f19 100644
--- a/Annex/Branch/Transitions.hs
+++ b/Annex/Branch/Transitions.hs
@@ -12,8 +12,9 @@ module Annex.Branch.Transitions (
 
 import Logs
 import Logs.Transitions
-import Logs.UUIDBased as UUIDBased
-import Logs.Presence.Pure as Presence
+import qualified Logs.UUIDBased as UUIDBased
+import qualified Logs.Presence.Pure as Presence
+import qualified Logs.Chunk.Pure as Chunk
 import Types.TrustLevel
 import Types.UUID
 
@@ -37,9 +38,11 @@ dropDead f content trustmap = case getLogVariety f of
 		-- because git remotes may still exist, and they need
 		-- to still know it's dead.
 		| f == trustLog -> PreserveFile
-		| otherwise -> ChangeFile $ UUIDBased.showLog id $ dropDeadFromUUIDBasedLog trustmap $ UUIDBased.parseLog Just content
+		| otherwise -> ChangeFile $ UUIDBased.showLog id $ dropDeadFromMapLog trustmap id $ UUIDBased.parseLog Just content
 	Just NewUUIDBasedLog -> ChangeFile $
-		UUIDBased.showLogNew id $ dropDeadFromUUIDBasedLog trustmap $ UUIDBased.parseLogNew Just content
+		UUIDBased.showLogNew id $ dropDeadFromMapLog trustmap id $ UUIDBased.parseLogNew Just content
+	Just (ChunkLog _) -> ChangeFile $
+		Chunk.showLog $ dropDeadFromMapLog trustmap fst $ Chunk.parseLog content
 	Just (PresenceLog _) ->
 		let newlog = Presence.compactLog $ dropDeadFromPresenceLog trustmap $ Presence.parseLog content
 		in if null newlog
@@ -48,8 +51,8 @@ dropDead f content trustmap = case getLogVariety f of
 	Just OtherLog -> PreserveFile
 	Nothing -> PreserveFile
 
-dropDeadFromUUIDBasedLog :: TrustMap -> UUIDBased.Log String -> UUIDBased.Log String
-dropDeadFromUUIDBasedLog trustmap = M.filterWithKey $ notDead trustmap . const
+dropDeadFromMapLog :: TrustMap -> (k -> UUID) -> M.Map k v -> M.Map k v
+dropDeadFromMapLog trustmap getuuid = M.filterWithKey $ \k _v -> notDead trustmap getuuid k
 
 {- Presence logs can contain UUIDs or other values. Any line that matches
  - a dead uuid is dropped; any other values are passed through. -}
diff --git a/Logs.hs b/Logs.hs
index c9d5815..ff7b7dc 100644
--- a/Logs.hs
+++ b/Logs.hs
@@ -14,6 +14,7 @@ import Types.Key
 data LogVariety
 	= UUIDBasedLog
 	| NewUUIDBasedLog
+	| ChunkLog Key
 	| PresenceLog Key
 	| OtherLog
 	deriving (Show)
@@ -24,6 +25,7 @@ getLogVariety :: FilePath -> Maybe LogVariety
 getLogVariety f
 	| f `elem` topLevelUUIDBasedLogs = Just UUIDBasedLog
 	| isRemoteStateLog f = Just NewUUIDBasedLog
+	| isChunkLog f = ChunkLog <$> chunkLogFileKey f
 	| isMetaDataLog f || f `elem` otherLogs = Just OtherLog
 	| otherwise = PresenceLog <$> firstJust (presenceLogs f)
 
@@ -133,6 +135,25 @@ remoteStateLogExt = ".log.rmt"
 isRemoteStateLog :: FilePath -> Bool
 isRemoteStateLog path = remoteStateLogExt `isSuffixOf` path
 
+{- The filename of the chunk log for a given key. -}
+chunkLogFile :: Key -> FilePath
+chunkLogFile key = hashDirLower key </> keyFile key ++ chunkLogExt
+
+chunkLogFileKey :: FilePath -> Maybe Key
+chunkLogFileKey path
+	| ext == chunkLogExt = fileKey base
+	| otherwise = Nothing
+  where
+  	file = takeFileName path
+	(base, ext) = splitAt (length file - extlen) file
+	extlen = length chunkLogExt
+
+chunkLogExt :: String
+chunkLogExt = ".log.cnk"
+
+isChunkLog :: FilePath -> Bool
+isChunkLog path = chunkLogExt `isSuffixOf` path
+
 {- The filename of the metadata log for a given key. -}
 metaDataLogFile :: Key -> FilePath
 metaDataLogFile key = hashDirLower key </> keyFile key ++ metaDataLogExt
@@ -146,20 +167,23 @@ isMetaDataLog path = metaDataLogExt `isSuffixOf` path
 prop_logs_sane :: Key -> Bool
 prop_logs_sane dummykey = and
 	[ isNothing (getLogVariety "unknown")
-	, expect isUUIDBasedLog (getLogVariety uuidLog)
-	, expect isPresenceLog (getLogVariety $ locationLogFile dummykey)
-	, expect isPresenceLog (getLogVariety $ urlLogFile dummykey)
-	, expect isNewUUIDBasedLog (getLogVariety $ remoteStateLogFile dummykey)
-	, expect isOtherLog (getLogVariety $ metaDataLogFile dummykey)
-	, expect isOtherLog (getLogVariety $ numcopiesLog)
+	, expect gotUUIDBasedLog (getLogVariety uuidLog)
+	, expect gotPresenceLog (getLogVariety $ locationLogFile dummykey)
+	, expect gotPresenceLog (getLogVariety $ urlLogFile dummykey)
+	, expect gotNewUUIDBasedLog (getLogVariety $ remoteStateLogFile dummykey)
+	, expect gotChunkLog (getLogVariety $ chunkLogFile dummykey)
+	, expect gotOtherLog (getLogVariety $ metaDataLogFile dummykey)
+	, expect gotOtherLog (getLogVariety $ numcopiesLog)
 	]
   where
   	expect = maybe False
-  	isUUIDBasedLog UUIDBasedLog = True
-	isUUIDBasedLog _ = False
-  	isNewUUIDBasedLog NewUUIDBasedLog = True
-	isNewUUIDBasedLog _ = False
-	isPresenceLog (PresenceLog k) = k == dummykey
-	isPresenceLog _ = False
-	isOtherLog OtherLog = True
-	isOtherLog _ = False
+	gotUUIDBasedLog UUIDBasedLog = True
+	gotUUIDBasedLog _ = False
+  	gotNewUUIDBasedLog NewUUIDBasedLog = True
+	gotNewUUIDBasedLog _ = False
+	gotChunkLog (ChunkLog k) = k == dummykey
+	gotChunkLog _ = False
+	gotPresenceLog (PresenceLog k) = k == dummykey
+	gotPresenceLog _ = False
+	gotOtherLog OtherLog = True
+	gotOtherLog _ = False
diff --git a/Logs/Chunk.hs b/Logs/Chunk.hs
new file mode 100644
index 0000000..76da509
--- /dev/null
+++ b/Logs/Chunk.hs
@@ -0,0 +1,44 @@
+{- Chunk logs.
+ -
+ - An object can be stored in chunked for on a remote; these logs keep
+ - track of the chunk size used, and the number of chunks.
+ -
+ - It's possible for a single object to be stored multiple times on the
+ - same remote using different chunk sizes. So, while this is a MapLog, it
+ - is not a normal UUIDBased log. Intead, it's a map from UUID and chunk
+ - size to number of chunks.
+ -
+ - Format: "timestamp uuid:chunksize chunkcount"
+ -
+ - Copyright 2014 Joey Hess <joey@kitenet.net>
+ -
+ - Licensed under the GNU GPL version 3 or higher.
+ -}
+
+module Logs.Chunk where
+
+import Common.Annex
+import Logs
+import Logs.MapLog
+import qualified Annex.Branch
+import Logs.Chunk.Pure
+
+import qualified Data.Map as M
+import Data.Time.Clock.POSIX
+
+chunksStored :: UUID -> Key -> ChunkSize -> ChunkCount -> Annex ()
+chunksStored u k chunksize chunkcount = do
+	ts <- liftIO getPOSIXTime
+	Annex.Branch.change (chunkLogFile k) $
+		showLog . changeMapLog ts (u, chunksize) chunkcount . parseLog
+
+chunksRemoved :: UUID -> Key -> ChunkSize -> Annex ()
+chunksRemoved u k chunksize = chunksStored u k chunksize 0
+
+getCurrentChunks :: UUID -> Key -> Annex [(ChunkSize, ChunkCount)]
+getCurrentChunks u k = select . parseLog <$> Annex.Branch.get (chunkLogFile k)
+  where
+	select = filter (\(_sz, ct) -> ct > 0)
+		. map (\((_ku, sz), l) -> (sz, value l))
+		. M.toList
+		. M.filterWithKey (\(ku, _sz) _ -> ku == u)
diff --git a/Logs/Chunk/Pure.hs b/Logs/Chunk/Pure.hs
new file mode 100644
index 0000000..09e871c
--- /dev/null
+++ b/Logs/Chunk/Pure.hs
@@ -0,0 +1,32 @@
+{- Chunk logs, pure operations.
+ -
+ - Copyright 2014 Joey Hess <joey@kitenet.net>
+ -
+ - Licensed under the GNU GPL version 3 or higher.
+ -}
+
+module Logs.Chunk.Pure where
+
+import Common.Annex
+import Logs.MapLog
+import Data.Int
+
+type ChunkSize = Int64
+
+type ChunkCount = Integer
+
+type ChunkLog = MapLog (UUID, ChunkSize) ChunkCount
+

(Diff truncated)
add chunk metadata to Key
Added new fields for chunk number, and chunk size. These will not appear
in normal keys ever, but will be used for chunked data stored on special
remotes.
This commit was sponsored by Jouni K Seppanen.
diff --git a/Backend/WORM.hs b/Backend/WORM.hs
index cc71238..fdeea6f 100644
--- a/Backend/WORM.hs
+++ b/Backend/WORM.hs
@@ -36,7 +36,7 @@ keyValue :: KeySource -> Annex (Maybe Key)
 keyValue source = do
 	stat <- liftIO $ getFileStatus $ contentLocation source
 	n <- genKeyName $ keyFilename source
-	return $ Just Key
+	return $ Just $ stubKey
 		{ keyName = n
 		, keyBackendName = name backend
 		, keySize = Just $ fromIntegral $ fileSize stat
diff --git a/Crypto.hs b/Crypto.hs
index f3a9e39..0bfa81d 100644
--- a/Crypto.hs
+++ b/Crypto.hs
@@ -142,11 +142,9 @@ decryptCipher (EncryptedCipher t variant _) =
  - reversable, nor does it need to be the same type of encryption used
  - on content. It does need to be repeatable. -}
 encryptKey :: Mac -> Cipher -> Key -> Key
-encryptKey mac c k = Key
+encryptKey mac c k = stubKey
 	{ keyName = macWithCipher mac c (key2file k)
 	, keyBackendName = "GPG" ++ showMac mac
-	, keySize = Nothing -- size and mtime omitted
-	, keyMtime = Nothing -- to avoid leaking data
 	}
 
 type Feeder = Handle -> IO ()
diff --git a/Types/Key.hs b/Types/Key.hs
index 26af622..90f66f2 100644
--- a/Types/Key.hs
+++ b/Types/Key.hs
@@ -2,7 +2,7 @@
  - 
  - Most things should not need this, using Types instead
  -
- - Copyright 2011 Joey Hess <joey@kitenet.net>
+ - Copyright 2011-2014 Joey Hess <joey@kitenet.net>
  -
  - Licensed under the GNU GPL version 3 or higher.
  -}
@@ -30,6 +30,8 @@ data Key = Key
 	, keyBackendName :: String
 	, keySize :: Maybe Integer
 	, keyMtime :: Maybe EpochTime
+	, keyChunkSize :: Maybe Integer
+	, keyChunkNum :: Maybe Integer
 	} deriving (Eq, Ord, Read, Show)
 
 {- A filename may be associated with a Key. -}
@@ -41,6 +43,8 @@ stubKey = Key
 	, keyBackendName = ""
 	, keySize = Nothing
 	, keyMtime = Nothing
+	, keyChunkSize = Nothing
+	, keyChunkNum = Nothing
 	}
 
 fieldSep :: Char
@@ -50,13 +54,13 @@ fieldSep = '-'
  - The name field is always shown last, separated by doubled fieldSeps,
  - and is the only field allowed to contain the fieldSep. -}
 key2file :: Key -> FilePath
-key2file Key { keyBackendName = b, keySize = s, keyMtime = m, keyName = n } =
-	b +++ ('s' ?: s) +++ ('m' ?: m) +++ (fieldSep : n)
+key2file Key { keyBackendName = b, keySize = s, keyMtime = m, keyChunkSize = cs, keyChunkNum = cn, keyName = n } =
+	b +++ ('s' ?: s) +++ ('m' ?: m) +++ ('S' ?: cs) +++ ('C' ?: cn) +++ (fieldSep : n)
   where
 	"" +++ y = y
 	x +++ "" = x
 	x +++ y = x ++ fieldSep:y
-	c ?: (Just v) = c : show v
+	f ?: (Just v) = f : show v
 	_ ?: _ = ""
 
 file2key :: FilePath -> Maybe Key
@@ -84,6 +88,13 @@ file2key s
 	addfield 'm' k v = do
 		mtime <- readish v
 		return $ k { keyMtime = Just mtime }
+	addfield 'S' k v = do
+		chunksize <- readish v
+		return $ k { keyChunkSize = Just chunksize }
+	addfield 'C' k v = case readish v of
+		Just chunknum | chunknum > 0 ->
+			return $ k { keyChunkNum = Just chunknum }
+		_ -> return k
 	addfield _ _ _ = Nothing
 
 instance Arbitrary Key where
@@ -92,6 +103,8 @@ instance Arbitrary Key where
 		<*> (listOf1 $ elements ['A'..'Z']) -- BACKEND
 		<*> ((abs <$>) <$> arbitrary) -- size cannot be negative
 		<*> arbitrary
+		<*> ((abs <$>) <$> arbitrary) -- chunksize cannot be negative
+		<*> ((succ . abs <$>) <$> arbitrary) -- chunknum cannot be 0 or negative
 
 prop_idempotent_key_encode :: Key -> Bool
 prop_idempotent_key_encode k = Just k == (file2key . key2file) k
@@ -103,6 +116,6 @@ prop_idempotent_key_decode f
   where
   	-- file2key will accept the fields in any order, so don't
 	-- try the test unless the fields are in the normal order
-	normalfieldorder = fields `isPrefixOf` "sm"
+	normalfieldorder = fields `isPrefixOf` "smSC"
 	fields = map (f !!) $ filter (< length f) $ map succ $
 		elemIndices fieldSep f
diff --git a/Upgrade/V1.hs b/Upgrade/V1.hs
index 8af4848..347b102 100644
--- a/Upgrade/V1.hs
+++ b/Upgrade/V1.hs
@@ -144,7 +144,7 @@ oldlog2key l
 readKey1 :: String -> Key
 readKey1 v
 	| mixup = fromJust $ file2key $ intercalate ":" $ Prelude.tail bits
-	| otherwise = Key
+	| otherwise = stubKey
 		{ keyName = n
 		, keyBackendName = b
 		, keySize = s
diff --git a/doc/design/assistant/chunks.mdwn b/doc/design/assistant/chunks.mdwn
index 42a31bd..c20bb9a 100644
--- a/doc/design/assistant/chunks.mdwn
+++ b/doc/design/assistant/chunks.mdwn
@@ -104,7 +104,7 @@ Problem: Does not solve concurrent uploads with different chunk sizes.
 
 When chunking is enabled, always put a chunk number in the Key,
 along with the chunk size.
-So, SHA256-s10000-c1--xxxxxxx for the first chunk of 1 megabyte.
+So, SHA256-1048576-c1--xxxxxxx for the first chunk of 1 megabyte.
 
 Before any chunks are stored, write a chunkcount file, eg
 SHA256-s12345-c0--xxxxxxx. Note that this key is the same as the original
@@ -148,20 +148,24 @@ could lead to data loss. (Same as in design 2.)
 
 # design 4
 
-Use key SHA256-s10000-c1--xxxxxxx for the first chunk of 1 megabyte.
+Use key SHA256-s12345-S1048576-C1--xxxxxxx for the first chunk of 1 megabyte.
+
+Note that keeping the 's'ize field unchanged is necessary because it 
+disambiguates eg, WORM keys. So a 'S'ize field is used to hold the chunk
+size.
 
 Instead of storing the chunk count in the special remote, store it in 
 the git-annex branch. 
 
-Look at git-annex:aaa/bbb/SHA256-s12345--xxxxxxx.log.cnk to get the 
-chunk count and size. File format would be:
+The location log does not record locations of individual chunk keys
+(too space-inneficient).
+Instead, look at git-annex:aaa/bbb/SHA256-s12345--xxxxxxx.log.cnk to get
+the chunk count and size for a key. File format would be:
 
-	ts uuid chunksize chunkcount 0|1
+	ts uuid chunksize chunkcount
 
-Where a trailing 0 means that chunk size is no longer present on the
-remote, and a trailing 1 means it is. For future expansion, any other
-value /= "0" is also accepted, meaning the chunk is present. For example,
-this could be used for [[deltas]], storing the checksums of the chunks.
+Where a chunkcount of 0 means that the object is not longer present in the
+remote using the specified chunk size.
 
 Note that a given remote uuid might have multiple lines, if a key was
 stored on it twice using different chunk sizes. Also note that even when
diff --git a/doc/internals/key_format.mdwn b/doc/internals/key_format.mdwn
index 17e2059..52fb803 100644
--- a/doc/internals/key_format.mdwn
+++ b/doc/internals/key_format.mdwn
@@ -1,6 +1,6 @@
 A git-annex key has this format:
 
-	BACKEND-sNNNN-mNNNN--NAME
+	BACKEND[-sNNNN][-mNNNN][-SNNNN-CNNNN]--NAME
 
 For example:
 
@@ -10,12 +10,15 @@ For example:
   are always upper-cased.
 * The name field at the end has a format dependent on the backend. It is
   always the last field, and is prefixed with "--". Unlike other fields,
-  it may contain "-" in its content. It should not contain newline characters;
-  otherwise nearly anything goes.
+  it may contain "-" in its content. It should not contain newline
+  characters or "/"; otherwise nearly anything goes. 
 * The "-s" field is optional, and is the size of the content in bytes.
 * The "-m" field is optional, and is the mtime of the file when it was
   added to git-annex, expressed as seconds from the epoch.
   This is currently only used by the WORM backend.
+* The "-S" and "-C" fields are only used for keys that are chunks
+  of some other key. "-S" is the size of the chunk, and "-c" is the chunk
+  number (starting at 1).
 * Other fields could be added in the future, if needed.
 
 git-annex always puts the fields in the order shown above when serializing

document new chunk logfiles
diff --git a/doc/internals.mdwn b/doc/internals.mdwn
index bf0fa66..5cb8ec5 100644
--- a/doc/internals.mdwn
+++ b/doc/internals.mdwn
@@ -219,6 +219,21 @@ reasonably short. If the value contains any whitespace
 (including \r or \r), it will be base64 encoded. Base64 encoded values
 are indicated by prefixing them with "!" 
 
+## `aaa/bbb/*.log.cnk`
+
+These log files are used when objects are stored in chunked form on
+remotes. They record the size(s) of the chunks, and the number of chunks.
+
+For example, this logs that a remote has an object stored using 9 chunks
+of 1 mb size:
+
+	1287290776.765152s e605dca6-446a-11e0-8b2a-002170d25c55 10240 9
+
+(When those chunks are removed from the remote, the 9 is changed to 0.)
+
+For future expansion, additional fields may be present following the
+number of chunks.
+
 ## `schedule.log`
 
 Used to record scheduled events, such as periodic fscks.

clarify field order reqirement
diff --git a/doc/internals/key_format.mdwn b/doc/internals/key_format.mdwn
index ac52bdd..17e2059 100644
--- a/doc/internals/key_format.mdwn
+++ b/doc/internals/key_format.mdwn
@@ -17,7 +17,10 @@ For example:
   added to git-annex, expressed as seconds from the epoch.
   This is currently only used by the WORM backend.
 * Other fields could be added in the future, if needed.
-* Fields may appear, in any order (though always before the name field).
+
+git-annex always puts the fields in the order shown above when serializing
+a key. It can parse keys with the fields in other orders (although the name
+field must always come last).
 
 The `git annex examinekey` command can be used to extract information from
 a key.

update
diff --git a/doc/design/assistant/chunks.mdwn b/doc/design/assistant/chunks.mdwn
index 6523a20..42a31bd 100644
--- a/doc/design/assistant/chunks.mdwn
+++ b/doc/design/assistant/chunks.mdwn
@@ -17,11 +17,11 @@ file, that similarly leaks information.
 It is not currently possible to enable chunking on a non-chunked remote.
 
 Problem: Two uploads of the same key from repos with different chunk sizes
-could lead to data loss. For example, suppose A is 10 mb, and B is 20 mb,
-and the upload speed is the same. If B starts first, when A will overwrite
-the file it is uploading for the 1st chunk. Then A uploads the second
-chunk, and once A is done, B finishes the 1st chunk and uploads its second.
-We now have [chunk 1(from A), chunk 2(from B)].
+could lead to data loss. For example, suppose A is 10 mb chunksize, and B
+is 20 mb, and the upload speed is the same. If B starts first, when A will
+overwrite the file it is uploading for the 1st chunk. Then A uploads the
+second chunk, and once A is done, B finishes the 1st chunk and uploads its
+second. We now have [chunk 1(from A), chunk 2(from B)].
 
 # new requirements
 
@@ -95,7 +95,8 @@ all the chunks are present, if the key size is not known?
 Problem: Also, this makes it difficult to download encrypted keys, because
 we only know the decrypted size, not the encrypted size, so we can't
 be sure how many chunks to get, and all chunks need to be downloaded before
-we can decrypt any of them.
+we can decrypt any of them. (Assuming we encrypt first; chunking first
+avoids this problem.)
 
 Problem: Does not solve concurrent uploads with different chunk sizes.
 
@@ -155,7 +156,12 @@ the git-annex branch.
 Look at git-annex:aaa/bbb/SHA256-s12345--xxxxxxx.log.cnk to get the 
 chunk count and size. File format would be:
 
-	ts uuid chunksize chunkcount
+	ts uuid chunksize chunkcount 0|1
+
+Where a trailing 0 means that chunk size is no longer present on the
+remote, and a trailing 1 means it is. For future expansion, any other
+value /= "0" is also accepted, meaning the chunk is present. For example,
+this could be used for [[deltas]], storing the checksums of the chunks.
 
 Note that a given remote uuid might have multiple lines, if a key was
 stored on it twice using different chunk sizes. Also note that even when
@@ -164,12 +170,12 @@ remote too.
 
 `hasKey` would check if any one (chunksize, chunkcount) is satisfied by
 the files on the remote. It would also check if the non-chunked key is
-present.
+present, as a fallback.
 
 When dropping a key from the remote, drop all logged chunk sizes.
 (Also drop any non-chunked key.)
 
-As long as the location log and the new log are committed atomically,
+As long as the location log and the chunk log are committed atomically,
 this guarantees that no orphaned chunks end up on a remote
 (except any that might be left by interrupted uploads).
 
@@ -189,9 +195,13 @@ Reasons:
    this allows some chunks to come from one and some from another,
    and be reassembled without problems.
 
-2. Prevents an attacker from re-assembling the chunked file using details
-   of the gpg output. Which would expose file size if padding is being used
-   to obscure it.
+2. Also allows chunks of the same object to be downloaded from different
+   remotes, perhaps concurrently, and again be reassembled without
+   problems.
+
+3. Prevents an attacker from re-assembling the chunked file using details
+   of the gpg output. Which would expose approximate
+   file size even if padding is being used to obscure it.
 
 Note that this means that the chunks won't exactly match the configured
 chunk size. gpg does compression, which might make them a

diff --git a/doc/todo/Deduplicate_archive___40__i.e._zip__41___files.mdwn b/doc/todo/Deduplicate_archive___40__i.e._zip__41___files.mdwn
new file mode 100644
index 0000000..314c283
--- /dev/null
+++ b/doc/todo/Deduplicate_archive___40__i.e._zip__41___files.mdwn
@@ -0,0 +1,7 @@
+I've just come across this issue and I'm not sure if git-annex is the right place to put it, but in case it is easy enough to do.. may as well ask!
+
+In this scenario, an online service (Bandcamp), automatically creates the archive file when downloading an album each and every time you download it. This results in identical files inside a zip, but different hashes due to the slightly different timestamps on the archive itself.
+
+Would it be possible for git-annex to be able to detect this scenario (in a manner similar to zipcmp) and redirect an add/import to the already existing copy?
+
+I've found this due to trying to decommission an old annex by `git annex import --clean-duplicates ~/annex_old/.git/annex/objects` and finding these files being left.

chunk then encrypt
diff --git a/doc/design/assistant/chunks.mdwn b/doc/design/assistant/chunks.mdwn
index 224c719..6523a20 100644
--- a/doc/design/assistant/chunks.mdwn
+++ b/doc/design/assistant/chunks.mdwn
@@ -55,13 +55,6 @@ another goal of chunking. At least two things are needed for this:
    so that a remote sees only encrypted files with uniform sizes
    and cannot make guesses about the kinds of data being stored.
 
-Note that encrypting the whole file and then chunking and padding it is not
-good because the remote can probably examine files and tell when a gpg
-stream has been cut into peices, even without the key (have not verified
-this, but it seems likely; certianly gpg magic numbers can identify gpg
-encrypted files so a file that's encrypted but lacks the magic is not the
-first chunk..).
-
 Note that padding cannot completely hide all information from an attacker
 who is logging puts or gets. An attacker could, for example, look at the
 times of puts, and guess at when git-annex has moved on to
@@ -184,3 +177,26 @@ This has the best security of the designs so far, because the special
 remote doesn't know anything about chunk sizes. It uses a little more
 data in the git-annex branch, although with care (using the same timestamp
 as the location log), it can compress pretty well.
+
+## chunk then encrypt
+
+Rather than encrypting the whole object 1st and then chunking, chunk and
+then encrypt.
+
+Reasons:
+
+1. If 2 repos are uploading the same key to a remote concurrently,
+   this allows some chunks to come from one and some from another,
+   and be reassembled without problems.
+
+2. Prevents an attacker from re-assembling the chunked file using details
+   of the gpg output. Which would expose file size if padding is being used
+   to obscure it.
+
+Note that this means that the chunks won't exactly match the configured
+chunk size. gpg does compression, which might make them a
+lot smaller. Or gpg overhead could make them slightly larger. So `hasKey`
+cannot check exact file sizes.
+
+If padding is enabled, gpg compression should be disabled, to not leak
+clues about how well the files compress and so what kind of file it is.

added gpg instructions
diff --git a/doc/install.mdwn b/doc/install.mdwn
index 4c27128..493fdea 100644
--- a/doc/install.mdwn
+++ b/doc/install.mdwn
@@ -19,6 +19,12 @@ detailed instructions             | quick install
 [[Windows]]                       | [download installer](http://downloads.kitenet.net/git-annex/windows/current/) **alpha**
 """]]
 
+The downloaded package's integrity can be verified by the public PGP key.  On Linux,
+
+	$ wget https://downloads.kitenet.net/git-annex/gpg-pubkey.asc
+	$ gpg --import gpg-pubey.asc
+	$ gpg --verify git-annex-standalone-*.tar.gz.sig
+
 ## Using cabal
 
 As a haskell package, git-annex can be installed from source pretty easily

diff --git a/doc/forum/local_subtree_and_broken_symlinks.mdwn b/doc/forum/local_subtree_and_broken_symlinks.mdwn
new file mode 100644
index 0000000..de6dd6e
--- /dev/null
+++ b/doc/forum/local_subtree_and_broken_symlinks.mdwn
@@ -0,0 +1,21 @@
+Here's a simple example on a repository with three branches, where we'll be adding images-annex as a subtree into master.
+
+    $ git branch
+        git-annex
+        images-annex
+      * master
+    $ git subtree add --squash --prefix=images/ images-annex
+      Added dir 'images'
+    $ ls
+      FILE_A        FILE_B        images/
+
+...checkout images-annex, make changes, commit...
+
+    $ git checkout master
+    $ git subtree pull --squash --prefix=images/ . images-annex
+      From .
+      * branch images-annex -> FETCH_HEAD
+      Merge made by the 'recursive' strategy.
+      ...(files created/modified/etc)
+
+I have tried a few different methods for merging the subtree in and so far have not been able to keep git-annex links up to date. Running `git-annex fix .` does what it's supposed to but then git sees everything as modified. Is this entirely the expected behavior because of the --prefix? I have not used subtrees much before but the model appears to be very helpful for what I'm trying to do.

Added a comment
diff --git a/doc/bugs/_WebApp_crashed:_getAddrInfo:_does_not_exist___40__Name_or_service_not_known__41_____91__2014-07-23_16:41:45_CEST__93___WebApp:_warning_WebApp_crashed:_getAddrInfo:_does_not_exist___40__Name_or_service_not_known__41__/comment_2_7be98a630e1deb655a4d1675bf622d05._comment b/doc/bugs/_WebApp_crashed:_getAddrInfo:_does_not_exist___40__Name_or_service_not_known__41_____91__2014-07-23_16:41:45_CEST__93___WebApp:_warning_WebApp_crashed:_getAddrInfo:_does_not_exist___40__Name_or_service_not_known__41__/comment_2_7be98a630e1deb655a4d1675bf622d05._comment
new file mode 100644
index 0000000..2dd9885
--- /dev/null
+++ b/doc/bugs/_WebApp_crashed:_getAddrInfo:_does_not_exist___40__Name_or_service_not_known__41_____91__2014-07-23_16:41:45_CEST__93___WebApp:_warning_WebApp_crashed:_getAddrInfo:_does_not_exist___40__Name_or_service_not_known__41__/comment_2_7be98a630e1deb655a4d1675bf622d05._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="markusk"
+ ip="79.243.250.79"
+ subject="comment 2"
+ date="2014-07-23T23:18:37Z"
+ content="""
+Thank you for the info! Will add the port grep to my auth grep script as you suggested. 
+"""]]

Added a comment
diff --git a/doc/bugs/_WebApp_crashed:_getAddrInfo:_does_not_exist___40__Name_or_service_not_known__41_____91__2014-07-23_16:41:45_CEST__93___WebApp:_warning_WebApp_crashed:_getAddrInfo:_does_not_exist___40__Name_or_service_not_known__41__/comment_1_4d1b96911e3e227c7433ccea543872c1._comment b/doc/bugs/_WebApp_crashed:_getAddrInfo:_does_not_exist___40__Name_or_service_not_known__41_____91__2014-07-23_16:41:45_CEST__93___WebApp:_warning_WebApp_crashed:_getAddrInfo:_does_not_exist___40__Name_or_service_not_known__41__/comment_1_4d1b96911e3e227c7433ccea543872c1._comment
new file mode 100644
index 0000000..5808c56
--- /dev/null
+++ b/doc/bugs/_WebApp_crashed:_getAddrInfo:_does_not_exist___40__Name_or_service_not_known__41_____91__2014-07-23_16:41:45_CEST__93___WebApp:_warning_WebApp_crashed:_getAddrInfo:_does_not_exist___40__Name_or_service_not_known__41__/comment_1_4d1b96911e3e227c7433ccea543872c1._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="24.159.78.125"
+ subject="comment 1"
+ date="2014-07-23T22:10:37Z"
+ content="""
+Support for --listen with a port was removed in version 5.20140306, since it was buggy. In particular, when the webapp creates a new repository, it needs to switch to a new port to serve that repository, so specifying a single port won't work.
+
+Instead, when annex.listen or --listen specifies the address to listen on, `git annex webapp` will print out the url to use to open it, including the port it picked. This could be used in a script, or clicked on in the terminal to open a local browser when running the webapp on a remote host.
+"""]]

link
diff --git a/doc/design/assistant/chunks.mdwn b/doc/design/assistant/chunks.mdwn
index 49cffac..224c719 100644
--- a/doc/design/assistant/chunks.mdwn
+++ b/doc/design/assistant/chunks.mdwn
@@ -29,7 +29,7 @@ Every special remote should support chunking. (It does not make sense
 to support it for git remotes, but gcrypt remotes should support it.)
 
 S3 remotes should chunk by default, because the current S3 backend fails
-for files past a certian size. See [[bugs/]]
+for files past a certian size. See [[bugs/Truncated_file_transferred_via_S3]].
 
 The size of chunks, as well as whether any chunking is done, should be
 configurable on the fly without invalidating data already stored in the

devblog
diff --git a/doc/devblog/day_201__chunky.mdwn b/doc/devblog/day_201__chunky.mdwn
new file mode 100644
index 0000000..b210702
--- /dev/null
+++ b/doc/devblog/day_201__chunky.mdwn
@@ -0,0 +1,12 @@
+Working on designs for better [[chunking|design/assistant/chunks]]. Having
+a hard time finding a way to totally obscure file sizes, but otherwise a
+good design seems to be coming together. I particularly like that the new
+design puts the chunk count in the Key (which is then encrypted for special
+remotes, rather than having it be some special extension.
+
+While thinking through chunking, I realized that the current chunking
+method can fail if two repositories have different chunksize settings for
+the same special remote and both upload the same key at the same time.
+Arn't races fun? The new design will eliminate this problem; in the
+meantime updated the docs to recommend never changing a remote's
+chunksize setting.

minor
diff --git a/doc/design/assistant/chunks.mdwn b/doc/design/assistant/chunks.mdwn
index 53dbf20..49cffac 100644
--- a/doc/design/assistant/chunks.mdwn
+++ b/doc/design/assistant/chunks.mdwn
@@ -21,10 +21,7 @@ could lead to data loss. For example, suppose A is 10 mb, and B is 20 mb,
 and the upload speed is the same. If B starts first, when A will overwrite
 the file it is uploading for the 1st chunk. Then A uploads the second
 chunk, and once A is done, B finishes the 1st chunk and uploads its second.
-We now have 1(from A), 2(from B).
-
-This needs to be supported for back-compat, so keep the chunksize= setting
-to enable that mode, and add a new setting for the new mode.
+We now have [chunk 1(from A), chunk 2(from B)].
 
 # new requirements
 
@@ -42,6 +39,10 @@ on in the webapp when configuring an existing remote).
 Two concurrent uploaders of the same object to a remote should be safe,
 even if they're using different chunk sizes.
 
+The old chunk method needs to be supported for back-compat, so
+keep the chunksize= setting to enable that mode, and add a new setting
+for the new mode.
+
 # obscuring file sizes
 
 To hide from a remote any information about the sizes of files could be
@@ -72,7 +73,7 @@ And, obviously, if someone stores 10 tb of data in a remote, they probably
 have around 10 tb of files, so it's probably not a collection of recipes..
 
 Given its inneficiencies and lack of fully obscuring file sizes,
-padding may not be worth adding.
+padding may not be worth adding, but is considered in the designs below.
 
 # design 1
 
@@ -153,15 +154,15 @@ could lead to data loss. (Same as in design 2.)
 
 # design 4
 
+Use key SHA256-s10000-c1--xxxxxxx for the first chunk of 1 megabyte.
+
 Instead of storing the chunk count in the special remote, store it in 
 the git-annex branch. 
 
-So, use key SHA256-s10000-c1--xxxxxxx for the first chunk of 1 megabyte.
-
-And look at git-annex:aaa/bbb/SHA256-s12345--xxxxxxx.log.cnk to get the 
+Look at git-annex:aaa/bbb/SHA256-s12345--xxxxxxx.log.cnk to get the 
 chunk count and size. File format would be:
 
-	ts uuid  chunksize chunkcount
+	ts uuid chunksize chunkcount
 
 Note that a given remote uuid might have multiple lines, if a key was
 stored on it twice using different chunk sizes. Also note that even when
@@ -173,10 +174,11 @@ the files on the remote. It would also check if the non-chunked key is
 present.
 
 When dropping a key from the remote, drop all logged chunk sizes.
+(Also drop any non-chunked key.)
+
 As long as the location log and the new log are committed atomically,
 this guarantees that no orphaned chunks end up on a remote
 (except any that might be left by interrupted uploads).
-(Also drop any non-chunked key.)
 
 This has the best security of the designs so far, because the special 
 remote doesn't know anything about chunk sizes. It uses a little more

diff --git a/doc/bugs/_WebApp_crashed:_getAddrInfo:_does_not_exist___40__Name_or_service_not_known__41_____91__2014-07-23_16:41:45_CEST__93___WebApp:_warning_WebApp_crashed:_getAddrInfo:_does_not_exist___40__Name_or_service_not_known__41__.mdwn b/doc/bugs/_WebApp_crashed:_getAddrInfo:_does_not_exist___40__Name_or_service_not_known__41_____91__2014-07-23_16:41:45_CEST__93___WebApp:_warning_WebApp_crashed:_getAddrInfo:_does_not_exist___40__Name_or_service_not_known__41__.mdwn
index 7f8d51e..77d2beb 100644
--- a/doc/bugs/_WebApp_crashed:_getAddrInfo:_does_not_exist___40__Name_or_service_not_known__41_____91__2014-07-23_16:41:45_CEST__93___WebApp:_warning_WebApp_crashed:_getAddrInfo:_does_not_exist___40__Name_or_service_not_known__41__.mdwn
+++ b/doc/bugs/_WebApp_crashed:_getAddrInfo:_does_not_exist___40__Name_or_service_not_known__41_____91__2014-07-23_16:41:45_CEST__93___WebApp:_warning_WebApp_crashed:_getAddrInfo:_does_not_exist___40__Name_or_service_not_known__41__.mdwn
@@ -8,6 +8,7 @@ some time ago i was using the webapp bound to a dedicated port number to get aro
 it never starts but just keeps waiting forever(?) 
 
 Update:(to clarify - the following works fine but results in the "random" port "problem")
+
     git-annex webapp --listen=192.168.21.12
 
 

4 designs for better chunking
Having a hard time finding a way to totally obscure file sizes, but
otherwise happy with design #4.
This commit was sponsored by Michael Alan Dorman.
diff --git a/doc/design/assistant/chunks.mdwn b/doc/design/assistant/chunks.mdwn
index 6a92731..53dbf20 100644
--- a/doc/design/assistant/chunks.mdwn
+++ b/doc/design/assistant/chunks.mdwn
@@ -5,3 +5,180 @@ May be a useful starting point for [[deltas]].
 
 May also allow for downloading different chunks of a file concurrently from
 multiple remotes.
+
+# currently
+
+Currently, only the webdav and directory special remotes support chunking.
+
+Filenames are used for the chunks that make it easy to see which chunks
+belong together, even when encryption is used. There is also a chunkcount
+file, that similarly leaks information.
+
+It is not currently possible to enable chunking on a non-chunked remote.
+
+Problem: Two uploads of the same key from repos with different chunk sizes
+could lead to data loss. For example, suppose A is 10 mb, and B is 20 mb,
+and the upload speed is the same. If B starts first, when A will overwrite
+the file it is uploading for the 1st chunk. Then A uploads the second
+chunk, and once A is done, B finishes the 1st chunk and uploads its second.
+We now have 1(from A), 2(from B).
+
+This needs to be supported for back-compat, so keep the chunksize= setting
+to enable that mode, and add a new setting for the new mode.
+
+# new requirements
+
+Every special remote should support chunking. (It does not make sense
+to support it for git remotes, but gcrypt remotes should support it.)
+
+S3 remotes should chunk by default, because the current S3 backend fails
+for files past a certian size. See [[bugs/]]
+
+The size of chunks, as well as whether any chunking is done, should be
+configurable on the fly without invalidating data already stored in the
+remote. This seems important for usability (eg, so users can turn chunking
+on in the webapp when configuring an existing remote).
+
+Two concurrent uploaders of the same object to a remote should be safe,
+even if they're using different chunk sizes.
+
+# obscuring file sizes
+
+To hide from a remote any information about the sizes of files could be
+another goal of chunking. At least two things are needed for this:
+
+1. The filenames used on the remote don't indicate which chunks belong
+   together.
+
+2. The final short chunk needs to be padded with random data,
+   so that a remote sees only encrypted files with uniform sizes
+   and cannot make guesses about the kinds of data being stored.
+
+Note that encrypting the whole file and then chunking and padding it is not
+good because the remote can probably examine files and tell when a gpg
+stream has been cut into peices, even without the key (have not verified
+this, but it seems likely; certianly gpg magic numbers can identify gpg
+encrypted files so a file that's encrypted but lacks the magic is not the
+first chunk..).
+
+Note that padding cannot completely hide all information from an attacker
+who is logging puts or gets. An attacker could, for example, look at the
+times of puts, and guess at when git-annex has moved on to
+encrypting/decrypting the next object, and so guess at the approximate
+sizes of objects. (Concurrent uploads/downloads or random delays could be
+added to prevent these kinds of attacks.)
+
+And, obviously, if someone stores 10 tb of data in a remote, they probably
+have around 10 tb of files, so it's probably not a collection of recipes..
+
+Given its inneficiencies and lack of fully obscuring file sizes,
+padding may not be worth adding.
+
+# design 1
+
+Add an optional chunk field to Key. It is only present for chunk
+2 and above. Ie, SHA256-s12345--xxxxxxx is the first chunk (or whole
+object), while SHA256-s12345-c2--xxxxxxx is the second chunk.
+
+On an encrypted remote, Keys are generated with the chunk field, and then
+HMAC enrypted.
+
+Note that only using it for chunks 2+ means that git-annex can start by
+requesting the regular key, so an observer sees the same request whether
+chunked or not, and does not see eg, a pattern of failed requests for 
+a non-chunked key, followed by successful requests for the chunked keys.
+(Both more efficient and perhaps more secure.)
+
+Problem: This makes putting chunks easy. But there is a problem when getting 
+an object that has been chunked. If the key size is not known, we
+cannot tell when we've gotten the last chunk. (Also, we cannot strip
+padding.) Note that `addurl` sometimes generates keys w/o size info
+(particularly, it does so by design when using quvi).
+
+Problem: Also, this makes `hasKey` hard to implement: How can it know if
+all the chunks are present, if the key size is not known?
+
+Problem: Also, this makes it difficult to download encrypted keys, because
+we only know the decrypted size, not the encrypted size, so we can't
+be sure how many chunks to get, and all chunks need to be downloaded before
+we can decrypt any of them.
+
+Problem: Does not solve concurrent uploads with different chunk sizes.
+
+# design 2
+
+When chunking is enabled, always put a chunk number in the Key,
+along with the chunk size.
+So, SHA256-s10000-c1--xxxxxxx for the first chunk of 1 megabyte.
+
+Before any chunks are stored, write a chunkcount file, eg
+SHA256-s12345-c0--xxxxxxx. Note that this key is the same as the original
+object's key, except with chunk number set to 0. This file contains both
+the number of chunks, and also the chunk size used. `hasKey` downloads this
+file, and then verifies that each chunk is present, looking for keys with
+the expected chunk numbers and chunk size.
+
+This avoids problems with multiple writers using different chunk sizes,
+since they will be uploading to different files.
+
+Problem: In such a situation, some duplicate data might be stored, not
+referenced by the last chunkcount file to be written. It would not be
+dropped when the key was removed from the remote.
+
+Note: This design lets an attacker with logs tell the (appoximate) size of
+objects, by finding the small files that contain a chunk count, and
+correlating when that is written/read and when other files are
+written/read. That could be solved by padding the chunkcount key up to the
+size of the rest of the keys, but that's very innefficient; `hasKey` is not
+designed to need to download large files.
+
+# design 3
+
+Like design 1, but add an encrypted chunk count prefix to the first object.
+This needs to be done in a way that does not let an attacker tell if the
+object has an encrypted chunk count prefix or not. 
+
+This seems difficult; attacker could probably tell where the first encrypted
+part stops and the next encrypted part starts by looking for gpg headers,
+and so tell which files are the first chunks.
+
+Also, `hasKey` would need to download some or all of the first file.
+If all, that's a lot more expensive. If only some is downloaded, an
+attacker can guess that the file that was partially downloaded is the
+first chunk in a series, and wait for a time when it's fully downloaded to
+determine which are the other chunks.
+
+Problem: Two uploads of the same key from repos with different chunk sizes
+could lead to data loss. (Same as in design 2.)
+
+# design 4
+
+Instead of storing the chunk count in the special remote, store it in 
+the git-annex branch. 
+
+So, use key SHA256-s10000-c1--xxxxxxx for the first chunk of 1 megabyte.
+
+And look at git-annex:aaa/bbb/SHA256-s12345--xxxxxxx.log.cnk to get the 
+chunk count and size. File format would be:
+
+	ts uuid  chunksize chunkcount
+
+Note that a given remote uuid might have multiple lines, if a key was
+stored on it twice using different chunk sizes. Also note that even when
+this file exists for a key, the object may be stored non-chunked on the
+remote too.
+
+`hasKey` would check if any one (chunksize, chunkcount) is satisfied by
+the files on the remote. It would also check if the non-chunked key is
+present.
+
+When dropping a key from the remote, drop all logged chunk sizes.
+As long as the location log and the new log are committed atomically,
+this guarantees that no orphaned chunks end up on a remote
+(except any that might be left by interrupted uploads).
+(Also drop any non-chunked key.)
+
+This has the best security of the designs so far, because the special 
+remote doesn't know anything about chunk sizes. It uses a little more
+data in the git-annex branch, although with care (using the same timestamp
+as the location log), it can compress pretty well.

diff --git a/doc/bugs/_WebApp_crashed:_getAddrInfo:_does_not_exist___40__Name_or_service_not_known__41_____91__2014-07-23_16:41:45_CEST__93___WebApp:_warning_WebApp_crashed:_getAddrInfo:_does_not_exist___40__Name_or_service_not_known__41__.mdwn b/doc/bugs/_WebApp_crashed:_getAddrInfo:_does_not_exist___40__Name_or_service_not_known__41_____91__2014-07-23_16:41:45_CEST__93___WebApp:_warning_WebApp_crashed:_getAddrInfo:_does_not_exist___40__Name_or_service_not_known__41__.mdwn
index c6f8eda..7f8d51e 100644
--- a/doc/bugs/_WebApp_crashed:_getAddrInfo:_does_not_exist___40__Name_or_service_not_known__41_____91__2014-07-23_16:41:45_CEST__93___WebApp:_warning_WebApp_crashed:_getAddrInfo:_does_not_exist___40__Name_or_service_not_known__41__.mdwn
+++ b/doc/bugs/_WebApp_crashed:_getAddrInfo:_does_not_exist___40__Name_or_service_not_known__41_____91__2014-07-23_16:41:45_CEST__93___WebApp:_warning_WebApp_crashed:_getAddrInfo:_does_not_exist___40__Name_or_service_not_known__41__.mdwn
@@ -7,7 +7,8 @@ some time ago i was using the webapp bound to a dedicated port number to get aro
 
 it never starts but just keeps waiting forever(?) 
 
-
+Update:(to clarify - the following works fine but results in the "random" port "problem")
+    git-annex webapp --listen=192.168.21.12
 
 
 

recommend users not change the chunksize
Suppose A is 10 mb, and B is 20 mb, and the upload speed is the same. If B
starts first, when A will overwrite the file it is uploading for the 1st chunk.
Then A uploads the second chunk, and once A is done, B finishes the 1st chunk
and uploads its second. We now have 1(from A), 2(from B), so data loss.
diff --git a/doc/special_remotes/directory.mdwn b/doc/special_remotes/directory.mdwn
index b79cf75..96d5938 100644
--- a/doc/special_remotes/directory.mdwn
+++ b/doc/special_remotes/directory.mdwn
@@ -31,7 +31,7 @@ remote:
   The value can use specified using any commonly used units.
   Example: `chunksize=100 megabytes`  
   Note that enabling chunking on an existing remote with non-chunked
-  files is not recommended.
+  files is not recommended; nor is changing the chunksize.
 
 Setup example:
 
diff --git a/doc/special_remotes/webdav.mdwn b/doc/special_remotes/webdav.mdwn
index 21b213e..871540a 100644
--- a/doc/special_remotes/webdav.mdwn
+++ b/doc/special_remotes/webdav.mdwn
@@ -35,7 +35,7 @@ the webdav remote.
   The value can use specified using any commonly used units.
   Example: `chunksize=75 megabytes`  
   Note that enabling chunking on an existing remote with non-chunked
-  files is not recommended.
+  files is not recommended, nor is changing the chunksize.
 
 Setup example:
 

New bug using webapp with --listen=IP:Port
diff --git a/doc/bugs/_WebApp_crashed:_getAddrInfo:_does_not_exist___40__Name_or_service_not_known__41_____91__2014-07-23_16:41:45_CEST__93___WebApp:_warning_WebApp_crashed:_getAddrInfo:_does_not_exist___40__Name_or_service_not_known__41__.mdwn b/doc/bugs/_WebApp_crashed:_getAddrInfo:_does_not_exist___40__Name_or_service_not_known__41_____91__2014-07-23_16:41:45_CEST__93___WebApp:_warning_WebApp_crashed:_getAddrInfo:_does_not_exist___40__Name_or_service_not_known__41__.mdwn
new file mode 100644
index 0000000..c6f8eda
--- /dev/null
+++ b/doc/bugs/_WebApp_crashed:_getAddrInfo:_does_not_exist___40__Name_or_service_not_known__41_____91__2014-07-23_16:41:45_CEST__93___WebApp:_warning_WebApp_crashed:_getAddrInfo:_does_not_exist___40__Name_or_service_not_known__41__.mdwn
@@ -0,0 +1,42 @@
+### Please describe the problem.
+
+
+some time ago i was using the webapp bound to a dedicated port number to get around firewall reconfig. Now after some time without using the webapp i'm using it again and when i start it with 
+
+     git-annex webapp --listen=192.168.21.12:46199
+
+it never starts but just keeps waiting forever(?) 
+
+
+
+
+
+
+### What steps will reproduce the problem?
+
+
+git-annex webapp --listen=192.168.21.12:46199
+
+
+### What version of git-annex are you using? On what operating system?
+
+
+version 5.20140716-g8c14ba8 on debian wheezy using your pre build static tar archive. 
+
+### 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
+
+
+the log output is the following 3 lines 
+
+[2014-07-23 16:41:45 CEST] main: starting assistant version 5.20140716-g8c14ba8
+WebApp crashed: getAddrInfo: does not exist (Name or service not known)
+[2014-07-23 16:41:45 CEST] WebApp: warning WebApp crashed: getAddrInfo: does not exist (Name or service not known)
+
+
+
+# End of transcript or log.
+"""]]

Added a comment
diff --git a/doc/bugs/git_annex_requested_key_is_not_present_on_random_files_even_though_they_exist___40__Direct_mode__41__/comment_3_c377b56d20b291877be3c7bce5e7bd0c._comment b/doc/bugs/git_annex_requested_key_is_not_present_on_random_files_even_though_they_exist___40__Direct_mode__41__/comment_3_c377b56d20b291877be3c7bce5e7bd0c._comment
new file mode 100644
index 0000000..6004fba
--- /dev/null
+++ b/doc/bugs/git_annex_requested_key_is_not_present_on_random_files_even_though_they_exist___40__Direct_mode__41__/comment_3_c377b56d20b291877be3c7bce5e7bd0c._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="24.159.78.125"
+ subject="comment 3"
+ date="2014-07-23T15:14:21Z"
+ content="""
+Actually no, rsync was never run on the server. git-annex-shell looked to see if the file was present, and did not see the file.
+"""]]

Added a comment
diff --git a/doc/bugs/git_annex_requested_key_is_not_present_on_random_files_even_though_they_exist___40__Direct_mode__41__/comment_2_c4c0dcc0074ff89866fb261c2d30148f._comment b/doc/bugs/git_annex_requested_key_is_not_present_on_random_files_even_though_they_exist___40__Direct_mode__41__/comment_2_c4c0dcc0074ff89866fb261c2d30148f._comment
new file mode 100644
index 0000000..3362fba
--- /dev/null
+++ b/doc/bugs/git_annex_requested_key_is_not_present_on_random_files_even_though_they_exist___40__Direct_mode__41__/comment_2_c4c0dcc0074ff89866fb261c2d30148f._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="24.159.78.125"
+ subject="comment 2"
+ date="2014-07-23T15:05:36Z"
+ content="""
+This looks very much like rsync on the server crashed, possibly because of an error reading the file.
+
+Accessing a git-annex repository over a network filesystem is almost never the best choice. Network filesystems are flakey at worst, and at best have locking problems and other limiations.
+
+
+"""]]

close; not a git-annex bug
diff --git a/doc/bugs/git_annex_requested_key_is_not_present_on_random_files_even_though_they_exist___40__Direct_mode__41__.mdwn b/doc/bugs/git_annex_requested_key_is_not_present_on_random_files_even_though_they_exist___40__Direct_mode__41__.mdwn
index ec3de62..2ac7319 100644
--- a/doc/bugs/git_annex_requested_key_is_not_present_on_random_files_even_though_they_exist___40__Direct_mode__41__.mdwn
+++ b/doc/bugs/git_annex_requested_key_is_not_present_on_random_files_even_though_they_exist___40__Direct_mode__41__.mdwn
@@ -74,3 +74,5 @@ upgrade supported from repository versions: 2 3 4
 
 # End of transcript or log.
 """]]
+
+> [[done]]; does not appear to be a git-annex bug. --[[Joey]]

Added a comment
diff --git a/doc/forum/Reloading_.git__47__config_mid-sync/comment_1_69e8879e0fed0e1b1589a721f9c6e3c7._comment b/doc/forum/Reloading_.git__47__config_mid-sync/comment_1_69e8879e0fed0e1b1589a721f9c6e3c7._comment
new file mode 100644
index 0000000..d39b21f
--- /dev/null
+++ b/doc/forum/Reloading_.git__47__config_mid-sync/comment_1_69e8879e0fed0e1b1589a721f9c6e3c7._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="24.159.78.125"
+ subject="comment 1"
+ date="2014-07-23T15:02:04Z"
+ content="""
+Assistant does not support SIGHUP. There is a menu item (top right menu) that can restart it.
+"""]]

update per request
diff --git a/doc/thanks.mdwn b/doc/thanks.mdwn
index 62b0b82..10ab1f1 100644
--- a/doc/thanks.mdwn
+++ b/doc/thanks.mdwn
@@ -71,7 +71,7 @@ Jawurek, Johan Herland, Gian-Maria Daffre, Justine Lam, Ori Livneh, Arnaud
 Berthomier, Chad Horohoe, Lois DeFiore, Lieven Baes, Patrick Wheeler, James
 Kim, Carlos Trijueque Albarran, Ritesh Nadhani, chesty, Andre Pereira,
 Eskild Hustvedt, David Wagner, Maximiliano Curia, András Széll, Allan
-Holman, Thomas Langewouters, Anonymous, Yannick Leyendecker, Peter
+Holman, Thomas Langewouters, Anonymous, Peter Daengeli, Josh Taylor, Abhishek Dasgupta, Maarten Aertsen, Mark Sheppard,
 Daengeli, Josh Taylor, Abhishek Dasgupta, Maarten Aertsen, Mark Sheppard,
 Markus Engström, Samuel Tardieu, Geog Wechslberger, Abdó Roig, Dmitry
 Markushevich, Sergio Rubio, Jim Paris, Vivek Gani, Brock Spratlen, Nathan

Added a comment: ok some progress
diff --git a/doc/bugs/git_annex_requested_key_is_not_present_on_random_files_even_though_they_exist___40__Direct_mode__41__/comment_1_410a591983ebb593e8ca978ceddf6a2c._comment b/doc/bugs/git_annex_requested_key_is_not_present_on_random_files_even_though_they_exist___40__Direct_mode__41__/comment_1_410a591983ebb593e8ca978ceddf6a2c._comment
new file mode 100644
index 0000000..8629e05
--- /dev/null
+++ b/doc/bugs/git_annex_requested_key_is_not_present_on_random_files_even_though_they_exist___40__Direct_mode__41__/comment_1_410a591983ebb593e8ca978ceddf6a2c._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkt8DjG40gowj_ETchFLDS_Z216tr7p1xw"
+ nickname="Adam"
+ subject="ok some progress"
+ date="2014-07-23T14:27:51Z"
+ content="""
+I tried to do the same from another local repository on the server and it worked fine.
+
+I created a Linux VM and that also struggled, but this time with 57 errors.
+
+It turns out that the way my files were being stored on the server was causing it.  I had the files stored on a local NAS which was mounted via iSCSI.  I moved the repository from the NAS to local storage and then did another clone and it is now working from the Linux VM and the Windows client via SSH.  When using git annex get on the Linux VM it is much faster than the native Git bash which takes ages.
+"""]]

diff --git a/doc/bugs/git_annex_requested_key_is_not_present_on_random_files_even_though_they_exist___40__Direct_mode__41__.mdwn b/doc/bugs/git_annex_requested_key_is_not_present_on_random_files_even_though_they_exist___40__Direct_mode__41__.mdwn
new file mode 100644
index 0000000..ec3de62
--- /dev/null
+++ b/doc/bugs/git_annex_requested_key_is_not_present_on_random_files_even_though_they_exist___40__Direct_mode__41__.mdwn
@@ -0,0 +1,76 @@
+### Please describe the problem.
+
+I have a repo on a server running in direct mode.  This repo is running Ubuntu 12.04 LTS.  I run a windows laptop and the git-annex client to synchronise via SSH.
+
+### What steps will reproduce the problem?
+
+I set up the repo as normal on the server, clone it on the laptop, then when I issue the 'git annex get workspace' command to get the content for the workspace directory there are 10 random files with which I am getting the following error:
+
+get workspace/XXXXXXXX/Functional_Design/test3.docx (from origin...)
+[2014-07-23 11:28:42 GMT Daylight Time] read: rsync ["--progress","--inplace","-
+e","'ssh' '-T' 'adam@172.21.25.11' 'git-annex-shell ''sendkey'' ''/mnt/NAS1/repo
+s/XXXXXXXXXXXXXXXXX'' ''SHA256E-s31601--6f4995ef93be1f640a8b229f84abc69bd44daf63
+6afeae9c1bcf91a6287cd92b.docx'' --uuid 51dce2ea-39c6-4498-a99d-8e189c154eef ''--
+'' ''remoteuuid=c5ec0b9a-b79e-4f3b-8f28-0e869b150f9c'' ''direct=1'' ''associated
+file=workspace/XXXXXXXX/Functional_Design/test3.docx'' ''--'''","--","dummy:","/
+cygdrive/c/repos/XXXXXXXXXXXXXXXXX/.git/annex/tmp/SHA256E-s31601--6f4995ef93be1f
+640a8b229f84abc69bd44daf636afeae9c1bcf91a6287cd92b.docx"]
+  requested key is not present
+rsync: connection unexpectedly closed (0 bytes received so far) [Receiver]
+rsync error: error in rsync protocol data stream (code 12) at /home/lapo/package
+/rsync-3.0.9-1/src/rsync-3.0.9/io.c(605) [Receiver=3.0.9]
+
+  rsync failed -- run git annex again to resume file transfer
+
+  Unable to access these remotes: origin
+
+  Try making some of these repositories available:
+        51dce2ea-39c6-4498-a99d-8e189c154eef -- root@vpndude:/mnt/NAS1/repos/XXXXXXXXXXXXXXXXXX [origin]
+failed
+
+I have checked the files and the keys and they all seem to match.  There are hundreds of other files which do work fine.
+
+I deleted the laptop repo and cloned again and had another attempt but the same thing occured again.
+
+I have checked permissions on these files and they are identical to other files which are working.
+
+I have run git annex sync on the server and the laptop, this has no impact.
+
+I have run git annex fsck on both server and laptop and this has no impact.
+
+I'm clueless as to why this is happening.
+
+### What version of git-annex are you using? On what operating system?
+
+Ubuntu 12.04 LTS:
+git-annex version: 5.20140716-g8c14ba8
+build flags: Assistant Webapp Webapp-secure Pairing Testsuite S3 WebDAV 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 webdav tahoe glacier ddar hook external
+local repository version: 5
+supported repository version: 5
+upgrade supported from repository versions: 0 1 2 4
+
+Windows 7:
+git-annex version: 5.20140717-g3de6e4b
+build flags: Assistant Webapp Webapp-secure Pairing Testsuite S3 WebDAV DNS Feed
+s Quvi TDFA CryptoHash
+key/value backends: SHA256E SHA1E SHA512E SHA224E SHA384E SKEIN256E SKEIN512E SH
+A256 SHA1 SHA512 SHA224 SHA384 SKEIN256 SKEIN512 WORM URL
+remote types: git gcrypt S3 bup directory rsync web webdav tahoe glacier ddar ho
+ok external
+local repository version: 5
+supported repository version: 5
+upgrade supported from repository versions: 2 3 4
+
+### 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.
+"""]]

Added a comment
diff --git a/doc/forum/Standard_groups__47__preferred_contents/comment_6_c70c9fa97bce8e4eb9b3880d8f843aef._comment b/doc/forum/Standard_groups__47__preferred_contents/comment_6_c70c9fa97bce8e4eb9b3880d8f843aef._comment
new file mode 100644
index 0000000..435d7f7
--- /dev/null
+++ b/doc/forum/Standard_groups__47__preferred_contents/comment_6_c70c9fa97bce8e4eb9b3880d8f843aef._comment
@@ -0,0 +1,25 @@
+[[!comment format=mdwn
+ username="divB"
+ ip="204.17.143.10"
+ subject="comment 6"
+ date="2014-07-23T05:20:47Z"
+ content="""
+Hi daniele,
+
+I am not completely sure what you mean but I as far as I understand as soon as I set \"wanted\" to anything other than \"default\" the standard groups do not apply at all.
+I can't use vicfg because I use windows and this command hangs ... probably because there is no vi.
+
+However, I can still check the expressions:
+
+    $ git annex group here
+    manual
+    $ git annex wanted here
+    exclude=\"*\" and present
+    $
+
+Have you tried this? Does it work in your case?
+Because the standard preferred contents also contains \"present\" so I assume it would behave the same.
+Is maybe \"present\" broken or the behavior different than expected?
+
+
+"""]]

diff --git a/doc/forum/Reloading_.git__47__config_mid-sync.mdwn b/doc/forum/Reloading_.git__47__config_mid-sync.mdwn
new file mode 100644
index 0000000..0c2ef14
--- /dev/null
+++ b/doc/forum/Reloading_.git__47__config_mid-sync.mdwn
@@ -0,0 +1 @@
+There are some settings (rsync bandwidth settings are my use case) I'd like to reload after assistant starts, possibly mid-sync. Does assistant support SIGHUP, etc? What's the correct way to change bandwidth settings?

Added a comment
diff --git a/doc/bugs/git_annex_still_deleting_content_when_merging/comment_3_f31a73e0e2c43f6a7f158455eadaa56c._comment b/doc/bugs/git_annex_still_deleting_content_when_merging/comment_3_f31a73e0e2c43f6a7f158455eadaa56c._comment
new file mode 100644
index 0000000..04621df
--- /dev/null
+++ b/doc/bugs/git_annex_still_deleting_content_when_merging/comment_3_f31a73e0e2c43f6a7f158455eadaa56c._comment
@@ -0,0 +1,27 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmMLeU-zCzx2mc5pL2XT8a1UNkQwHAHjg8"
+ nickname="daniele"
+ subject="comment 3"
+ date="2014-07-22T02:10:14Z"
+ content="""
+I was unsure as to what git-log command would best describe the problematic commits but in the meantime I did a:
+    
+     git log --graph --decorate=full --full-diff
+
+These are the only three commits of that afternoon (the surrounding history is from completely different hours and very likely unrelated, so it wasn't posted)
+
+    * commit d9eb9e94a3973598a847a5bdab1b65e459c1588a
+    | Author: COMPUTER B
+    | Date:   Thu Jul 17 18:17:16 2014 +0200
+    |  
+    * commit 6fa27f0849227c490ac4d4d62ca86e4befe5121e
+    | Author: COMPUTER A
+    | Date:   Thu Jul 17 18:17:14 2014 +0200
+    |  
+    * commit d25cc793739573057e475c92c8d37ce4ecc7bc9b
+    | Author: COMPUTER A
+    | Date:   Thu Jul 17 18:17:12 2014 +0200
+
+
+It's a straight line (fast forward?), I don't see any merging either. Is this normal? Shouldn't a change in Repo A bring a merge in Repo B (where everything stayed the same) when things are synchronized? I don't fully understand how annex syncs happen so don't mind this question if it's all normal.
+"""]]

Added a comment
diff --git a/doc/bugs/git_annex_still_deleting_content_when_merging/comment_2_bbbcce7fc5f34d733126c42be8ec0a1d._comment b/doc/bugs/git_annex_still_deleting_content_when_merging/comment_2_bbbcce7fc5f34d733126c42be8ec0a1d._comment
new file mode 100644
index 0000000..b874831
--- /dev/null
+++ b/doc/bugs/git_annex_still_deleting_content_when_merging/comment_2_bbbcce7fc5f34d733126c42be8ec0a1d._comment
@@ -0,0 +1,27 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmMLeU-zCzx2mc5pL2XT8a1UNkQwHAHjg8"
+ nickname="daniele"
+ subject="comment 2"
+ date="2014-07-22T01:47:29Z"
+ content="""
+> I am not familiar with the log syntax shown
+
+You mean the \"git log --stat\" part? Which git command would yield the most helpful syntax in this case?
+
+> AFAICS, the problem occurs on machine B. Which machine is the transcript from?
+
+Sorry I forgot to mention it: yes, it's from machine B.
+
+> Is this \"Removing\" message then printed out by another git command?
+
+Sorry I have no clue here. I didn't issue any git command from the terminal (nor did the user on computer A) if that was part of the question. It was all done in automatic.
+
+> Enabling debug logging would probably help a lot, to narrow that down the next time this occurs.
+
+Will do. I'll set 'annex.debug' to true in .git/config. Sadly, computer A is (a laptop) on vacation at the moment (well outside the local network), so I'll have to wait a couple of weeks to get back to debugging this. I'll have the logs with debug enabled when it happens again.
+
+Thanks again for your support and for developing git-annex.
+
+
+
+"""]]

Added a comment
diff --git a/doc/forum/Standard_groups__47__preferred_contents/comment_5_eb47696244931173bddcbeb8d5f78637._comment b/doc/forum/Standard_groups__47__preferred_contents/comment_5_eb47696244931173bddcbeb8d5f78637._comment
new file mode 100644
index 0000000..fa5c47e
--- /dev/null
+++ b/doc/forum/Standard_groups__47__preferred_contents/comment_5_eb47696244931173bddcbeb8d5f78637._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmMLeU-zCzx2mc5pL2XT8a1UNkQwHAHjg8"
+ nickname="daniele"
+ subject="comment 5"
+ date="2014-07-22T00:29:20Z"
+ content="""
+wait, is the group working together with the preferred content?
+
+Usually you set a repository in a group and then you tell annex that particular group has this preferred content expression (which by default is set to 'standard'). So you could add the repo to 'client' group then set the group 'client' to that preferred content expression. If you only want that particular client to have that expression you can play around with \"groupwanted\", or even define your own group I guess.
+
+Use \"git annex vicfg\" to quickly check both \"group\" and \"wanted\" settings together.
+
+"""]]

Added a comment
diff --git a/doc/forum/Standard_groups__47__preferred_contents/comment_4_e0faf9ebd3162e0de860eba0fd28c67c._comment b/doc/forum/Standard_groups__47__preferred_contents/comment_4_e0faf9ebd3162e0de860eba0fd28c67c._comment
new file mode 100644
index 0000000..50acdbc
--- /dev/null
+++ b/doc/forum/Standard_groups__47__preferred_contents/comment_4_e0faf9ebd3162e0de860eba0fd28c67c._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="divB"
+ ip="204.17.143.10"
+ subject="comment 4"
+ date="2014-07-22T00:24:46Z"
+ content="""
+... and for the directories the same:
+
+1.) Create a (sub-)directory 'subdir' with files and sync everything
+2.) On the client: git annex get subdir . The subdirectory is now present, all files under it downloaded.
+3.) On the server create a new file in 'subdir' and git annex add; git annex sync --content
+4.) git annex sync --content on the client
+
+Result: Content of the files is not synced to client 
+"""]]

Added a comment
diff --git a/doc/forum/Standard_groups__47__preferred_contents/comment_3_202a7e2820e0adf079ccd14a7993ad25._comment b/doc/forum/Standard_groups__47__preferred_contents/comment_3_202a7e2820e0adf079ccd14a7993ad25._comment
new file mode 100644
index 0000000..523aa74
--- /dev/null
+++ b/doc/forum/Standard_groups__47__preferred_contents/comment_3_202a7e2820e0adf079ccd14a7993ad25._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="divB"
+ ip="204.17.143.10"
+ subject="comment 3"
+ date="2014-07-22T00:11:34Z"
+ content="""
+Unfortunately the same :(
+
+Testcase:
+1.) Create a file 'file' on the server, git annex add/sync etc.
+2.) On the client: git annex wanted here 'exclude=\"*\" and present'
+3.) On the client: git annex get file . The file is now present on the client
+4.) Change the file on the server, git annex sync
+5.) git annex sync --content on the client
+
+Result: File is dropped again on client
+
+
+
+
+"""]]

devblog
diff --git a/doc/devblog/day_200__one_year_along.mdwn b/doc/devblog/day_200__one_year_along.mdwn
new file mode 100644
index 0000000..6cfab59
--- /dev/null
+++ b/doc/devblog/day_200__one_year_along.mdwn
@@ -0,0 +1,17 @@
+Updated the Debian backport. (Also the git-remote-gcrypt backport.)
+
+Made the assistant install a desktop file to integrate with Konqueror.
+
+Improved `git annex repair`, fixing a bug that could cause it to leave
+broken branch refs and yet think that the repair was successful.
+
+----
+
+A bit surprised to see that now been a full year since I started doing
+development funded by my campaign. Not done yet!
+
+Update on campaign rewards: <https://campaign.joeyh.name/blog/stickers_soon/>
+
+----
+
+Today's work was sponsored by Douglas Butts.

Added a comment
diff --git a/doc/forum/Corrupted_repository__44___can_not_be_repaired/comment_3_baee46af6b2dbaf92be406ab22007a85._comment b/doc/forum/Corrupted_repository__44___can_not_be_repaired/comment_3_baee46af6b2dbaf92be406ab22007a85._comment
new file mode 100644
index 0000000..662e8a2
--- /dev/null
+++ b/doc/forum/Corrupted_repository__44___can_not_be_repaired/comment_3_baee46af6b2dbaf92be406ab22007a85._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="108.236.230.124"
+ subject="comment 3"
+ date="2014-07-21T22:57:32Z"
+ content="""
+There was a bug in the repair code that could leave the repair incomplete like this; I've fixed it.
+
+> I recently moved a bunch of files to another location shortly after I renamed them. The assistant was running (repo: indirect mode) and I guess the assistant was confused
+
+No, I don't think that this was caused by the assistant somehow getting confused. Your git repository was missing objects that had been previously committed to git. The only way this can happen is if your computer lost data. Most commonly due to crashing or being powered off or the drive the repository is in being removed while git is in the middle of committing changes.
+"""]]

Added a comment
diff --git a/doc/tips/megaannex/comment_1_eec701662debd2a78c48243dbcebf59a._comment b/doc/tips/megaannex/comment_1_eec701662debd2a78c48243dbcebf59a._comment
new file mode 100644
index 0000000..8b4b7f8
--- /dev/null
+++ b/doc/tips/megaannex/comment_1_eec701662debd2a78c48243dbcebf59a._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="108.236.230.124"
+ subject="comment 1"
+ date="2014-07-21T19:56:13Z"
+ content="""
+Note that there has apparently been an API break, so this special remote may not work anymore. See: <http://git-annex.branchable.com/forum/MegaAnnex_not_working./>
+"""]]

Added a comment
diff --git a/doc/forum/comprehension_question:_repository_vs._working_copy_in_direct_mode/comment_1_a6b4db0cefa439f72b97089d48dfacbd._comment b/doc/forum/comprehension_question:_repository_vs._working_copy_in_direct_mode/comment_1_a6b4db0cefa439f72b97089d48dfacbd._comment
new file mode 100644
index 0000000..327c057
--- /dev/null
+++ b/doc/forum/comprehension_question:_repository_vs._working_copy_in_direct_mode/comment_1_a6b4db0cefa439f72b97089d48dfacbd._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="108.236.230.124"
+ subject="comment 1"
+ date="2014-07-21T19:54:15Z"
+ content="""
+A git repository is a `.git` directory (or `git.bare` for a bare repository).
+
+A working tree is the directory that contains the `.git` directory.
+
+That is standard git terminology; git-annex does not change this at all really. The only difference is that a file added to git-annex is in both the repository and the working tree at the same time, rather than their being 2 local copies of the file (which would need twice the disk space so not good for large files).
+
+`git annex sync` commits any changes to files in the working tree, and pushes those changes to other remotes. You need to pass --content to also make git-annex upload the files to other remotes. Once a remote has been pushed to, you can run `git annex merge` in it to update its working tree to reflect the pushed changes (`git annex sync` also does that merge).
+
+To automatically sync changes to remotes, you can run the git-annex assistant.
+"""]]

Added a comment
diff --git a/doc/forum/Require_a_local_copy_of_all_new_files_without_explicitly_calling___34__get__34___or___34__sync__34__/comment_1_8adf9c6d2a3ef29120703bfa1b8f9ae2._comment b/doc/forum/Require_a_local_copy_of_all_new_files_without_explicitly_calling___34__get__34___or___34__sync__34__/comment_1_8adf9c6d2a3ef29120703bfa1b8f9ae2._comment
new file mode 100644
index 0000000..12aef24
--- /dev/null
+++ b/doc/forum/Require_a_local_copy_of_all_new_files_without_explicitly_calling___34__get__34___or___34__sync__34__/comment_1_8adf9c6d2a3ef29120703bfa1b8f9ae2._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="108.236.230.124"
+ subject="comment 1"
+ date="2014-07-21T19:46:44Z"
+ content="""
+This is generally handled by using either `git annex sync --content`, which will make the laptops upload new files to the server before they push the git repository to it, or by using the git-annex assistant (on the laptops or perhaps on the server) to automatically copy files. Either way, you configure [[preferred_content]] settings to control which repositories want which  files.
+"""]]

remove download notification screenshot, it will not look like that in kde
diff --git a/doc/tips/file_manager_integration.mdwn b/doc/tips/file_manager_integration.mdwn
index 0b3fd52..b81d758 100644
--- a/doc/tips/file_manager_integration.mdwn
+++ b/doc/tips/file_manager_integration.mdwn
@@ -20,8 +20,6 @@ Even more recent git-annex comes with built-in integration with Konqueror.
 
 [[!img assistant/konquerormenu.png]]
 
-[[!img assistant/downloadnotification.png]]
-
 This is set up by git-annex creating a 
 `~/.kde/share/kde4/services/ServiceMenus/git-annex.desktop file.
 

split
diff --git a/doc/tips/file_manager_integration.mdwn b/doc/tips/file_manager_integration.mdwn
index 67a91cd..0b3fd52 100644
--- a/doc/tips/file_manager_integration.mdwn
+++ b/doc/tips/file_manager_integration.mdwn
@@ -3,20 +3,26 @@ annexed files to get or drop.
 
 [[!toc]]
 
-## GNOME (nautilus) and KDE (Dolphin/Konqueror)
+## GNOME (nautilus)
 
-Recent git-annex comes with built-in integration for the file managers of
-these desktop environments. These let you pick git-annex get and git-annex
-drop actions from the context menus when right-clicking on a file.
+Recent git-annex comes with built-in integration for Nautilus.
 
 [[!img assistant/nautilusmenu.png]]
-[[!img assistant/konquerormenu.png]]
 
 [[!img assistant/downloadnotification.png]]
 
-This is set up by making simple scripts in
+This is set up by git-annex creating simple scripts in
 `~/.local/share/nautilus/scripts`, with names like "git-annex get"
-and by making a 
+
+## KDE (Dolphin/Konqueror)
+
+Even more recent git-annex comes with built-in integration with Konqueror.
+
+[[!img assistant/konquerormenu.png]]
+
+[[!img assistant/downloadnotification.png]]
+
+This is set up by git-annex creating a 
 `~/.kde/share/kde4/services/ServiceMenus/git-annex.desktop file.
 
 ## XFCE (Thunar)

add konqueror screenshot
diff --git a/doc/assistant/konquerormenu.png b/doc/assistant/konquerormenu.png
new file mode 100644
index 0000000..747bcdd
Binary files /dev/null and b/doc/assistant/konquerormenu.png differ
diff --git a/doc/tips/file_manager_integration.mdwn b/doc/tips/file_manager_integration.mdwn
index 9b02ffb..67a91cd 100644
--- a/doc/tips/file_manager_integration.mdwn
+++ b/doc/tips/file_manager_integration.mdwn
@@ -10,6 +10,7 @@ these desktop environments. These let you pick git-annex get and git-annex
 drop actions from the context menus when right-clicking on a file.
 
 [[!img assistant/nautilusmenu.png]]
+[[!img assistant/konquerormenu.png]]
 
 [[!img assistant/downloadnotification.png]]
 

webapp: Automatically install Konqueror integration scripts to get and drop files.
Based on the example from the tip, but modified to cd into the repo before
running git-annex, since konqueror does not. Also, at least on my system,
the directory is ~/.kde, not ~/.kde4. (konqueror 4.12.4)
This commit was sponsored by Jürgen Peters.
diff --git a/Assistant/Install.hs b/Assistant/Install.hs
index 84dc779..1a7799b 100644
--- a/Assistant/Install.hs
+++ b/Assistant/Install.hs
@@ -22,6 +22,7 @@ import Utility.SshConfig
 import Utility.OSX
 #else
 import Utility.FreeDesktop
+import Utility.UserInfo
 import Assistant.Install.Menu
 #endif
 
@@ -36,13 +37,13 @@ standaloneAppBase = getEnv "GIT_ANNEX_APP_BASE"
  - Note that this is done every time it's started, so if the user moves
  - it around, the paths this sets up won't break.
  -
- - Nautilus hook script installation is done even for packaged apps,
- - since it has to go into the user's home directory.
+ - File manager hook script installation is done even for
+ - packaged apps, since it has to go into the user's home directory.
  -}
 ensureInstalled :: IO ()
 ensureInstalled = go =<< standaloneAppBase
   where
-	go Nothing = installNautilus "git-annex"
+	go Nothing = installFileManagerHooks "git-annex"
 	go (Just base) = do
 		let program = base </> "git-annex"
 		programfile <- programFile
@@ -78,7 +79,7 @@ ensureInstalled = go =<< standaloneAppBase
 			, runshell "\"$@\""
 			]
 
-		installNautilus program
+		installFileManagerHooks program
 
 installWrapper :: FilePath -> String -> IO ()
 installWrapper file content = do
@@ -88,15 +89,23 @@ installWrapper file content = do
 		viaTmp writeFile file content
 		modifyFileMode file $ addModes [ownerExecuteMode]
 
-installNautilus :: FilePath -> IO ()
+installFileManagerHooks :: FilePath -> IO ()
 #ifdef linux_HOST_OS
-installNautilus program = do
-	scriptdir <- (\d -> d </> "nautilus" </> "scripts") <$> userDataDir
-	createDirectoryIfMissing True scriptdir
-	genscript scriptdir "get"
-	genscript scriptdir "drop"
+installFileManagerHooks program = do
+	-- Gnome
+	nautilusScriptdir <- (\d -> d </> "nautilus" </> "scripts") <$> userDataDir
+	createDirectoryIfMissing True nautilusScriptdir
+	genNautilusScript nautilusScriptdir "get"
+	genNautilusScript nautilusScriptdir "drop"
+
+	-- KDE
+	home <- myHomeDir
+	let kdeServiceMenusdir = home </> ".kde" </> "share" </> "kde4" </> "services" </> "ServiceMenus"
+	createDirectoryIfMissing True kdeServiceMenusdir
+	writeFile (kdeServiceMenusdir </> "git-annex.desktop")
+		(kdeDesktopFile ["get", "drop"])
   where
-	genscript scriptdir action =
+	genNautilusScript scriptdir action =
 		installscript (scriptdir </> scriptname action) $ unlines
 			[ shebang_local
 			, autoaddedcomment
@@ -108,9 +117,33 @@ installNautilus program = do
 		modifyFileMode f $ addModes [ownerExecuteMode]
 	safetoinstallscript f = catchDefaultIO True $
 		elem autoaddedcomment . lines <$> readFileStrict f
-	autoaddedcomment = "# Automatically added by git-annex, do not edit. (To disable, chmod 600 this file.)"
+	autoaddedcomment = "# " ++ autoaddedmsg ++ " (To disable, chmod 600 this file.)"
+	autoaddedmsg = "Automatically added by git-annex, do not edit."
+
+	kdeDesktopFile actions = unlines $ concat $
+		kdeDesktopHeader actions : map kdeDesktopAction actions
+	kdeDesktopHeader actions =
+		[ "# " ++ autoaddedmsg
+		, "[Desktop Entry]"
+		, "Type=Service"
+		, "ServiceTypes=all/allfiles"
+		, "MimeType=all/all;"
+		, "Actions=" ++ intercalate ";" (map kdeDesktopSection actions)
+		, "X-KDE-Priority=TopLevel"
+		, "X-KDE-Submenu=Git-Annex"
+		, "X-KDE-Icon=git-annex"
+		, "X-KDE-ServiceTypes=KonqPopupMenu/Plugin"
+		]
+	kdeDesktopSection command = "GitAnnex" ++ command
+	kdeDesktopAction command = 
+		[ ""
+		, "[Desktop Action " ++ kdeDesktopSection command ++ "]"
+		, "Name=" ++ command
+		, "Icon=git-annex"
+		, "Exec=sh -c 'cd \"$(dirname '%U')\" && git-annex " ++ command ++ " --notify-start --notify-finish -- %U'"
+		]
 #else
-installNautilus _ = noop
+installFileManagerHooks _ = noop
 #endif
 
 {- Returns a cleaned up environment that lacks settings used to make the
diff --git a/debian/changelog b/debian/changelog
index 81d222d..964161d 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+git-annex (5.20140718) UNRELEASED; urgency=medium
+
+  * webapp: Automatically install Konqueror integration scripts
+    to get and drop files.
+
+ -- Joey Hess <joeyh@debian.org>  Mon, 21 Jul 2014 14:41:26 -0400
+
 git-annex (5.20140717) unstable; urgency=high
 
   * Fix minor FD leak in journal code. Closes: #754608
diff --git a/doc/tips/file_manager_integration.mdwn b/doc/tips/file_manager_integration.mdwn
index 6c6ac64..9b02ffb 100644
--- a/doc/tips/file_manager_integration.mdwn
+++ b/doc/tips/file_manager_integration.mdwn
@@ -3,10 +3,11 @@ annexed files to get or drop.
 
 [[!toc]]
 
-## GNOME (nautilus)
+## GNOME (nautilus) and KDE (Dolphin/Konqueror)
 
-Recent git-annex comes with built-in nautilus integration. Just pick the
-action from the menu.
+Recent git-annex comes with built-in integration for the file managers of
+these desktop environments. These let you pick git-annex get and git-annex
+drop actions from the context menus when right-clicking on a file.
 
 [[!img assistant/nautilusmenu.png]]
 
@@ -14,30 +15,8 @@ action from the menu.
 
 This is set up by making simple scripts in
 `~/.local/share/nautilus/scripts`, with names like "git-annex get"
-
-## KDE (Dolphin/Konqueror)
-
-Create a file `~/.kde4/share/kde4/services/ServiceMenus/git-annex.desktop` with the following contents:
-
-        [Desktop Entry]
-        Type=Service
-        ServiceTypes=all/allfiles
-        MimeType=all/all;
-        Actions=GitAnnexGet;GitAnnexDrop;
-        X-KDE-Priority=TopLevel
-        X-KDE-Submenu=Git-Annex
-        X-KDE-Icon=git-annex
-        X-KDE-ServiceTypes=KonqPopupMenu/Plugin
-
-        [Desktop Action GitAnnexGet]
-        Name=Get
-        Icon=git-annex
-        Exec=git-annex get --notify-start --notify-finish -- %U
-
-        [Desktop Action GitAnnexDrop]
-        Name=Drop
-        Icon=git-annex
-        Exec=git-annex drop --notify-start --notify-finish -- %U
+and by making a 
+`~/.kde/share/kde4/services/ServiceMenus/git-annex.desktop file.
 
 ## XFCE (Thunar)
 

Added a comment: good point
diff --git a/doc/todo/wishlist:_--maxdepth_option_for_git_annex_find/comment_4_c766c1465407324fc933db78be325b33._comment b/doc/todo/wishlist:_--maxdepth_option_for_git_annex_find/comment_4_c766c1465407324fc933db78be325b33._comment
new file mode 100644
index 0000000..6025101
--- /dev/null
+++ b/doc/todo/wishlist:_--maxdepth_option_for_git_annex_find/comment_4_c766c1465407324fc933db78be325b33._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlScsufvQF7s8TVTwPd-h_QiP5Hn_i-hrs"
+ nickname="Jason"
+ subject="good point"
+ date="2014-07-21T19:22:30Z"
+ content="""
+You make another good point `--maxdepth` is vague in this context...
+I guess if we were to decide to come up with a summary option, it will have be named something else, like `--summary-depth`, where the default would be to represent all files of whatever depth, and specifying the option would take the output that would otherwise get from `git annex find <opts>`, truncate the paths to a certain depth, and then make a set thereof (to remove the many dups), that way any directory that had any files that would have been output by `git annex find <opts>`, that would also be at or above a certain depth, would be listed.
+
+I think if I get a chance I'll try to implement something like this.
+
+"""]]

Added a comment
diff --git a/doc/todo/wishlist:_--maxdepth_option_for_git_annex_find/comment_3_f3eadd6241f5cc2886515b2826dc5cf9._comment b/doc/todo/wishlist:_--maxdepth_option_for_git_annex_find/comment_3_f3eadd6241f5cc2886515b2826dc5cf9._comment
new file mode 100644
index 0000000..8da436e
--- /dev/null
+++ b/doc/todo/wishlist:_--maxdepth_option_for_git_annex_find/comment_3_f3eadd6241f5cc2886515b2826dc5cf9._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="108.236.230.124"
+ subject="comment 3"
+ date="2014-07-21T18:40:00Z"
+ content="""
+I think that --maxdepth has a well-defined meaning and this summary option would need to be named something else.
+
+I don't object to the idea of implementing it. However, I don't know that it would be very easy to implement either.
+"""]]

Added a comment
diff --git a/doc/todo/wishlist:_--maxdepth_option_for_git_annex_find/comment_2_da30a066c4de465fe172ad01057e2380._comment b/doc/todo/wishlist:_--maxdepth_option_for_git_annex_find/comment_2_da30a066c4de465fe172ad01057e2380._comment
new file mode 100644
index 0000000..944f360
--- /dev/null
+++ b/doc/todo/wishlist:_--maxdepth_option_for_git_annex_find/comment_2_da30a066c4de465fe172ad01057e2380._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlScsufvQF7s8TVTwPd-h_QiP5Hn_i-hrs"
+ nickname="Jason"
+ subject="comment 2"
+ date="2014-07-21T18:37:19Z"
+ content="""
+I see your point, `git ls-files` may still have to walk the whole tree, precluding a speed advantage.
+But I guess the point of what I was saying was more that a way summarize from a high level what is here and what is not would be nice.
+I certainly understand if this is not something you see as worthwhile, but if someone were inclined to write a patch (if ever I find the time) that would add a `--maxdepth` option that would merely summarize the results of `git annex find` would it be something you would be inclined to include in the main repo (providing, of course, that you find the behavior sensible)?
+"""]]

Added a comment
diff --git a/doc/bugs/git_annex_still_deleting_content_when_merging/comment_1_cb51e25c5e1656dcbb73b3ff680341f0._comment b/doc/bugs/git_annex_still_deleting_content_when_merging/comment_1_cb51e25c5e1656dcbb73b3ff680341f0._comment
new file mode 100644
index 0000000..76db9bc
--- /dev/null
+++ b/doc/bugs/git_annex_still_deleting_content_when_merging/comment_1_cb51e25c5e1656dcbb73b3ff680341f0._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="108.236.230.124"
+ subject="comment 1"
+ date="2014-07-21T17:37:22Z"
+ content="""
+Well, this is definitely a different bug or issue than the \"ugly bug\". In particular, it only affects a single file. Also, based on the commits, this may not be occuring in a merge commit at all (although I am not sure; I am not familiar with the log syntax shown).
+
+AFAICS, the problem occurs on machine B. Which machine is the transcript from?
+
+The \"Removing shared.skg\" is a good clue. This seems to be printed by `git`, in merge-recursive.c's `process_entry`. What is puzzling to me is that it's printed after the \"Automatic merge went well; stopped before committing as requested\", which  AFAICS is printed out by git last thing. Is this \"Removing\" message then printed out by another git command?
+
+Enabling debug logging would probably help a lot, to narrow that down the next time this occurs.
+"""]]

Added a comment
diff --git a/doc/todo/wishlist:_--maxdepth_option_for_git_annex_find/comment_1_c355878ac49bbb23a4cf82fe685da9ee._comment b/doc/todo/wishlist:_--maxdepth_option_for_git_annex_find/comment_1_c355878ac49bbb23a4cf82fe685da9ee._comment
new file mode 100644
index 0000000..73d4cba
--- /dev/null
+++ b/doc/todo/wishlist:_--maxdepth_option_for_git_annex_find/comment_1_c355878ac49bbb23a4cf82fe685da9ee._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="108.236.230.124"
+ subject="comment 1"
+ date="2014-07-21T17:28:53Z"
+ content="""
+`find --maxdepth` is a nice optimisation because it can short-circuit when it gets deep in the tree. However, `git annex find` is built on top of `git ls-files --cached`, which has no equivilant way to short-circuit. I am not sure if the format of the index makes it practical for it to get a --maxdepth option (it may need to traverse the whole index, or might be able to short-circuit).
+
+I don't see any point in adding a --matdepth to git-annex if it doesn't actually make it any faster, so getting such a thing into `git ls-files` would be the first step. So, suggest filing a feature request on git.
+"""]]

Added a comment
diff --git a/doc/forum/Performance_implications_of_triply_nested_objects_directory/comment_4_4e44289e6913797844e103f9cdf4c5a2._comment b/doc/forum/Performance_implications_of_triply_nested_objects_directory/comment_4_4e44289e6913797844e103f9cdf4c5a2._comment
new file mode 100644
index 0000000..ea0b82f
--- /dev/null
+++ b/doc/forum/Performance_implications_of_triply_nested_objects_directory/comment_4_4e44289e6913797844e103f9cdf4c5a2._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="108.236.230.124"
+ subject="comment 4"
+ date="2014-07-21T17:19:42Z"
+ content="""
+<https://microca.st/clacke/note/kKMqYM4DQtOPzMe065oHiA> suggests using -I 512 -O inline_data (\"bignode\")
+"""]]

diff --git a/doc/forum/Require_a_local_copy_of_all_new_files_without_explicitly_calling___34__get__34___or___34__sync__34__.mdwn b/doc/forum/Require_a_local_copy_of_all_new_files_without_explicitly_calling___34__get__34___or___34__sync__34__.mdwn
new file mode 100644
index 0000000..9c19b9b
--- /dev/null
+++ b/doc/forum/Require_a_local_copy_of_all_new_files_without_explicitly_calling___34__get__34___or___34__sync__34__.mdwn
@@ -0,0 +1,9 @@
+Greetings.  Here is my desired usage scenario:
+
+I have setup a server and three laptops which I am syncing over ssh. Each laptop may access the server, but because different people are using each of the laptops, they may not sync between laptops for security/privacy.
+
+Each of the laptops will be adding content to the repository, and each of the laptops will be using the new content that the others have added.
+
+Currently, in order to make all content available to all users, I'm having to ssh into the server and use `git annex get .` every time new content is added from one of the laptops, which is a pain. Is there a way to require a local copy of all content in a given repository so that is pulled/pushed automatically? I would like for each laptop to be able to add new content to their copies of the repository and sync with the server, after which each other laptop can access the content through the server.
+
+Thanks!

poll vote (/sdcard/annex)
diff --git a/doc/design/assistant/polls/Android_default_directory.mdwn b/doc/design/assistant/polls/Android_default_directory.mdwn
index ee41fac..52bd892 100644
--- a/doc/design/assistant/polls/Android_default_directory.mdwn
+++ b/doc/design/assistant/polls/Android_default_directory.mdwn
@@ -4,4 +4,4 @@ Same as the desktop webapp, users will be able to enter a directory they
 want the first time they run it, but to save typing on android, anything
 that gets enough votes will be included in a list of choices as well.
 
-[[!poll open=yes expandable=yes 67 "/sdcard/annex" 6 "Whole /sdcard" 7 "DCIM directory (photos and videos only)" 2 "Same as for regular git-annex. ~/annex/"]]
+[[!poll open=yes expandable=yes 68 "/sdcard/annex" 6 "Whole /sdcard" 7 "DCIM directory (photos and videos only)" 2 "Same as for regular git-annex. ~/annex/"]]

diff --git a/doc/todo/utilising_the_mklink_command_on_windows_to_utilise_symlinks_and_therefore_indirect_mode_on_windows.mdwn b/doc/todo/utilising_the_mklink_command_on_windows_to_utilise_symlinks_and_therefore_indirect_mode_on_windows.mdwn
new file mode 100644
index 0000000..263035f
--- /dev/null
+++ b/doc/todo/utilising_the_mklink_command_on_windows_to_utilise_symlinks_and_therefore_indirect_mode_on_windows.mdwn
@@ -0,0 +1,7 @@
+It seems like it is possible to achieve this now on later versions of Windows (7 and above).
+
+The mklink tool creates a symlink that works on windows.
+
+There would be some work required so that a linux symlink and a windows symlink are considered the same, a user has recommend 'git update-index --assume-unchanged' for this.
+
+There is a good write up of someone using this approach on vanilla git here: http://stackoverflow.com/questions/5917249/git-symlinks-in-windows

Added a comment
diff --git a/doc/forum/Archive_USB_drive_not_working_as_documented/comment_2_3541fdd31d398a494a8fa452ac2c277f._comment b/doc/forum/Archive_USB_drive_not_working_as_documented/comment_2_3541fdd31d398a494a8fa452ac2c277f._comment
new file mode 100644
index 0000000..1ec09b0
--- /dev/null
+++ b/doc/forum/Archive_USB_drive_not_working_as_documented/comment_2_3541fdd31d398a494a8fa452ac2c277f._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnwSZggfi3YE0EAuxAB9jT6pMcB73V8ae4"
+ nickname="Marshal"
+ subject="comment 2"
+ date="2014-07-20T01:33:25Z"
+ content="""
+Thank you Mesar! 
+
+I think I'm beginning to understand. Indeed, the files were there on the usbdrive repo (in .git/annex/objects). No need to sync or merge. I was able to drop a file from the laptop repo and get it back from the usbdrive.
+
+What is a bit unnerving, is that the symlinks are not present on the usbdrive, so it looks empty except for the .git directory.
+
+Thanks so much for clearing this up. More to explore... 
+"""]]

Added a comment: comment 1
diff --git a/doc/forum/Archive_USB_drive_not_working_as_documented/comment_1_59de1e101e5e427abb1df3a71c6f1b04._comment b/doc/forum/Archive_USB_drive_not_working_as_documented/comment_1_59de1e101e5e427abb1df3a71c6f1b04._comment
new file mode 100644
index 0000000..e7f5eea
--- /dev/null
+++ b/doc/forum/Archive_USB_drive_not_working_as_documented/comment_1_59de1e101e5e427abb1df3a71c6f1b04._comment
@@ -0,0 +1,23 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmcS2gG2R_AIiBBOsWuxGf1yEn_l797jjU"
+ nickname="Mesar"
+ subject="comment 1"
+ date="2014-07-20T00:50:15Z"
+ content="""
+
+When you did:
+
+    marshal@home[~/annex]> git-annex copy --auto --to usbdrive
+
+this copies the file content (see .git/annex/objects/*), and updates the metadata in both repos.
+The reason why you are not seeing the files on the usb is because the metadata has not been merged into your master branch.
+This is verified by the output of:
+
+    marshal@home[/media/marshal/Sony USB/annex]> git-annex sync laptop
+
+To verify that you indeed do have the files and their content, don't do the above sync, but instead do:
+
+    marshal@home[/media/marshal/Sony USB/annex]> git annex merge
+
+the local metadata in the sync/git-annex branch will be merged in, and the local directory will be populated with the new symlinks to the content which you already have in the /media/marshal/Sony USB/annex/.git/annex/objects/*
+"""]]