Recent changes to this wiki:

auto-detect xbmc library location, clarify
diff --git a/doc/tips/dumb_metadata_extraction_from_xbmc/git-annex-xbmc-playcount.pl b/doc/tips/dumb_metadata_extraction_from_xbmc/git-annex-xbmc-playcount.pl
index 76ad336..3e2bd9b 100644
--- a/doc/tips/dumb_metadata_extraction_from_xbmc/git-annex-xbmc-playcount.pl
+++ b/doc/tips/dumb_metadata_extraction_from_xbmc/git-annex-xbmc-playcount.pl
@@ -1,7 +1,24 @@
 #! /usr/bin/perl -w
 
-my $dbpath="/home/video/.xbmc/userdata/Database/MyVideos75.db";
+# we want to operate on relative links, so set this to the common prefix
+# to the git annex repo
 my $prefix="/home/media/video/";
+# this is the directory for the XBMC database
+my $path = '/home/video/.xbmc/userdata/Database/';
+
+# no user-serviceable parts below
+
+# list videos database, find the latest one
+# modified version of
+# http://stackoverflow.com/questions/4651092/getting-the-list-of-files-sorted-by-modification-date-in-perl
+opendir my($dirh), $path or die "can't opendir $path: $!";
+my @flist = sort {  -M $a <=> -M $b } # Sort by modification time
+            map  { "$path/$_" } # We need full paths for sorting
+            grep { /^MyVideos.*\.db$/ }
+            readdir $dirh;
+closedir $dirh;
+
+my $dbpath=$flist[0];
 
 my @lines = `echo 'SELECT playCount, path.strPath, files.strFileName FROM movie JOIN files ON files.idFile=movie.idFile JOIN path ON path.idPath=files.idPath;' | sqlite3 $dbpath`;
 for (@lines) {
@@ -11,7 +28,6 @@ for (@lines) {
     if ($count !~ /[0-9]/) {
         $count = 0;
     }
-    $dir =~ s/$prefix//;
     if ($file =~ s#stack://##) {
         for (split /,/, $file) {
             s/$prefix//;
@@ -22,6 +38,7 @@ for (@lines) {
         }
     }
     else {
+        $dir =~ s/$prefix//;
         my @cmd = (qw(git annex metadata --set), "playCount=$count", "$dir$file");
         system(@cmd);
     }

Added a comment
diff --git a/doc/tips/file_manager_integration/comment_3_e7096737268cf66fce2709e9e4937f51._comment b/doc/tips/file_manager_integration/comment_3_e7096737268cf66fce2709e9e4937f51._comment
new file mode 100644
index 0000000..1c3c7ee
--- /dev/null
+++ b/doc/tips/file_manager_integration/comment_3_e7096737268cf66fce2709e9e4937f51._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://id.koumbit.net/anarcat"
+ ip="72.0.72.144"
+ subject="comment 3"
+ date="2014-10-01T02:02:39Z"
+ content="""
+for some reason this doesn't work in gnome2. i had to add the shortcuts in /usr/share/nautilus-scripts (iirc). --[[anarcat]]
+"""]]

Added a comment
diff --git a/doc/tips/using_the_web_as_a_special_remote/comment_9_b420b1f320d620a9909cce5086c549bf._comment b/doc/tips/using_the_web_as_a_special_remote/comment_9_b420b1f320d620a9909cce5086c549bf._comment
new file mode 100644
index 0000000..d6b194d
--- /dev/null
+++ b/doc/tips/using_the_web_as_a_special_remote/comment_9_b420b1f320d620a9909cce5086c549bf._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.55"
+ subject="comment 9"
+ date="2014-09-30T18:09:04Z"
+ content="""
+For urls using http basic auth, you can use the standard url form, http://username:password@example.org/url/ , which should work with `git annex addurl`. The url, including the password, will be stored in the git-annex branch though. If you want to protect the password from being exposed to anyone who gets a clone of the repository, just download manually, and then `git annex add` the file.
+"""]]

diff --git a/doc/forum/This_account_is_restricted_by_rssh._Allowed_commands:_scp_rsync__160__.mdwn b/doc/forum/This_account_is_restricted_by_rssh._Allowed_commands:_scp_rsync__160__.mdwn
new file mode 100644
index 0000000..932c78a
--- /dev/null
+++ b/doc/forum/This_account_is_restricted_by_rssh._Allowed_commands:_scp_rsync__160__.mdwn
@@ -0,0 +1,5 @@
+Hello,
+
+I'm using the git-annex assistant (in Mac Mavericks) and I'm trying to create a new remote rsync repo, I have the details and everything but I can't do it over ssh, I need the call to use rsync otherwise I get: **This account is restricted by rssh. Allowed commands: scp rsync ** . Can this be changed manually? How can I create a remote rsync repo?
+
+Thanks

Added a comment: HTTP Authentication?
diff --git a/doc/tips/using_the_web_as_a_special_remote/comment_8_3f32d536f51d5e9908953caf5736b0a0._comment b/doc/tips/using_the_web_as_a_special_remote/comment_8_3f32d536f51d5e9908953caf5736b0a0._comment
new file mode 100644
index 0000000..c340350
--- /dev/null
+++ b/doc/tips/using_the_web_as_a_special_remote/comment_8_3f32d536f51d5e9908953caf5736b0a0._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnvr2UPmp7ABeH0yI8KGAHCqFhl91Ju4Tc"
+ nickname="Calvin"
+ subject="HTTP Authentication?"
+ date="2014-09-29T21:37:44Z"
+ content="""
+Hi!
+
+I have a somewhat interesting use case. My course notes require HTTP authentication. This is possible with wget, but is there any way to make git annex do it?
+
+[wget authentication stuff!](http://stackoverflow.com/questions/4272770/wget-with-authentication)
+
+It would be nice to have the user and pass encrypted with GPG too. This might be a strange use case, but I can see other people wanting to do something like this in the future.
+
+Thanks!
+"""]]

Added a comment: ls symlink workaround; idea for a solution
diff --git a/doc/forum/git_annex_ls___47___metadata_in_git_annex_whereis/comment_3_24c54ed70220974b98700bf717d1e770._comment b/doc/forum/git_annex_ls___47___metadata_in_git_annex_whereis/comment_3_24c54ed70220974b98700bf717d1e770._comment
new file mode 100644
index 0000000..67ff59d
--- /dev/null
+++ b/doc/forum/git_annex_ls___47___metadata_in_git_annex_whereis/comment_3_24c54ed70220974b98700bf717d1e770._comment
@@ -0,0 +1,29 @@
+[[!comment format=mdwn
+ username="sudoman"
+ ip="216.15.125.93"
+ subject="ls symlink workaround; idea for a solution"
+ date="2014-09-29T18:58:23Z"
+ content="""
+as a workaround, you could make a bash alias for `ls -l` -> `ls -lL`. the problem with this is that links to other links are fully dereferenced.
+
+what looks like this in a non-git-annex directory with `ls -lh`:
+
+    total 3.8M
+    -rw-r--r-- 1 sudoman sudoman 3.8M Sep 29 13:56 42x3551_02.pdf
+    lrwxrwxrwx 1 sudoman sudoman   14 Sep 29 14:00 tmp -> 42x3551_02.pdf
+
+looks like this in an indirect git annex repo with `ls -lhL`:
+
+    total 7.5M
+    -r--r--r-- 1 sudoman sudoman 3.8M Sep 29 13:56 42x3551_02.pdf
+    -r--r--r-- 1 sudoman sudoman 3.8M Sep 29 13:56 tmp
+
+
+the ls alias is a bit hackish, but for some purposes it's an improvement.
+
+rsync may work as desired when using a command like `rsync -l --safe-links` (haven't tried it. users might want to experiment by adding `--exclude` to that command.)
+
+
+a potential solution for ls (and cp) could be the inclusion of a patched version under `git annex util ls`. writing shim programs using `LD_PRELOAD` instead of patching may drastically reduce the amount of code needing future security updates.
+
+"""]]

Added a comment
diff --git a/doc/bugs/runs_of_of_memory_adding_2_million_files/comment_9_27a31463bcf28b5c684bb483b46a3baf._comment b/doc/bugs/runs_of_of_memory_adding_2_million_files/comment_9_27a31463bcf28b5c684bb483b46a3baf._comment
new file mode 100644
index 0000000..fe421a4
--- /dev/null
+++ b/doc/bugs/runs_of_of_memory_adding_2_million_files/comment_9_27a31463bcf28b5c684bb483b46a3baf._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmyYyXrtGKiR3Pu2OjdVsETXf4ePmECW54"
+ nickname="Andrey"
+ subject="comment 9"
+ date="2014-09-29T10:48:36Z"
+ content="""
+Joeyh, in what version it was fixed? I really need it for Ubuntu 14.04
+"""]]

Added a comment
diff --git a/doc/bugs/S3_upload_not_using_multipart/comment_8_4d9242cde0d2348452438659a8aa8d6d._comment b/doc/bugs/S3_upload_not_using_multipart/comment_8_4d9242cde0d2348452438659a8aa8d6d._comment
new file mode 100644
index 0000000..a427c50
--- /dev/null
+++ b/doc/bugs/S3_upload_not_using_multipart/comment_8_4d9242cde0d2348452438659a8aa8d6d._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawl9sYlePmv1xK-VvjBdN-5doOa_Xw-jH4U"
+ nickname="Richard"
+ subject="comment 8"
+ date="2014-09-29T08:09:33Z"
+ content="""
+PS: Chunking spams the S3 remote with individual objects whereas multipart uploads do not. Just something to keep in mind in case you turn on chunking for S3.
+"""]]

Added a comment
diff --git a/doc/bugs/S3_upload_not_using_multipart/comment_7_f620888512cd78628f82ec9e5eed4ad1._comment b/doc/bugs/S3_upload_not_using_multipart/comment_7_f620888512cd78628f82ec9e5eed4ad1._comment
new file mode 100644
index 0000000..ec47aa2
--- /dev/null
+++ b/doc/bugs/S3_upload_not_using_multipart/comment_7_f620888512cd78628f82ec9e5eed4ad1._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawl9sYlePmv1xK-VvjBdN-5doOa_Xw-jH4U"
+ nickname="Richard"
+ subject="comment 7"
+ date="2014-09-29T08:07:55Z"
+ content="""
+As I found the latest comment confusing, here's the full quote:
+
+    Depending on the size of the data you are uploading, Amazon S3 offers the following options:
+    
+    Upload objects in a single operation—With a single PUT operation you can upload objects up to 5 GB in size.
+    
+    Upload objects in parts—Using the Multipart upload API you can upload large objects, up to 5 TB.
+    
+    The Multipart Upload API is designed to improve the upload experience for larger objects. You can upload objects in parts.
+    These object parts can be uploaded independently, in any order, and in parallel.
+    You can use a Multipart Upload for objects from 5 MB to 5 TB in size.
+    
+    We encourage Amazon S3 customers to use Multipart Upload for objects greater than 100 MB.
+
+"""]]

Added a comment
diff --git a/doc/forum/XMPP_problem_behind_router/comment_3_7fa8fe8cb92993c935ba2dbfb2aef728._comment b/doc/forum/XMPP_problem_behind_router/comment_3_7fa8fe8cb92993c935ba2dbfb2aef728._comment
new file mode 100644
index 0000000..d8ee076
--- /dev/null
+++ b/doc/forum/XMPP_problem_behind_router/comment_3_7fa8fe8cb92993c935ba2dbfb2aef728._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://me.yahoo.com/a/wbh0dY54mcPwTpeOweuPQ8JiZrH3hg--#9b726"
+ nickname="Joe"
+ subject="comment 3"
+ date="2014-09-29T01:38:14Z"
+ content="""
+Thanks, that seemed to be the problem!  My router's dnsmasq had the 'filterwin2k' option set, which apparently [blocks queries for SRV records](http://wiki.openwrt.org/doc/howto/dhcp.dnsmasq#sip-phones.and.dnsmasq).  This may be fixed in newer OpenWRT versions, but my device is no longer supported.
+"""]]

devblog
diff --git a/doc/devblog/day_222_preparing_for_debian_release.mdwn b/doc/devblog/day_222_preparing_for_debian_release.mdwn
new file mode 100644
index 0000000..62acc02
--- /dev/null
+++ b/doc/devblog/day_222_preparing_for_debian_release.mdwn
@@ -0,0 +1,12 @@
+Made two releases of git-annex, yesterday and today, which turned out to
+contain only Debian changes. So no need for other users to upgrade.
+
+This included fixing building on mips, and arm architectures.
+The mips build was running out of memory, and I was able to work around
+that. Then the arm builds broke today, because of a recent change to the
+version of llvm that has completely trashed ghc. Luckily, I was able
+to work around that too.
+
+Hopefully that will get last week's security fix into Debian testing,
+and otherwise have git-annex in Debian in good shape for the upcoming
+freeze.

add news item for git-annex 5.20140927
diff --git a/doc/news/version_5.20140817.mdwn b/doc/news/version_5.20140817.mdwn
deleted file mode 100644
index 82e44eb..0000000
--- a/doc/news/version_5.20140817.mdwn
+++ /dev/null
@@ -1,42 +0,0 @@
-git-annex 5.20140817 released with [[!toggle text="these changes"]]
-[[!toggleable text="""
-   * New chunk= option to chunk files stored in special remotes.
-     Supported by: directory, S3, webdav, gcrypt, rsync, and all external
-     and hook special remotes.
-   * Partially transferred files are automatically resumed when using
-     chunked remotes!
-   * The old chunksize= option is deprecated. Do not use for new remotes.
-   * Legacy code for directory remotes using the old chunksize= option
-     will keep them working, but more slowly than before.
-   * webapp: Automatically install Konqueror integration scripts
-     to get and drop files.
-   * repair: Removing bad objects could leave fsck finding no more
-     unreachable objects, but some branches no longer accessible.
-     Fix this, including support for fixing up repositories that
-     were incompletely repaired before.
-   * Fix cost calculation for non-encrypted remotes.
-   * Display exception message when a transfer fails due to an exception.
-   * WebDAV: Sped up by avoiding making multiple http connections
-     when storing a file.
-   * WebDAV: Avoid buffering whole file in memory when uploading and
-     downloading.
-   * WebDAV: Dropped support for DAV before 1.0.
-   * testremote: New command to test uploads/downloads to a remote.
-   * Dropping an object from a bup special remote now deletes the git branch
-     for the object, although of course the object's content cannot be deleted
-     due to the nature of bup.
-   * unlock: Better error handling; continue past files that are not available
-     or cannot be unlocked due to disk space, and try all specified files.
-   * Windows: Now uses actual inode equivilants in new direct mode
-     repositories, for safer detection of eg, renaming of files with the same
-     size and mtime.
-   * direct: Fix ugly warning messages.
-   * WORM backend: When adding a file in a subdirectory, avoid including the
-     subdirectory in the key name.
-   * S3, Glacier, WebDAV: Fix bug that prevented accessing the creds
-     when the repository was configured with encryption=shared embedcreds=yes.
-   * direct: Avoid leaving file content in misctemp if interrupted.
-   * git-annex-shell sendkey: Don't fail if a remote asks for a key to be sent
-     that already has a transfer lock file indicating it's being sent to that
-     remote. The remote may have moved between networks, or reconnected.
-   * Switched from the old haskell HTTP library to http-conduit."""]]
\ No newline at end of file
diff --git a/doc/news/version_5.20140927.mdwn b/doc/news/version_5.20140927.mdwn
new file mode 100644
index 0000000..9aabf15
--- /dev/null
+++ b/doc/news/version_5.20140927.mdwn
@@ -0,0 +1,6 @@
+git-annex 5.20140927 released with [[!toggle text="these changes"]]
+[[!toggleable text="""
+   * Really depend (not just build-depend) on new enough git for --no-gpg-sign
+     to work. Closes: #[763057](http://bugs.debian.org/763057)
+   * Add temporary workaround for bug #763078 which broke building on armel
+     and armhf."""]]
\ No newline at end of file

Added a comment
diff --git a/doc/bugs/WebDAV_error_when_connecting_to_box.com:_The_resource_you_tried_to_create_already_exists/comment_1_ac40ddc26bff27dafdbc457837695a92._comment b/doc/bugs/WebDAV_error_when_connecting_to_box.com:_The_resource_you_tried_to_create_already_exists/comment_1_ac40ddc26bff27dafdbc457837695a92._comment
new file mode 100644
index 0000000..89ab74c
--- /dev/null
+++ b/doc/bugs/WebDAV_error_when_connecting_to_box.com:_The_resource_you_tried_to_create_already_exists/comment_1_ac40ddc26bff27dafdbc457837695a92._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawk0GR7KgDF6PAzHTkLZCCkjAvJVB7ceXTY"
+ nickname="Takafumi"
+ subject="comment 1"
+ date="2014-09-27T19:46:08Z"
+ content="""
+I updated git-annex and it works. Thank you very much.
+"""]]

close
diff --git a/doc/bugs/WebDAV_error_when_connecting_to_box.com:_The_resource_you_tried_to_create_already_exists.mdwn b/doc/bugs/WebDAV_error_when_connecting_to_box.com:_The_resource_you_tried_to_create_already_exists.mdwn
index a612530..857ca33 100644
--- a/doc/bugs/WebDAV_error_when_connecting_to_box.com:_The_resource_you_tried_to_create_already_exists.mdwn
+++ b/doc/bugs/WebDAV_error_when_connecting_to_box.com:_The_resource_you_tried_to_create_already_exists.mdwn
@@ -31,3 +31,6 @@ I ran the following while with appropriate environment variable WEBDAV_USERNAM a
     git-annex: WebDAV test failed: StatusCodeException (Status {statusCode = 405, statusMessage = "Method Not Allowed"}) [("Server","nginx"),("Date","Sat, 27 Sep 2014 09:36:42 GMT"),("Content-Type","application/xml; charset=utf-8"),("Content-Length","247"),("Connection","keep-alive"),("Vary","Host"),("Allow","OPTIONS, GET, HEAD, DELETE, PROPFIND, PUT, PROPPATCH, COPY, MOVE, REPORT, LOCK, UNLOCK"),("X-Response-Body-Start","<?xml version=\"1.0\" encoding=\"utf-8\"?>\n<d:error xmlns:d=\"DAV:\" xmlns:s=\"http://sabredav.org/ns\">\n  <s:exception>Sabre_DAV_Exception_MethodNotAllowed</s:exception>\n  <s:message>The resource you tried to create already exists</s:message>\n</d:error>\n")] (CJ {expose = []}): user error
     failed
     git-annex: enableremote: 1 failed
+
+> You are using an old version of git-annex; this bug was fixed in
+> version 5.20140919. [[done]] --[[Joey]]
diff --git a/doc/bugs/hS3_prevents_build.mdwn b/doc/bugs/hS3_prevents_build.mdwn
index 1d39135..1a064b9 100644
--- a/doc/bugs/hS3_prevents_build.mdwn
+++ b/doc/bugs/hS3_prevents_build.mdwn
@@ -1 +1,3 @@
 The `hS3` dependency doesn't work with the `network` / `network-uri` split, which causes a build failure for `git-annex` in a fresh sandbox with its current version bounds. Either more gymnastics are needed to constrain `network` to accommodate `hS3`, or the `s3-aws` branch could be merged in if it's ready. Building `git-annex` with a `< 2.6` constraint on `network` does succeed.
+
+> not a bug in git-annex, but in a dependency it uses, so [[done]]. (I already told the hS3 author about this, which is a very easy fix there, and he promised to fix it soon.) --[[Joey]]

diff --git a/doc/bugs/WebDAV_error_when_connecting_to_box.com:_The_resource_you_tried_to_create_already_exists.mdwn b/doc/bugs/WebDAV_error_when_connecting_to_box.com:_The_resource_you_tried_to_create_already_exists.mdwn
new file mode 100644
index 0000000..a612530
--- /dev/null
+++ b/doc/bugs/WebDAV_error_when_connecting_to_box.com:_The_resource_you_tried_to_create_already_exists.mdwn
@@ -0,0 +1,33 @@
+### Please describe the problem.
+
+"git-annex enableremote box.com" fails with "git-annex: WebDAV test failed".  The server returns error message "The resource you tried to create already exists" (see below).
+
+### What steps will reproduce the problem?
+
+1. I initialize box.com special remote in desktop.  The path at box.com is at "gas/annex".
+
+2. I enable the box.com special remote in laptop.  I got the error I described above.
+
+### What version of git-annex are you using? On what operating system?
+
+    $ git annex version  
+    git-annex version: 5.20140831-g62e6ad8
+    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
+    $ uname -a
+    Linux tkf-acer 3.12.9-2-ARCH #1 SMP PREEMPT Fri Jan 31 10:22:54 CET 2014 x86_64 GNU/Linux
+
+
+### Please provide any additional information below.
+
+I ran the following while with appropriate environment variable WEBDAV_USERNAM and WEBDAV_PASSWORD.
+
+    me@desktop$ git-annex initremote box type=webdav url=https://dav.box.com/dav/gas/annex chunk=50mb encryption=shared
+    
+    me@laptop$ git-annex enableremote box.com
+    enableremote box.com (testing WebDAV server...)
+    
+    git-annex: WebDAV test failed: StatusCodeException (Status {statusCode = 405, statusMessage = "Method Not Allowed"}) [("Server","nginx"),("Date","Sat, 27 Sep 2014 09:36:42 GMT"),("Content-Type","application/xml; charset=utf-8"),("Content-Length","247"),("Connection","keep-alive"),("Vary","Host"),("Allow","OPTIONS, GET, HEAD, DELETE, PROPFIND, PUT, PROPPATCH, COPY, MOVE, REPORT, LOCK, UNLOCK"),("X-Response-Body-Start","<?xml version=\"1.0\" encoding=\"utf-8\"?>\n<d:error xmlns:d=\"DAV:\" xmlns:s=\"http://sabredav.org/ns\">\n  <s:exception>Sabre_DAV_Exception_MethodNotAllowed</s:exception>\n  <s:message>The resource you tried to create already exists</s:message>\n</d:error>\n")] (CJ {expose = []}): user error
+    failed
+    git-annex: enableremote: 1 failed

diff --git a/doc/bugs/hS3_prevents_build.mdwn b/doc/bugs/hS3_prevents_build.mdwn
new file mode 100644
index 0000000..1d39135
--- /dev/null
+++ b/doc/bugs/hS3_prevents_build.mdwn
@@ -0,0 +1 @@
+The `hS3` dependency doesn't work with the `network` / `network-uri` split, which causes a build failure for `git-annex` in a fresh sandbox with its current version bounds. Either more gymnastics are needed to constrain `network` to accommodate `hS3`, or the `s3-aws` branch could be merged in if it's ready. Building `git-annex` with a `< 2.6` constraint on `network` does succeed.

add news item for git-annex 5.20140926
diff --git a/doc/news/version_5.20140717.mdwn b/doc/news/version_5.20140717.mdwn
deleted file mode 100644
index 9d7b831..0000000
--- a/doc/news/version_5.20140717.mdwn
+++ /dev/null
@@ -1,28 +0,0 @@
-git-annex 5.20140717 released with [[!toggle text="these changes"]]
-[[!toggleable text="""
-   * Fix minor FD leak in journal code. Closes: #[754608](http://bugs.debian.org/754608)
-   * direct: Fix handling of case where a work tree subdirectory cannot
-     be written to due to permissions.
-   * migrate: Avoid re-checksumming when migrating from hashE to hash backend.
-   * uninit: Avoid failing final removal in some direct mode repositories
-     due to file modes.
-   * S3: Deal with AWS ACL configurations that do not allow creating or
-     checking the location of a bucket, but only reading and writing content to
-     it.
-   * resolvemerge: New plumbing command that runs the automatic merge conflict
-     resolver.
-   * Deal with change in git 2.0 that made indirect mode merge conflict
-     resolution leave behind old files.
-   * sync: Fix git sync with local git remotes even when they don't have an
-     annex.uuid set. (The assistant already did so.)
-   * Set gcrypt-publish-participants when setting up a gcrypt repository,
-     to avoid unncessary passphrase prompts.
-     This is a security/usability tradeoff. To avoid exposing the gpg key
-     ids who can decrypt the repository, users can unset
-     gcrypt-publish-participants.
-   * Install nautilus hooks even when ~/.local/share/nautilus/ does not yet
-     exist, since it is not automatically created for Gnome 3 users.
-   * Windows: Move .vbs files out of git\bin, to avoid that being in the
-     PATH, which caused some weird breakage. (Thanks, divB)
-   * Windows: Fix locking issue that prevented the webapp starting
-     (since 5.20140707)."""]]
\ No newline at end of file
diff --git a/doc/news/version_5.20140926.mdwn b/doc/news/version_5.20140926.mdwn
new file mode 100644
index 0000000..289dd0b
--- /dev/null
+++ b/doc/news/version_5.20140926.mdwn
@@ -0,0 +1,5 @@
+git-annex 5.20140926 released with [[!toggle text="these changes"]]
+[[!toggleable text="""
+   * Depend on new enough git for --no-gpg-sign to work. Closes: #[762446](http://bugs.debian.org/762446)
+   * Work around failure to build on mips by using cabal, not Setup,
+     to build in debian/rules."""]]
\ No newline at end of file

Added a comment
diff --git a/doc/bugs/Can__39__t_add_a_git_repo_to_git_annex:___34__Invalid_path_repo__47__.git__47__X__34___for_many_X/comment_10_2c8e8a4f35b392b1cb4dc8104786312d._comment b/doc/bugs/Can__39__t_add_a_git_repo_to_git_annex:___34__Invalid_path_repo__47__.git__47__X__34___for_many_X/comment_10_2c8e8a4f35b392b1cb4dc8104786312d._comment
new file mode 100644
index 0000000..b95b3ed
--- /dev/null
+++ b/doc/bugs/Can__39__t_add_a_git_repo_to_git_annex:___34__Invalid_path_repo__47__.git__47__X__34___for_many_X/comment_10_2c8e8a4f35b392b1cb4dc8104786312d._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="JerSou"
+ ip="82.228.88.32"
+ subject="comment 10"
+ date="2014-09-25T19:27:43Z"
+ content="""
+I thought a workaround (but I don't think ultimately use) :
+
+>    \# for each git repo :
+
+>    mv .git .gitToAnnex
+
+>    ln -s .gitToAnnex .git
+
+>    echo .gitToAnnex >> .gitignore
+
+"""]]

removed
diff --git a/doc/bugs/Can__39__t_add_a_git_repo_to_git_annex:___34__Invalid_path_repo__47__.git__47__X__34___for_many_X/comment_10_80572f5fc9874fe76b08b940f1f7f8cf._comment b/doc/bugs/Can__39__t_add_a_git_repo_to_git_annex:___34__Invalid_path_repo__47__.git__47__X__34___for_many_X/comment_10_80572f5fc9874fe76b08b940f1f7f8cf._comment
deleted file mode 100644
index 3006bd9..0000000
--- a/doc/bugs/Can__39__t_add_a_git_repo_to_git_annex:___34__Invalid_path_repo__47__.git__47__X__34___for_many_X/comment_10_80572f5fc9874fe76b08b940f1f7f8cf._comment
+++ /dev/null
@@ -1,16 +0,0 @@
-[[!comment format=mdwn
- username="JerSou"
- ip="82.228.88.32"
- subject="comment 10"
- date="2014-09-25T19:26:03Z"
- content="""
-I have the same thoughts, I thought a workaround (but I don't think ultimately use) :
-
-> \# for each git repo :
-
->mv .git .gitToAnnex
-
->ln -s .gitToAnnex .git
-
->echo .gitToAnnex >> .gitignore
-"""]]

Added a comment
diff --git a/doc/bugs/Can__39__t_add_a_git_repo_to_git_annex:___34__Invalid_path_repo__47__.git__47__X__34___for_many_X/comment_10_80572f5fc9874fe76b08b940f1f7f8cf._comment b/doc/bugs/Can__39__t_add_a_git_repo_to_git_annex:___34__Invalid_path_repo__47__.git__47__X__34___for_many_X/comment_10_80572f5fc9874fe76b08b940f1f7f8cf._comment
new file mode 100644
index 0000000..3006bd9
--- /dev/null
+++ b/doc/bugs/Can__39__t_add_a_git_repo_to_git_annex:___34__Invalid_path_repo__47__.git__47__X__34___for_many_X/comment_10_80572f5fc9874fe76b08b940f1f7f8cf._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="JerSou"
+ ip="82.228.88.32"
+ subject="comment 10"
+ date="2014-09-25T19:26:03Z"
+ content="""
+I have the same thoughts, I thought a workaround (but I don't think ultimately use) :
+
+> \# for each git repo :
+
+>mv .git .gitToAnnex
+
+>ln -s .gitToAnnex .git
+
+>echo .gitToAnnex >> .gitignore
+"""]]

Added a comment
diff --git a/doc/forum/Direct_Mode_-_Restore_file_from_Full_Backup_Repository__63__/comment_2_eb6df2bfcb3892ae22050a8c5f67ee90._comment b/doc/forum/Direct_Mode_-_Restore_file_from_Full_Backup_Repository__63__/comment_2_eb6df2bfcb3892ae22050a8c5f67ee90._comment
new file mode 100644
index 0000000..5963d4b
--- /dev/null
+++ b/doc/forum/Direct_Mode_-_Restore_file_from_Full_Backup_Repository__63__/comment_2_eb6df2bfcb3892ae22050a8c5f67ee90._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmK0703vNSIQsP1mGf-4MAPnsBZiSc6yVo"
+ nickname="Emre"
+ subject="comment 2"
+ date="2014-09-25T19:25:06Z"
+ content="""
+Thanks Joeyh, of course i guess checking stuff in git would then lose my timestamps as in the previous post. I recommend, as a feature request, to make file recovery a bit easier if possible. I'm not a git expert and definitely wont use command line stuff for doing this on the long run, unless some more intuitive commands like \"git annex list-old-versions\" or \"git annex show-deleted\" and then \"git annex restore \"filename\" version_no  etc.
+"""]]

diff --git a/doc/todo/webapp_nudge_when_less_than_numcopies_clones.mdwn b/doc/todo/webapp_nudge_when_less_than_numcopies_clones.mdwn
new file mode 100644
index 0000000..ee38d0f
--- /dev/null
+++ b/doc/todo/webapp_nudge_when_less_than_numcopies_clones.mdwn
@@ -0,0 +1,7 @@
+Currently, nothing stops a user from setting up ~/annex, adding some special remote, and never once ending up with a clone of their repository, so there is really no backup of the repository as a whole, despite the special remotes.
+
+Potentially adding to the confusion, they might have remotes in repository groups "full backup" or "backup", and so think everything is backed up.
+
+Webapp could count the number of known remote uuids that are not special remotes, and require there to be at least numcopies of them (excluding the current repo I suppose), and pop up a nudge with a button that presents the various available ways to make a non-special remote.
+
+Working out if a remote uuid is a special remote is probably the hard bit. A special remote will be listed in uuid.log, with a type other than gcrypt or git. Any other uuid, that is not dead, can count as 1 clone. This does not handle git remotes that are not using git-annex (eg github), so it could also look through the git remote list and count any that don't have an annex-uuid.

removed
diff --git a/doc/forum/Removing_git-annex_repo.mdwn b/doc/forum/Removing_git-annex_repo.mdwn
deleted file mode 100644
index a19d6f8..0000000
--- a/doc/forum/Removing_git-annex_repo.mdwn
+++ /dev/null
@@ -1,3 +0,0 @@
-http://stackoverflow.com/questions/26041704/removing-repository-in-git-annex
-
-Does anyone know how to resolve it?

Added a comment
diff --git a/doc/forum/assistant_created_encrypted__backup_remote:_Howto_restore__63__/comment_6_cf877a3502802492cd2bc3012cb2d779._comment b/doc/forum/assistant_created_encrypted__backup_remote:_Howto_restore__63__/comment_6_cf877a3502802492cd2bc3012cb2d779._comment
new file mode 100644
index 0000000..3765a67
--- /dev/null
+++ b/doc/forum/assistant_created_encrypted__backup_remote:_Howto_restore__63__/comment_6_cf877a3502802492cd2bc3012cb2d779._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.144"
+ subject="comment 6"
+ date="2014-09-25T15:59:34Z"
+ content="""
+Right.
+
+So, I think I should go change the description displayed by the webapp to \"full backup (file contents only)\" and \"full backup (entire git repository)\" or so. It's a little hard to word it precisely without making it hard to understand.
+
+Or, the webapp could display a nudge to make a clone when no other clones of the git repository exist. I think that's probably more valuable, so [[todo_added|todo/webapp_nudge_when_less_than_numcopies_clones]].
+"""]]

Added a comment
diff --git a/doc/forum/Direct_Mode_-_Restore_file_from_Full_Backup_Repository__63__/comment_1_67ac7e8b53a4374baf640d32dac79030._comment b/doc/forum/Direct_Mode_-_Restore_file_from_Full_Backup_Repository__63__/comment_1_67ac7e8b53a4374baf640d32dac79030._comment
new file mode 100644
index 0000000..21adc4e
--- /dev/null
+++ b/doc/forum/Direct_Mode_-_Restore_file_from_Full_Backup_Repository__63__/comment_1_67ac7e8b53a4374baf640d32dac79030._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.144"
+ subject="comment 1"
+ date="2014-09-25T15:52:04Z"
+ content="""
+Yes, you need to use git to either revert the repository to a previous version that had the file, or perhaps just revert the commit where the file was deleted. Either way, this requires letting git modify files in the repository, which is prevented by direct mode. So, if you can `git annex indirect` to switch to indirect mode, your git commands will work then.
+"""]]

Added a comment
diff --git a/doc/forum/XMPP_problem_behind_router/comment_2_3186ebe32c30764b9fd53625dd3e4eda._comment b/doc/forum/XMPP_problem_behind_router/comment_2_3186ebe32c30764b9fd53625dd3e4eda._comment
new file mode 100644
index 0000000..63387ae
--- /dev/null
+++ b/doc/forum/XMPP_problem_behind_router/comment_2_3186ebe32c30764b9fd53625dd3e4eda._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.144"
+ subject="comment 2"
+ date="2014-09-25T15:48:39Z"
+ content="""
+I don't think that google XMPP server is at gmail.com. This suggests that the SRV record lookup to get from the email server to the xmpp server failed somehow. So, I'd look for a issue on the router's DNS server, or perhaps reconfigure DNS to bypass that server.
+"""]]

Added a comment
diff --git a/doc/forum/Removing_git-annex_repo/comment_1_58fcceb96647a8c7f33d188ae908f3bd._comment b/doc/forum/Removing_git-annex_repo/comment_1_58fcceb96647a8c7f33d188ae908f3bd._comment
new file mode 100644
index 0000000..d03ca6b
--- /dev/null
+++ b/doc/forum/Removing_git-annex_repo/comment_1_58fcceb96647a8c7f33d188ae908f3bd._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.144"
+ subject="comment 1"
+ date="2014-09-25T15:44:16Z"
+ content="""
+chmod u+w -R ~/annex/.git
+"""]]

Added a comment
diff --git a/doc/forum/Git_annex_assistant_can__39__t_find_rsync_nor_git-annex_on_server/comment_2_496e2f3a61b609ebb28ab55e5c30022b._comment b/doc/forum/Git_annex_assistant_can__39__t_find_rsync_nor_git-annex_on_server/comment_2_496e2f3a61b609ebb28ab55e5c30022b._comment
new file mode 100644
index 0000000..f0e6383
--- /dev/null
+++ b/doc/forum/Git_annex_assistant_can__39__t_find_rsync_nor_git-annex_on_server/comment_2_496e2f3a61b609ebb28ab55e5c30022b._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.144"
+ subject="comment 2"
+ date="2014-09-25T15:42:41Z"
+ content="""
+You need to be able to `ssh yourserver which rsync` and have it succeed. That's what git-annex uses to probe if rsync etc is present.
+
+Note that, since that does not start a login shell, bash doesn't source ~/.bash* at all, or even /etc/profile. So none of the ways people add nonstandard directories to PATH will work.
+
+So, use this to check the PATH that is available on the system: `ssh yourserver 'echo $PATH'`
+"""]]

diff --git a/doc/forum/Removing_git-annex_repo.mdwn b/doc/forum/Removing_git-annex_repo.mdwn
new file mode 100644
index 0000000..a19d6f8
--- /dev/null
+++ b/doc/forum/Removing_git-annex_repo.mdwn
@@ -0,0 +1,3 @@
+http://stackoverflow.com/questions/26041704/removing-repository-in-git-annex
+
+Does anyone know how to resolve it?

diff --git a/doc/forum/.mdwn b/doc/forum/.mdwn
new file mode 100644
index 0000000..ae58726
--- /dev/null
+++ b/doc/forum/.mdwn
@@ -0,0 +1,3 @@
+http://stackoverflow.com/questions/26041704/removing-repository-in-git-annex
+
+Does anyone know a solution for this?

Added a comment: Also with standalone git-annex
diff --git a/doc/forum/Git_annex_assistant_can__39__t_find_rsync_nor_git-annex_on_server/comment_1_75c599cc26e7d3645f69173861d4f8be._comment b/doc/forum/Git_annex_assistant_can__39__t_find_rsync_nor_git-annex_on_server/comment_1_75c599cc26e7d3645f69173861d4f8be._comment
new file mode 100644
index 0000000..20b8337
--- /dev/null
+++ b/doc/forum/Git_annex_assistant_can__39__t_find_rsync_nor_git-annex_on_server/comment_1_75c599cc26e7d3645f69173861d4f8be._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawn26A25mnLHRtWAP587-NPwEFKzolmENL4"
+ nickname="Marco"
+ subject="Also with standalone git-annex"
+ date="2014-09-24T14:14:43Z"
+ content="""
+Update: I also tried to install the standalone distribution in the home of the annex user on the server as shown in the video (BTW, nice illustration!), but I get the same error.
+(On the client side I installed the osx app instead.)
+"""]]

diff --git a/doc/forum/Git_annex_assistant_can__39__t_find_rsync_nor_git-annex_on_server.mdwn b/doc/forum/Git_annex_assistant_can__39__t_find_rsync_nor_git-annex_on_server.mdwn
new file mode 100644
index 0000000..66d224b
--- /dev/null
+++ b/doc/forum/Git_annex_assistant_can__39__t_find_rsync_nor_git-annex_on_server.mdwn
@@ -0,0 +1,14 @@
+Hi, I'm trying to setup git annex assistant (my first time).
+When I add the server (in "transfert" mode, if that matters) I get the following error:
+
+    "Neither rsync nor git-annex are installed on the server. Perhaps you should go install them?"
+
+I manually verified that both rsync and git/git-annex are installed and available from PATH in the "annex" account and all seems to be ok.
+
+Can you suggest a way to get a more specific information on the source of the error?
+
+My first guess was that this is due to the fact that rsync and git-annex are installed in "non-standard locations".  My server run NixOS (http://nixos.org) which has a completely different convention about directory hierarchy from traditional linux/unix OS (that is, no /usr/bin /usr/lib etc.).  However, I tried to "cheat" by manually adding symbolic links into a /usr/bin but this didn't work either, so I might be looking in the wrong direction.
+
+Any suggestion appreciated, thank you in advance,
+
+Marco

Added a comment
diff --git a/doc/bugs/sync_does_not_preserve_timestamps/comment_4_99b064259fc2e3c6eb83c3da3b2d3bac._comment b/doc/bugs/sync_does_not_preserve_timestamps/comment_4_99b064259fc2e3c6eb83c3da3b2d3bac._comment
new file mode 100644
index 0000000..08de756
--- /dev/null
+++ b/doc/bugs/sync_does_not_preserve_timestamps/comment_4_99b064259fc2e3c6eb83c3da3b2d3bac._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://svario.it/gioele"
+ nickname="gioele"
+ subject="comment 4"
+ date="2014-09-24T07:15:09Z"
+ content="""
+You can try to store the timestamps just before commit and restore them on checkout.
+
+Have a look at [metastore](https://github.com/przemoc/metastore): it is a ready-made solution for plain git. Maybe you can adapt it to git-annex.
+"""]]

Added a comment
diff --git a/doc/bugs/sync_does_not_preserve_timestamps/comment_3_9a3eeddc46e5a420575f00cb47caf703._comment b/doc/bugs/sync_does_not_preserve_timestamps/comment_3_9a3eeddc46e5a420575f00cb47caf703._comment
new file mode 100644
index 0000000..ba34823
--- /dev/null
+++ b/doc/bugs/sync_does_not_preserve_timestamps/comment_3_9a3eeddc46e5a420575f00cb47caf703._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmK0703vNSIQsP1mGf-4MAPnsBZiSc6yVo"
+ nickname="Emre"
+ subject="comment 3"
+ date="2014-09-23T21:15:29Z"
+ content="""
+Btw, git storing the last commit time as Mtime is not enough, it shall store the original timestamp of the file, not the date of commit. Hope I could explain and hope this is something doable.
+"""]]

Added a comment
diff --git a/doc/bugs/sync_does_not_preserve_timestamps/comment_2_c337fca1474b5b78f61ad6f421138ae4._comment b/doc/bugs/sync_does_not_preserve_timestamps/comment_2_c337fca1474b5b78f61ad6f421138ae4._comment
new file mode 100644
index 0000000..4b5a750
--- /dev/null
+++ b/doc/bugs/sync_does_not_preserve_timestamps/comment_2_c337fca1474b5b78f61ad6f421138ae4._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmK0703vNSIQsP1mGf-4MAPnsBZiSc6yVo"
+ nickname="Emre"
+ subject="comment 2"
+ date="2014-09-23T20:58:10Z"
+ content="""
+Thanks Joey for the comment. 
+
+But when syncing two repos, timestamps are critical at least for my use case. I can't lose this info. Even if it's expensive. 
+
+Appreciate if you can consider to add it for direct mode repos, ie when a file is synced to another repo and created there, it shall carry at least the mtime of the file in source repo. Owncloud sync does it, btsync does it, although I know git-annex is different than those. 
+"""]]

Added a comment
diff --git a/doc/bugs/sync_does_not_preserve_timestamps/comment_1_caf5e5cb17f4d05fff8c2fab661cd93f._comment b/doc/bugs/sync_does_not_preserve_timestamps/comment_1_caf5e5cb17f4d05fff8c2fab661cd93f._comment
new file mode 100644
index 0000000..48ec44d
--- /dev/null
+++ b/doc/bugs/sync_does_not_preserve_timestamps/comment_1_caf5e5cb17f4d05fff8c2fab661cd93f._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.144"
+ subject="comment 1"
+ date="2014-09-23T20:27:25Z"
+ content="""
+The closest git comes to storing a timestamp is the date of the last commit of a file for mtime, and first commit for ctime. However, those are pretty expensive to look up for a given file. And git doesn't try to preserve timestamps in checkouts at all, which argues that git-annex, at least at the command line, should not either.
+"""]]

close
diff --git a/doc/bugs/cabal_install_fails:_Could_not_find_module___8216__Network.URI__8217__.mdwn b/doc/bugs/cabal_install_fails:_Could_not_find_module___8216__Network.URI__8217__.mdwn
index b175ec5..2f9b5de 100644
--- a/doc/bugs/cabal_install_fails:_Could_not_find_module___8216__Network.URI__8217__.mdwn
+++ b/doc/bugs/cabal_install_fails:_Could_not_find_module___8216__Network.URI__8217__.mdwn
@@ -210,3 +210,7 @@ network-protocol-xmpp-0.4.6 depends on gnuidn-0.2.1 which failed to install.
 
 # End of transcript or log.
 """]]
+
+> This is a bug in hS3, not in git-annex. hS3 needs to be updated
+> per the example at <http://hackage.haskell.org/package/network>.
+> Email sent to hS3 author; [[done]]. --[[Joey]]

Added a comment: Why different versions?
diff --git a/doc/install/OSX/comment_9_f11f726d1fee3c4c91f3c984e792037d._comment b/doc/install/OSX/comment_9_f11f726d1fee3c4c91f3c984e792037d._comment
new file mode 100644
index 0000000..afc7268
--- /dev/null
+++ b/doc/install/OSX/comment_9_f11f726d1fee3c4c91f3c984e792037d._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawn3p4i4lk_zMilvjnJ9sS6g2nerpgz0Fjc"
+ nickname="Matthias"
+ subject="Why different versions?"
+ date="2014-09-23T10:59:32Z"
+ content="""
+Why are there different versions for 10.7, 10.8, 10.9 anyway? Is it not possible to produce an executable compatible with all these? I mean, it's the same architecture and executable format, not? I guess there has to be a reason, explanations are welcome :-)
+"""]]

Added a comment
diff --git a/doc/forum/XMPP_problem_behind_router/comment_1_25a7f8dc5cf14cda4d76b2f8c6ca77d5._comment b/doc/forum/XMPP_problem_behind_router/comment_1_25a7f8dc5cf14cda4d76b2f8c6ca77d5._comment
new file mode 100644
index 0000000..04b1965
--- /dev/null
+++ b/doc/forum/XMPP_problem_behind_router/comment_1_25a7f8dc5cf14cda4d76b2f8c6ca77d5._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://me.yahoo.com/a/wbh0dY54mcPwTpeOweuPQ8JiZrH3hg--#9b726"
+ nickname="Joe"
+ subject="comment 1"
+ date="2014-09-23T01:15:23Z"
+ content="""
+I forgot to mention that XMPP via other clients (e.g., empathy) works fine.
+"""]]

diff --git a/doc/forum/XMPP_problem_behind_router.mdwn b/doc/forum/XMPP_problem_behind_router.mdwn
new file mode 100644
index 0000000..5eec76a
--- /dev/null
+++ b/doc/forum/XMPP_problem_behind_router.mdwn
@@ -0,0 +1,3 @@
+I'm trying to configure a jabber account for use with git-annex, but it seems that something's wrong as soon as I try to go through my router (wired or wireless).  Compared to directly connecting to my modem, wireshark shows a lot of TCP retransmissions, eventually resulting in "Unable to connect to the Jabber server. Maybe you entered the wrong password? (Error message: host gmail.com:5222 failed: connect: timeout (Connection timed out))" in the webapp.
+
+I've tried to configure the account both in the webapp and manually in the .git/annex/creds/xmpp file, but it doesn't seem to make a difference.  It's able to connect if I directly connect it to my modem, so I'm fairly sure it's not a problem at my computer or with the credentials.  It doesn't appear to be a problem at the firewall on the router, but I could certainly be missing something.  Are there some other tests I could try to narrow down the problem?

removed
diff --git a/doc/sync/comment_17_675dd8ff219372c9efc780a02e3add53._comment b/doc/sync/comment_17_675dd8ff219372c9efc780a02e3add53._comment
deleted file mode 100644
index 7dd126c..0000000
--- a/doc/sync/comment_17_675dd8ff219372c9efc780a02e3add53._comment
+++ /dev/null
@@ -1,12 +0,0 @@
-[[!comment format=mdwn
- username="https://www.google.com/accounts/o8/id?id=AItOawmK0703vNSIQsP1mGf-4MAPnsBZiSc6yVo"
- nickname="Emre"
- subject="Sync between two indirectly connected remotes need XMPP?"
- date="2014-09-19T19:37:36Z"
- content="""
-Need to understand something. I just installed git-annex to my home PC, to my vps and to my office notebook. When I add the VPS as a shared encryption remote on both home PC and office notebook, they do not sync files. I tried assigning Full Backup and Transfer category to the VPS, but it did not help. The home pc and office notebook just sit there and do nothing to sync. For test purpose, I started with empty annex directory and started populating files on the home. It does sync to the VPS, but the office notebook is unaware of it and even if I try a manual sync, nothing happens.
-
-On the other hand, if I start from scratch, add local repo's on both home and office ones, then add XMPP Account on both, then I'm asked to add cloud account, and once I do it on one end,  it appears on the other and when I enable sync, they start to work. However, this is not a good scenario as the work network uses a Proxy and as far as I understand, git-annex does not yet support it (did not find any options for it in the webapp).
-
-So did I get right that an XMPP connection is required between indirectly connected repositories on different connections to be able to sync?  Ie a having a middleman computer with a repo is not enough.
-"""]]

fix urls
diff --git a/doc/thanks.mdwn b/doc/thanks.mdwn
index 9e7b9ac..d872c4d 100644
--- a/doc/thanks.mdwn
+++ b/doc/thanks.mdwn
@@ -8,11 +8,11 @@ email <joey@kitenet.net>.)
 
 ## 2014-2015
 
-<img alt="NSF logo" src="http://www.nsf.gov/images/logos/nsf1.gif">
+<img alt="NSF logo" src="https://www.nsf.gov/images/logos/nsf1.gif">
 
 git-annex development is partially supported by the
-[NSF](http://www.nsf.gov/images/logos/nsf1.gif) as a part of the
-[DataGit project](http://www.nsf.gov/awardsearch/showAward?AWD_ID=1429999).
+[NSF](https://www.nsf.gov/) as a part of the
+[DataGit project](https://www.nsf.gov/awardsearch/showAward?AWD_ID=1429999).
 
 ## 2013-2014
 

update
diff --git a/doc/thanks.mdwn b/doc/thanks.mdwn
index 10ab1f1..9e7b9ac 100644
--- a/doc/thanks.mdwn
+++ b/doc/thanks.mdwn
@@ -6,6 +6,14 @@ do. You have my most sincere thanks. --[[Joey]]
 (If I got your name wrong, or you don't want it publically posted here,
 email <joey@kitenet.net>.)
 
+## 2014-2015
+
+<img alt="NSF logo" src="http://www.nsf.gov/images/logos/nsf1.gif">
+
+git-annex development is partially supported by the
+[NSF](http://www.nsf.gov/images/logos/nsf1.gif) as a part of the
+[DataGit project](http://www.nsf.gov/awardsearch/showAward?AWD_ID=1429999).
+
 ## 2013-2014
 
 Continued git-annex development was [crowd funded](https://campaign.joeyh.name/)

diff --git a/doc/forum/Direct_Mode_-_Restore_file_from_Full_Backup_Repository__63__.mdwn b/doc/forum/Direct_Mode_-_Restore_file_from_Full_Backup_Repository__63__.mdwn
new file mode 100644
index 0000000..47c327f
--- /dev/null
+++ b/doc/forum/Direct_Mode_-_Restore_file_from_Full_Backup_Repository__63__.mdwn
@@ -0,0 +1,14 @@
+Hi, I'm using the webapp and created a repository on my local computer. Then I created another remote repository (encrypted remote with gcrypt), this remote repository is selected as type "full backup". 
+
+I've added some files to the local repository, then changed some of them and watched the sync happen. Then I deleted some files, and these also get synced to the remote.
+
+Now, how can I recover those files from the foreign repo, using the webapp or the command line? I could not find any solution.
+
+I tried:
+git log --diff-filter=D --summary
+and then
+git checkout 488408bfcd58eced685d9e3ca5daf55250850f5d -- .
+to recover the file listed in this remote but got the following response:
+fatal: This operation must be run in a work tree
+
+What do I miss and how does the "Restore" part work when using "full backup" remote repository?

diff --git a/doc/bugs/cabal_install_fails:_Could_not_find_module___8216__Network.URI__8217__.mdwn b/doc/bugs/cabal_install_fails:_Could_not_find_module___8216__Network.URI__8217__.mdwn
new file mode 100644
index 0000000..b175ec5
--- /dev/null
+++ b/doc/bugs/cabal_install_fails:_Could_not_find_module___8216__Network.URI__8217__.mdwn
@@ -0,0 +1,212 @@
+### Please describe the problem.
+
+Can't install git-annex from current git master. cabal install also fails. Both fail with the same error.
+
+### What steps will reproduce the problem?
+
+cabal install git-annex --bindir=$HOME/bin
+
+### What version of git-annex are you using? On what operating system?
+
+[[!format sh """
+$ uname -a
+Linux arch 3.16.3-1-ARCH #1 SMP PREEMPT Wed Sep 17 21:54:13 CEST 2014 x86_64 GNU/Linux
+
+$ cabal --version
+cabal-install version 1.20.0.3
+using version 1.20.0.0 of the Cabal library
+"""]]
+
+### 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
+
+$ cabal install git-annex --bindir=$HOME/bin
+Resolving dependencies...
+Configuring DAV-1.0.2...
+Configuring gnuidn-0.2.1...
+Configuring gsasl-0.3.5...
+Configuring hS3-0.5.8...
+Failed to install gsasl-0.3.5
+Build log ( /home/dirk/.cabal/logs/gsasl-0.3.5.log ):
+Configuring gsasl-0.3.5...
+setup-Simple-Cabal-1.18.1.3-x86_64-linux-ghc-7.8.3: The pkg-config package
+libgsasl version >=1.1 is required but it could not be found.
+Failed to install gnuidn-0.2.1
+Build log ( /home/dirk/.cabal/logs/gnuidn-0.2.1.log ):
+Configuring gnuidn-0.2.1...
+setup-Simple-Cabal-1.18.1.3-x86_64-linux-ghc-7.8.3: The program c2hs is
+required but it could not be found.
+Building hS3-0.5.8...
+Building DAV-1.0.2...
+Failed to install hS3-0.5.8
+Build log ( /home/dirk/.cabal/logs/hS3-0.5.8.log ):
+Configuring hS3-0.5.8...
+Building hS3-0.5.8...
+Preprocessing library hS3-0.5.8...
+
+Network/AWS/S3Object.hs:26:8:
+    Could not find module ‘Network.URI’
+    It is a member of the hidden package ‘network-uri-2.6.0.1’.
+    Perhaps you need to add ‘network-uri’ to the build-depends in your .cabal file.
+    Use -v to see a list of the files searched for.
+Failed to install DAV-1.0.2
+Build log ( /home/dirk/.cabal/logs/DAV-1.0.2.log ):
+Configuring DAV-1.0.2...
+Building DAV-1.0.2...
+Preprocessing library DAV-1.0.2...
+[1 of 2] Compiling Network.Protocol.HTTP.DAV.TH ( Network/Protocol/HTTP/DAV/TH.hs, dist/build/Network/Protocol/HTTP/DAV/TH.o )
+Loading package ghc-prim ... linking ... done.
+Loading package integer-gmp ... linking ... done.
+Loading package base ... linking ... done.
+Loading package array-0.5.0.0 ... linking ... done.
+Loading package deepseq-1.3.0.2 ... linking ... done.
+Loading package containers-0.5.5.1 ... linking ... done.
+Loading package bytestring-0.10.4.0 ... linking ... done.
+Loading package transformers-0.3.0.0 ... linking ... done.
+Loading package mtl-2.1.3.1 ... linking ... done.
+Loading package text-1.2.0.0 ... linking ... done.
+Loading package parsec-3.1.6 ... linking ... done.
+Loading package hashable-1.2.2.0 ... linking ... done.
+Loading package scientific-0.3.3.1 ... linking ... done.
+Loading package attoparsec-0.12.1.2 ... linking ... done.
+Loading package dlist-0.7.1 ... linking ... done.
+Loading package old-locale-1.0.0.6 ... linking ... done.
+Loading package syb-0.4.2 ... linking ... done.
+Loading package pretty-1.1.1.1 ... linking ... done.
+Loading package template-haskell ... linking ... done.
+Loading package time-1.4.2 ... linking ... done.
+Loading package unordered-containers-0.2.5.0 ... linking ... done.
+Loading package primitive-0.5.3.0 ... linking ... done.
+Loading package vector-0.10.11.0 ... linking ... done.
+Loading package aeson-0.8.0.0 ... linking ... done.
+Loading package blaze-builder-0.3.3.4 ... linking ... done.
+Loading package blaze-markup-0.6.1.1 ... linking ... done.
+Loading package blaze-html-0.7.0.3 ... linking ... done.
+Loading package filepath-1.3.0.2 ... linking ... done.
+Loading package unix-2.7.0.1 ... linking ... done.
+Loading package directory-1.2.1.0 ... linking ... done.
+Loading package exceptions-0.6.1 ... linking ... done.
+Loading package process-1.2.0.0 ... linking ... done.
+Loading package system-filepath-0.4.12 ... linking ... done.
+Loading package system-fileio-0.3.14 ... linking ... done.
+Loading package shakespeare-2.0.1.1 ... linking ... done.
+Loading package stm-2.4.3 ... linking ... done.
+Loading package transformers-base-0.4.3 ... linking ... done.
+Loading package monad-control-0.3.3.0 ... linking ... done.
+Loading package lifted-base-0.2.3.0 ... linking ... done.
+Loading package mmorph-1.0.4 ... linking ... done.
+Loading package resourcet-1.1.2.3 ... linking ... done.
+Loading package nats-0.2 ... linking ... done.
+Loading package semigroups-0.15.3 ... linking ... done.
+Loading package void-0.6.1 ... linking ... done.
+Loading package conduit-1.2.0.2 ... linking ... done.
+Loading package attoparsec-conduit-1.1.0 ... linking ... done.
+Loading package blaze-builder-conduit-1.1.0 ... linking ... done.
+Loading package network-2.6.0.2 ... linking ... done.
+Loading package random-1.1 ... linking ... done.
+Loading package zlib-0.5.4.1 ... linking ... done.
+Loading package streaming-commons-0.1.5 ... linking ... done.
+Loading package conduit-extra-1.1.3.4 ... linking ... done.
+Loading package data-default-class-0.0.1 ... linking ... done.
+Loading package data-default-instances-base-0.0.1 ... linking ... done.
+Loading package data-default-instances-containers-0.0.1 ... linking ... done.
+Loading package data-default-instances-dlist-0.0.1 ... linking ... done.
+Loading package data-default-instances-old-locale-0.0.1 ... linking ... done.
+Loading package data-default-0.5.3 ... linking ... done.
+Loading package xml-types-0.3.4 ... linking ... done.
+Loading package xml-conduit-1.2.2 ... linking ... done.
+Loading package xml-hamlet-0.4.0.9 ... linking ... done.
+Loading package transformers-compat-0.3.3.4 ... linking ... done.
+Loading package contravariant-1.2 ... linking ... done.
+Loading package tagged-0.7.2 ... linking ... done.
+Loading package distributive-0.4.4 ... linking ... done.
+Loading package comonad-4.2.2 ... linking ... done.
+Loading package semigroupoids-4.2 ... linking ... done.
+Loading package bifunctors-4.1.1.1 ... linking ... done.
+Loading package prelude-extras-0.4 ... linking ... done.
+Loading package profunctors-4.2.0.1 ... linking ... done.
+Loading package free-4.9 ... linking ... done.
+Loading package parallel-3.2.0.4 ... linking ... done.
+Loading package reflection-1.5.1 ... linking ... done.
+Loading package split-0.2.2 ... linking ... done.
+Loading package lens-4.4.0.2 ... linking ... done.
+Loading package byteable-0.1.1 ... linking ... done.
+Loading package securemem-0.1.3 ... linking ... done.
+Loading package crypto-cipher-types-0.0.9 ... linking ... done.
+Loading package cipher-aes-0.2.8 ... linking ... done.
+Loading package crypto-random-0.0.8 ... linking ... done.
+Loading package cprng-aes-0.5.2 ... linking ... done.
+Loading package cereal-0.4.0.1 ... linking ... done.
+Loading package socks-0.5.4 ... linking ... done.
+Loading package asn1-types-0.2.3 ... linking ... done.
+Loading package asn1-encoding-0.8.1.3 ... linking ... done.
+Loading package cipher-des-0.0.6 ... linking ... done.
+Loading package cipher-rc4-0.1.4 ... linking ... done.
+Loading package crypto-numbers-0.2.3 ... linking ... done.
+Loading package crypto-pubkey-types-0.4.2.2 ... linking ... done.
+Loading package cryptohash-0.11.6 ... linking ... done.
+Loading package crypto-pubkey-0.2.4 ... linking ... done.
+Loading package asn1-parse-0.8.1 ... linking ... done.
+Loading package base64-bytestring-1.0.0.1 ... linking ... done.
+Loading package pem-0.2.2 ... linking ... done.
+Loading package x509-1.4.12 ... linking ... done.
+Loading package x509-store-1.4.4 ... linking ... done.
+Loading package x509-validation-1.5.0 ... linking ... done.
+Loading package tls-1.2.9 ... linking ... done.
+Loading package x509-system-1.4.5 ... linking ... done.
+Loading package connection-0.2.3 ... linking ... done.
+Loading package case-insensitive-1.2.0.1 ... linking ... done.
+Loading package cookie-0.4.1.3 ... linking ... done.
+Loading package http-types-0.8.5 ... linking ... done.
+Loading package mime-types-0.1.0.4 ... linking ... done.
+Loading package network-uri-2.6.0.1 ... linking ... done.
+Loading package utf8-string-0.3.8 ... linking ... done.
+Loading package publicsuffixlist-0.1 ... linking ... done.
+Loading package http-client-0.4.0 ... linking ... done.
+Loading package http-client-tls-0.2.2 ... linking ... done.
+Loading package MonadRandom-0.3 ... linking ... done.
+Loading package either-4.3.1 ... linking ... done.
+Loading package safe-0.3.8 ... linking ... done.
+Loading package errors-1.4.7 ... linking ... done.
+[2 of 2] Compiling Network.Protocol.HTTP.DAV ( Network/Protocol/HTTP/DAV.hs, dist/build/Network/Protocol/HTTP/DAV.o )
+
+Network/Protocol/HTTP/DAV.hs:80:1: Warning:
+    The import of ‘unauthorized401’
+    from module ‘Network.HTTP.Types’ is redundant
+
+Network/Protocol/HTTP/DAV.hs:92:95: Warning:
+    ‘DAVT’ is an instance of MonadPlus but not Alternative - this will become an error in GHC 7.10, under the Applicative-Monad Proposal.
+
+Network/Protocol/HTTP/DAV.hs:213:1: Warning:
+    Defined but not used: ‘supportsCalDAV’
+
+Network/Protocol/HTTP/DAV.hs:88:10: Warning:
+    Orphan instance: instance Default DAVContext
+
+Network/Protocol/HTTP/DAV.hs:95:10: Warning:
+    Orphan instance: instance MonadMask m => MonadMask (EitherT e m)
+In-place registering DAV-1.0.2...
+Preprocessing executable 'hdav' for DAV-1.0.2...
+
+hdav.hs:33:8:

(Diff truncated)
diff --git a/doc/bugs/sync_does_not_preserve_timestamps.mdwn b/doc/bugs/sync_does_not_preserve_timestamps.mdwn
new file mode 100644
index 0000000..0d8f237
--- /dev/null
+++ b/doc/bugs/sync_does_not_preserve_timestamps.mdwn
@@ -0,0 +1,16 @@
+### Please describe the problem.
+I see that files are synced between my computers with git-annex but the timestamps do not match. The one that receives files always puts the current time of file creation on the file.
+
+### What steps will reproduce the problem?
+Install git-annex on two computers. Connect with XMPP. Then add cloud storage with shared encryption for transferring files. Since you want also backup, choose "full backup" as the type of cloud storage.
+
+
+### What version of git-annex are you using? On what operating system?
+Downloaded binary package dated 13/09/2014 amd64 Ubuntu 14.04.
+
+
+### Please provide any additional information below.
+
+Files are in sync. For example, I move a file from a directory to my synced annex directory. It contains timestamp of 01/01/2010 for example. Once the file gets transferred to the remote computer, it gets current time, for example 20/09/2014 rather than keeping 01/01/2010. 
+
+All computers are linux based, ext4 filesystems. File transfers are done through shared encryption rsync remote.

Added a comment
diff --git a/doc/forum/Modification_time_of_files_retained_in_synchronized_remote_copies__63__/comment_1_2b13584998108af0522b898c5d396ba4._comment b/doc/forum/Modification_time_of_files_retained_in_synchronized_remote_copies__63__/comment_1_2b13584998108af0522b898c5d396ba4._comment
new file mode 100644
index 0000000..1d5bf00
--- /dev/null
+++ b/doc/forum/Modification_time_of_files_retained_in_synchronized_remote_copies__63__/comment_1_2b13584998108af0522b898c5d396ba4._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmK0703vNSIQsP1mGf-4MAPnsBZiSc6yVo"
+ nickname="Emre"
+ subject="comment 1"
+ date="2014-09-19T21:31:23Z"
+ content="""
+I just saw your post and agree with you. Maybe we shall create a bug report. I would also need to keep my files in original timestamps. (may not mind about permissions though).
+"""]]

Added a comment: Understanding
diff --git a/doc/forum/assistant_created_encrypted__backup_remote:_Howto_restore__63__/comment_5_c1d247fa128c0a0fc899284f5f95002c._comment b/doc/forum/assistant_created_encrypted__backup_remote:_Howto_restore__63__/comment_5_c1d247fa128c0a0fc899284f5f95002c._comment
new file mode 100644
index 0000000..474bd66
--- /dev/null
+++ b/doc/forum/assistant_created_encrypted__backup_remote:_Howto_restore__63__/comment_5_c1d247fa128c0a0fc899284f5f95002c._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmK0703vNSIQsP1mGf-4MAPnsBZiSc6yVo"
+ nickname="Emre"
+ subject="Understanding"
+ date="2014-09-19T21:24:19Z"
+ content="""
+If box does not have the encryption keys in this \"shared encryption\" scenario and if you had only your computer and this remote repo, does that mean losing your computer (ie your git repository) would mean also losing access to those encrypted content? So, actually an encrypted remote, even if marked as full backup, is not actually a backup unless you have a 3rd computer that has the same git repo, in the case of losing your original computer or accidentally wiping it...
+"""]]

Added a comment: Sync between two indirectly connected remotes need XMPP?
diff --git a/doc/sync/comment_17_675dd8ff219372c9efc780a02e3add53._comment b/doc/sync/comment_17_675dd8ff219372c9efc780a02e3add53._comment
new file mode 100644
index 0000000..7dd126c
--- /dev/null
+++ b/doc/sync/comment_17_675dd8ff219372c9efc780a02e3add53._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmK0703vNSIQsP1mGf-4MAPnsBZiSc6yVo"
+ nickname="Emre"
+ subject="Sync between two indirectly connected remotes need XMPP?"
+ date="2014-09-19T19:37:36Z"
+ content="""
+Need to understand something. I just installed git-annex to my home PC, to my vps and to my office notebook. When I add the VPS as a shared encryption remote on both home PC and office notebook, they do not sync files. I tried assigning Full Backup and Transfer category to the VPS, but it did not help. The home pc and office notebook just sit there and do nothing to sync. For test purpose, I started with empty annex directory and started populating files on the home. It does sync to the VPS, but the office notebook is unaware of it and even if I try a manual sync, nothing happens.
+
+On the other hand, if I start from scratch, add local repo's on both home and office ones, then add XMPP Account on both, then I'm asked to add cloud account, and once I do it on one end,  it appears on the other and when I enable sync, they start to work. However, this is not a good scenario as the work network uses a Proxy and as far as I understand, git-annex does not yet support it (did not find any options for it in the webapp).
+
+So did I get right that an XMPP connection is required between indirectly connected repositories on different connections to be able to sync?  Ie a having a middleman computer with a repo is not enough.
+"""]]

Added a comment
diff --git a/doc/bugs/Upload_to_S3_fails_/comment_4_0cdd2e8d6e83c03de717ecd3253e753d._comment b/doc/bugs/Upload_to_S3_fails_/comment_4_0cdd2e8d6e83c03de717ecd3253e753d._comment
new file mode 100644
index 0000000..216aea5
--- /dev/null
+++ b/doc/bugs/Upload_to_S3_fails_/comment_4_0cdd2e8d6e83c03de717ecd3253e753d._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="67.223.1.203"
+ subject="comment 4"
+ date="2014-09-19T18:33:17Z"
+ content="""
+Your version supports both new and old style chunking. Which is used depends on how the S3 remote was configured when it was set up. It can't really be changed w/o re-setting up the remote. You can check which is used by `git show git-annex:remote.log`, find the line for the UUID of the remote, and see if it has chunk= (new chunking) or chunksize= (old chunking).
+"""]]

Added a comment
diff --git a/doc/forum/annex_merge_creates___34__synced__47____42____34___branches/comment_4_79219e920a6beb4bd3265571f59f51cb._comment b/doc/forum/annex_merge_creates___34__synced__47____42____34___branches/comment_4_79219e920a6beb4bd3265571f59f51cb._comment
new file mode 100644
index 0000000..8e07649
--- /dev/null
+++ b/doc/forum/annex_merge_creates___34__synced__47____42____34___branches/comment_4_79219e920a6beb4bd3265571f59f51cb._comment
@@ -0,0 +1,36 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlog_5wIICaMcrKTexlFNA6IO6UTp323aE"
+ nickname="Torkaly"
+ subject="comment 4"
+ date="2014-09-19T18:22:36Z"
+ content="""
+delete the *synced/master* branch:
+```
+$ git branch -d synced/master
+Branch synced/master entfernt (war 20ec8b3).
+```
+
+then call *annex merge*:
+```
+$ git annex merge
+merge git-annex ok
+```
+
+check branches:
+```
+$ git branch -a
+  git-annex
+* master
+  synced/master
+  remotes/origin/git-annex
+  remotes/origin/master
+```
+and there is the *synced/master* branch again.
+
+But that's not my problem. My problem was: how to use annex with a central repository.
+I done that by deleting all remote synced/* branches. And now I'm updating the git-annex branch by `git fetch`ing and
+`git annex merge`ing again.
+
+PS: the MD for code blocks is broken
+
+"""]]

add news item for git-annex 5.20140919
diff --git a/doc/news/version_5.20140709.mdwn b/doc/news/version_5.20140709.mdwn
deleted file mode 100644
index e760994..0000000
--- a/doc/news/version_5.20140709.mdwn
+++ /dev/null
@@ -1,11 +0,0 @@
-git-annex 5.20140709 released with [[!toggle text="these changes"]]
-[[!toggleable text="""
-   * Fix race in direct mode merge code that could cause all files in the
-     repository to be removed. It should be able to recover repositories
-     experiencing this bug without data loss. See:
-     http://git-annex.branchable.com/bugs/bad\_merge\_commit\_deleting\_all\_files/
-   * Fix git version that supported --no-gpg-sign.
-   * Fix bug in automatic merge conflict resolution, when one side is an
-     annexed symlink, and the other side is a non-annexed symlink.
-   * Really fix bug that caused the assistant to make many unncessary
-     empty merge commits."""]]
diff --git a/doc/news/version_5.20140919.mdwn b/doc/news/version_5.20140919.mdwn
new file mode 100644
index 0000000..7a179c9
--- /dev/null
+++ b/doc/news/version_5.20140919.mdwn
@@ -0,0 +1,16 @@
+git-annex 5.20140919 released with [[!toggle text="these changes"]]
+[[!toggleable text="""
+   * Security fix for S3 and glacier when using embedcreds=yes with
+     encryption=pubkey or encryption=hybrid. CVE-2014-6274
+     The creds embedded in the git repo were *not* encrypted.
+     git-annex enableremote will warn when used on a remote that has
+     this problem. For details, see:
+     https://git-annex.branchable.com/upgrades/insecure\_embedded\_creds/
+   * assistant: Detect when repository has been deleted or moved, and
+     automatically shut down the assistant. Closes: #[761261](http://bugs.debian.org/761261)
+   * Windows: Avoid crashing trying to list gpg secret keys, for gcrypt
+     which is not yet supported on Windows.
+   * WebDav: Fix enableremote crash when the remote already exists.
+     (Bug introduced in version 5.20140817.)
+   * add: In direct mode, adding an annex symlink will check it into git,
+     as was already done in indirect mode."""]]
\ No newline at end of file

Added a comment
diff --git a/doc/forum/big_overhead/comment_15_b973529bae549bcbaaae792f0403989b._comment b/doc/forum/big_overhead/comment_15_b973529bae549bcbaaae792f0403989b._comment
new file mode 100644
index 0000000..a875cc3
--- /dev/null
+++ b/doc/forum/big_overhead/comment_15_b973529bae549bcbaaae792f0403989b._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="rasmus"
+ ip="217.130.110.20"
+ subject="comment 15"
+ date="2014-09-19T06:29:58Z"
+ content="""
+Brilliant!  Thanks for taking time to analyze the issue and taking the bug to `gcrypt`.
+
+[I'm surprised that a different key than my git-annex key is used and that it's a symmetric key, but I will explore the technology on my own].
+"""]]

Added a comment
diff --git a/doc/bugs/Upload_to_S3_fails_/comment_3_cd1e768fe1e67daf08b5afd460620922._comment b/doc/bugs/Upload_to_S3_fails_/comment_3_cd1e768fe1e67daf08b5afd460620922._comment
new file mode 100644
index 0000000..5efb786
--- /dev/null
+++ b/doc/bugs/Upload_to_S3_fails_/comment_3_cd1e768fe1e67daf08b5afd460620922._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="annexuser"
+ ip="71.198.212.13"
+ subject="comment 3"
+ date="2014-09-19T04:43:42Z"
+ content="""
+Was the version I listed above not using the new chunking from the `s3-aws` branch? How do I determine if my version of git-annex was built with the new or old chunking?
+"""]]

Added a comment
diff --git a/doc/forum/big_overhead/comment_14_cbfb3d557915258e72c65a4e84df77a9._comment b/doc/forum/big_overhead/comment_14_cbfb3d557915258e72c65a4e84df77a9._comment
new file mode 100644
index 0000000..87632c9
--- /dev/null
+++ b/doc/forum/big_overhead/comment_14_cbfb3d557915258e72c65a4e84df77a9._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="108.236.230.124"
+ subject="comment 14"
+ date="2014-09-19T02:59:36Z"
+ content="""
+<https://github.com/bluss/git-remote-gcrypt/issues/16>
+"""]]

Added a comment: I know what it is now
diff --git a/doc/forum/big_overhead/comment_13_1c8cc992f04fc63179094c494bd25025._comment b/doc/forum/big_overhead/comment_13_1c8cc992f04fc63179094c494bd25025._comment
new file mode 100644
index 0000000..229ef25
--- /dev/null
+++ b/doc/forum/big_overhead/comment_13_1c8cc992f04fc63179094c494bd25025._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="108.236.230.124"
+ subject="I know what it is now"
+ date="2014-09-19T02:43:22Z"
+ content="""
+These objects are the ones written by git-remote-gcrypt when pushing to a remote. That's why the weird dates, root pseudo-commit, crazy filenames, and big gpg encrypted blobs. All countermeasures that git-remote-gcrypt uses to keep your encrypted git remote safe and not leak information about what's in it.
+
+So, this is a bug in git-remote-gcrypt. It needs to clean these objects up after pushing them! (Also after failed pushes.)
+"""]]

Added a comment
diff --git a/doc/forum/big_overhead/comment_12_475d5af95adcfcd3a51e10f270205eb7._comment b/doc/forum/big_overhead/comment_12_475d5af95adcfcd3a51e10f270205eb7._comment
new file mode 100644
index 0000000..53e15b7
--- /dev/null
+++ b/doc/forum/big_overhead/comment_12_475d5af95adcfcd3a51e10f270205eb7._comment
@@ -0,0 +1,71 @@
+[[!comment format=mdwn
+ username="rasmus"
+ ip="146.185.23.178"
+ subject="comment 12"
+ date="2014-09-19T00:43:56Z"
+ content="""
+Hi Joey,
+
+Thanks for giving the thread a more appropriate title and thanks for the helpful messages. 
+
+Let me start with the easy points:
+
+
+* Looking at my log file of installed packages I have never used `etckeeper` on my system.  So unless it could have entered through `annex` then I think we can rule that one out. 
+* According to `git log` the repos are from January 2014 where I restarted my repos. 
+
+
+        commit 029a8e76ab5f66aa4390987130985550a1ccd69c
+        Author: Rasmus <w530@domain.eu>
+        Date:   Thu Jan 23 21:06:13 2014 +0100
+
+        created repository
+
+
+* When I start git repos I typically just use \"init\" so I don't think I did the 2012 commits. 
+* I checked out one of the 74mb files.  When I do `file test.blob` it shows `test.blob: GPG symmetrically encrypted data (CAST5 cipher)`.  But none of my normal passwords worked.  Could such a gpg'ed file be from local network connections where the assistant asks for a passphrase?  I'm pretty sure that my transfer repo has only been using `gcrypt` and I believe I \"restarted\" my repos because I switched to `gcrypt` repos.  Also, my transfer repo is 10Gb as well which sounds big for transfer repo. 
+
+I performed a similar \"analysis\" on the `conf.annex` repo which should contain mostly no binary files (some 16x16 pngs etc).  
+
+`conf.annex` has 727 unreachable objects and 3477 commits in total.  Of these 338 are commits.  Here's an example of a larger commit message of an unreachable commit.
+
+    commit 601c10f9512e8d3502d9dd52ef409560ebb5b7e0
+    Author: root <root@localhost>
+    Date:   Mon Dec 31 19:00:01 2012 -0400
+
+         Initial commit
+
+     diff --git a/6fbbea493cdec9d912d256374199cc4c012022d35524c8789a7aceeb953442a5 b/6fbbea493cdec9d912d256374199cc4c012022d35524c8789a7aceeb953442a5
+     new file mode 100644
+     index 0000000..ea5fcc3
+     Binary files /dev/null and b/6fbbea493cdec9d912d256374199cc4c012022d35524c8789a7aceeb953442a5 differ
+     diff --git a/91bd0c092128cf2e60e1a608c31e92caf1f9c1595f83f2890ef17c0e4881aa0a b/91bd0c092128cf2e60e1a608c31e92caf1f9c1595f83f2890ef17c0e4881aa0a
+     new file mode 100644
+     index 0000000..a86c1a9
+     Binary files /dev/null and b/91bd0c092128cf2e60e1a608c31e92caf1f9c1595f83f2890ef17c0e4881aa0a differ
+     diff --git a/9da3fcfc1635c674012c35d90c21adce3c35440e629d64fe117fe349a6b3e194 b/9da3fcfc1635c674012c35d90c21adce3c35440e629d64fe117fe349a6b3e194
+     new file mode 100644
+     index 0000000..ef1d71c
+     Binary files /dev/null and b/9da3fcfc1635c674012c35d90c21adce3c35440e629d64fe117fe349a6b3e194 differ
+     diff --git a/ad4ae79c29b3756f7e41257db7454f3c319112d06385a8bc12d28209a82f2594 b/ad4ae79c29b3756f7e41257db7454f3c319112d06385a8bc12d28209a82f2594
+     new file mode 100644
+     index 0000000..61d3e5b
+     Binary files /dev/null and b/ad4ae79c29b3756f7e41257db7454f3c319112d06385a8bc12d28209a82f2594 differ
+     diff --git a/bd0e9cb492077e0c090bc62892c8de438c51a956c8215b2c68de7caa7e2431cc b/bd0e9cb492077e0c090bc62892c8de438c51a956c8215b2c68de7caa7e2431cc
+     new file mode 100644
+     index 0000000..92e9bd7
+     Binary files /dev/null and b/bd0e9cb492077e0c090bc62892c8de438c51a956c8215b2c68de7caa7e2431cc differ
+
+Across all commits 6006 objects are mentioned, but only 371 are unique. 
+
+I checked out one blob and again `file` reports `GPG symmetrically encrypted data (CAST5 cipher)`.  Interesting for `conf.annex` I get this line when trying to decrypt
+
+    gpg: DBG: cleared passphrase cached with ID: SBF83A0F822D0F664
+
+
+For `doc.annex` I get
+
+    gpg: DBG: cleared passphrase cached with ID: S32DEAD1E8DD06A4D
+
+And on my other computer I see a third ID.  I'm not sure if this means anything when files are symmetrically encrypted, though. 
+"""]]

error, don't warn about insecure creds
A one-time warning was not good enough. A hard error will force the user to
notice the problem.
Perhaps worth noting that git-annex enableremote already failed with an
error, and nobody reported a bug. Suggests that not many people have used
the insecure configuration, or if they did, they went to the bother to
embedcreds, but never re-enabled the special remote.
diff --git a/Creds.hs b/Creds.hs
index f9b8c4e..5e6c54e 100644
--- a/Creds.hs
+++ b/Creds.hs
@@ -110,7 +110,7 @@ getRemoteCredPair c storage = maybe fromcache (return . Just) =<< fromenv
 				-- Not a problem for shared cipher.
 				case storablecipher of
 					SharedCipher {} -> showLongNote "gpg error above was caused by an old git-annex bug in credentials storage. Working around it.."
-					_ -> warning "*** Insecure credentials storage detected for this remote! See https://git-annex.branchable.com/upgrades/insecure_embedded_creds/"
+					_ -> error "*** Insecure credentials storage detected for this remote! See https://git-annex.branchable.com/upgrades/insecure_embedded_creds/"
 				fromcreds $ fromB64 enccreds
 	fromcreds creds = case decodeCredPair creds of
 		Just credpair -> do
diff --git a/doc/upgrades/insecure_embedded_creds.mdwn b/doc/upgrades/insecure_embedded_creds.mdwn
index 19713f9..a221fb5 100644
--- a/doc/upgrades/insecure_embedded_creds.mdwn
+++ b/doc/upgrades/insecure_embedded_creds.mdwn
@@ -6,12 +6,9 @@ in (effectively) plaintext, not encrypted as they were supposed to be.
 That means that anyone who gets a copy of the git repository can extract the
 AWS credentials from it. Which would be bad..
 
-Fixed versions of git-annex will detect this problem when enabling such a
-remote, and print a warning message (including a pointer to this web page).
-
-This message will only be printed one time, since git-annex will
-change the embedded credentials to be encrypted properly.
-However, this leaves the non-encrypted version still in the git history.
+A remote with this problem cannot be enabled using `git annex
+enableremote`. Old versions of git-annex will fail with a gpg error;
+the current version will fail with a pointer to this web page.
 
 If your repository has this problem, chose from one of these approaches
 to deal with it:
@@ -25,11 +22,21 @@ to deal with it:
    `AWS_SECRET_ACCESS_KEY` and `AWS_ACCESS_KEY_ID` environment variables,
    and running `git annex enableremote $remotename embedcreds=yes`
 
-2. Remove the history of the git-annex branch of the repository.
-   You can use `git annex forget` to do that; note that it will
-   remove other historical data too. Keep in mind that this will not
-   necessarily delete data from clones you do not control.
+2. Fix the problem and then remove the history of the git-annex branch
+   of the repository.
+
+   Make sure you have a fixed version of git-annex, and force git-annex
+   to rewrite the embedded creds, with encryption this time, by setting
+   by setting the `AWS_SECRET_ACCESS_KEY` and `AWS_ACCESS_KEY_ID`
+   environment variables, and running `git annex enableremote $remotename embedcreds=yes`
+
+   Then, to get rid of old versions of the git-annex branch that still
+   contain the creds in cleartext, you can use `git annex forget`;
+   note that it will remove other historical data too.
+   
+   Keep in mind that this will not necessarily delete data from clones
+   you do not control.
 
-3. If you're the only one who has access to the repository, you could decide
-   to leave it as-is. It's no more insecure than if you had used
-   encryption=shared in the first place when setting it up.
+3. If you're sure that you're the only one who has access to the repository,
+   you could decide to leave it as-is. It's no more insecure than if you
+   had used encryption=shared in the first place when setting it up.

git history is hard to kill, make sure it's clear
diff --git a/doc/upgrades/insecure_embedded_creds.mdwn b/doc/upgrades/insecure_embedded_creds.mdwn
index 117ee96..19713f9 100644
--- a/doc/upgrades/insecure_embedded_creds.mdwn
+++ b/doc/upgrades/insecure_embedded_creds.mdwn
@@ -26,8 +26,9 @@ to deal with it:
    and running `git annex enableremote $remotename embedcreds=yes`
 
 2. Remove the history of the git-annex branch of the repository.
-   You can use `git annex forget`` to do that; note that it will
-   remove other historical data too.
+   You can use `git annex forget` to do that; note that it will
+   remove other historical data too. Keep in mind that this will not
+   necessarily delete data from clones you do not control.
 
 3. If you're the only one who has access to the repository, you could decide
    to leave it as-is. It's no more insecure than if you had used

number
diff --git a/doc/upgrades/insecure_embedded_creds.mdwn b/doc/upgrades/insecure_embedded_creds.mdwn
index b0554a5..117ee96 100644
--- a/doc/upgrades/insecure_embedded_creds.mdwn
+++ b/doc/upgrades/insecure_embedded_creds.mdwn
@@ -13,8 +13,8 @@ This message will only be printed one time, since git-annex will
 change the embedded credentials to be encrypted properly.
 However, this leaves the non-encrypted version still in the git history.
 
-If your repository has this problem, you have two courses of action to fix
-it:
+If your repository has this problem, chose from one of these approaches
+to deal with it:
 
 1. Change your AWS credentials, so the ones stored in the clear in git
    won't be used. 

devblog
diff --git a/doc/devblog/day_221__another_fine_day_of_bugfixing.mdwn b/doc/devblog/day_221__another_fine_day_of_bugfixing.mdwn
new file mode 100644
index 0000000..0c26f57
--- /dev/null
+++ b/doc/devblog/day_221__another_fine_day_of_bugfixing.mdwn
@@ -0,0 +1,10 @@
+Working through the forum posts and bugs. Backlog is down to 95.
+
+Discovered the first known security hole in git-annex!
+Turns out that S3 and Glacier remotes that were configured with embedcreds=yes and encryption=pubkey or encryption=hybrid
+didn't actually encrypt the AWS credentials that get embedded into the git
+repo. This doesn't affect any repos set up by the assistant.
+
+I've fixed the problem and am going to make a release soon.
+If your repo is affected, see 
+[[upgrades/insecure_embedded_creds]] for what to do about it.

deal with old repositories with non-encrypted creds
See 2f3c3aa01ff0eb1dfdf1e30ff29fef40ed8fd167 for backstory about how a repo
could be in this state.
When decryption fails, the repo must be using non-encrypted creds. Note
that creds are encrypted/decrypted using the encryption cipher which is
stored in the repo, so the decryption cannot fail due to missing gpg keys
etc. (For !shared encryptiom, the cipher is iteself encrypted using some
gpg key(s), and the decryption of the cipher happens earlier, so not
affected by this change.
Print a warning message for !shared repos, and continue on using the
cipher. Wrote a page explaining what users hit by this bug should do.
This commit was sponsored by Samuel Tardieu.
diff --git a/Creds.hs b/Creds.hs
index aad3996..f9b8c4e 100644
--- a/Creds.hs
+++ b/Creds.hs
@@ -23,7 +23,7 @@ import Annex.Perms
 import Utility.FileMode
 import Crypto
 import Types.Remote (RemoteConfig, RemoteConfigKey)
-import Remote.Helper.Encryptable (remoteCipher, embedCreds, EncryptionIsSetup)
+import Remote.Helper.Encryptable (remoteCipher, remoteCipher', embedCreds, EncryptionIsSetup)
 import Utility.Env (getEnv)
 
 import qualified Data.ByteString.Lazy.Char8 as L
@@ -90,20 +90,32 @@ getRemoteCredPair c storage = maybe fromcache (return . Just) =<< fromenv
 	fromcache = maybe fromconfig (return . Just) =<< readCacheCredPair storage
 	fromconfig = case credPairRemoteKey storage of
 		Just key -> do
-			mcipher <- remoteCipher c
+			mcipher <- remoteCipher' c
 			case (M.lookup key c, mcipher) of
 				(Nothing, _) -> return Nothing
-				(Just enccreds, Just cipher) -> do
-					creds <- liftIO $ decrypt cipher
-						(feedBytes $ L.pack $ fromB64 enccreds)
-						(readBytes $ return . L.unpack)
-					fromcreds creds
+				(Just enccreds, Just (cipher, storablecipher)) ->
+					fromenccreds enccreds cipher storablecipher
 				(Just bcreds, Nothing) ->
 					fromcreds $ fromB64 bcreds
 		Nothing -> return Nothing
+	fromenccreds enccreds cipher storablecipher = do
+		mcreds <- liftIO $ catchMaybeIO $ decrypt cipher
+			(feedBytes $ L.pack $ fromB64 enccreds)
+			(readBytes $ return . L.unpack)
+		case mcreds of
+			Just creds -> fromcreds creds
+			Nothing -> do
+				-- Work around un-encrypted creds storage
+				-- bug in old S3 and glacier remotes.
+				-- Not a problem for shared cipher.
+				case storablecipher of
+					SharedCipher {} -> showLongNote "gpg error above was caused by an old git-annex bug in credentials storage. Working around it.."
+					_ -> warning "*** Insecure credentials storage detected for this remote! See https://git-annex.branchable.com/upgrades/insecure_embedded_creds/"
+				fromcreds $ fromB64 enccreds
 	fromcreds creds = case decodeCredPair creds of
 		Just credpair -> do
 			writeCacheCredPair credpair storage
+
 			return $ Just credpair
 		_ -> error "bad creds"
 
diff --git a/Remote/Helper/Encryptable.hs b/Remote/Helper/Encryptable.hs
index e8e9d3b..05f3fc3 100644
--- a/Remote/Helper/Encryptable.hs
+++ b/Remote/Helper/Encryptable.hs
@@ -11,6 +11,7 @@ module Remote.Helper.Encryptable (
 	noEncryptionUsed,
 	encryptionAlreadySetup,
 	remoteCipher,
+	remoteCipher',
 	embedCreds,
 	cipherKey,
 	storeCipher,
@@ -93,21 +94,24 @@ encryptionSetup c = maybe genCipher updateCipher $ extractCipher c
                 -- remotes (while being backward-compatible).
 		[ "keyid", "keyid+", "keyid-", "highRandomQuality" ]
 
+remoteCipher :: RemoteConfig -> Annex (Maybe Cipher)
+remoteCipher = fmap fst <$$> remoteCipher'
+
 {- Gets encryption Cipher. The decrypted Ciphers are cached in the Annex
  - state. -}
-remoteCipher :: RemoteConfig -> Annex (Maybe Cipher)
-remoteCipher c = go $ extractCipher c
+remoteCipher' :: RemoteConfig -> Annex (Maybe (Cipher, StorableCipher))
+remoteCipher' c = go $ extractCipher c
   where
 	go Nothing = return Nothing
 	go (Just encipher) = do
 		cache <- Annex.getState Annex.ciphers
 		case M.lookup encipher cache of
-			Just cipher -> return $ Just cipher
+			Just cipher -> return $ Just (cipher, encipher)
 			Nothing -> do
 				showNote "gpg"
 				cipher <- liftIO $ decryptCipher encipher
 				Annex.changeState (\s -> s { Annex.ciphers = M.insert encipher cipher cache })
-				return $ Just cipher
+				return $ Just (cipher, encipher)
 
 {- Checks if the remote's config allows storing creds in the remote's config.
  - 
diff --git a/debian/changelog b/debian/changelog
index ffb760b..5bfba77 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -3,6 +3,9 @@ git-annex (5.20140916) UNRELEASED; urgency=medium
   * Security fix for S3 and glacier when using embedcreds=yes with
     encryption=pubkey or encryption=hybrid. 
     The creds embedded in the git repo were *not* encrypted.
+    git-annex enableremote will warn when used on a remote that has
+    this problem. For details, see:
+    https://git-annex.branchable.com/upgrades/insecure_embedded_creds/
   * assistant: Detect when repository has been deleted or moved, and
     automatically shut down the assistant. Closes: #761261
   * Windows: Avoid crashing trying to list gpg secret keys, for gcrypt
diff --git a/doc/upgrades/insecure_embedded_creds.mdwn b/doc/upgrades/insecure_embedded_creds.mdwn
new file mode 100644
index 0000000..b0554a5
--- /dev/null
+++ b/doc/upgrades/insecure_embedded_creds.mdwn
@@ -0,0 +1,34 @@
+git-annex had a bug in the S3 and Glacier remotes where if embedcreds=yes
+was set, and the remote used encryption=pubkey or encryption=hybrid,
+the embedded AWS credentials were stored in the git repository
+in (effectively) plaintext, not encrypted as they were supposed to be.
+
+That means that anyone who gets a copy of the git repository can extract the
+AWS credentials from it. Which would be bad..
+
+Fixed versions of git-annex will detect this problem when enabling such a
+remote, and print a warning message (including a pointer to this web page).
+
+This message will only be printed one time, since git-annex will
+change the embedded credentials to be encrypted properly.
+However, this leaves the non-encrypted version still in the git history.
+
+If your repository has this problem, you have two courses of action to fix
+it:
+
+1. Change your AWS credentials, so the ones stored in the clear in git
+   won't be used. 
+   
+   After changing the credentials, make sure you have a
+   fixed version of git-annex, and you can then re-embed the new creds
+   into the repository, encrypted this time, by setting the
+   `AWS_SECRET_ACCESS_KEY` and `AWS_ACCESS_KEY_ID` environment variables,
+   and running `git annex enableremote $remotename embedcreds=yes`
+
+2. Remove the history of the git-annex branch of the repository.
+   You can use `git annex forget`` to do that; note that it will
+   remove other historical data too.
+
+3. If you're the only one who has access to the repository, you could decide
+   to leave it as-is. It's no more insecure than if you had used
+   encryption=shared in the first place when setting it up.

glacier, S3: Fix bug that caused embedded creds to not be encypted using the remote's key.
encryptionSetup must be called before setRemoteCredPair. Otherwise,
the RemoteConfig doesn't have the cipher in it, and so no cipher is used to
encrypt the embedded creds.
This is a security fix for non-shared encryption methods!
For encryption=shared, there's no security problem, just an
inconsistentency in whether the embedded creds are encrypted.
This is very important to get right, so used some types to help ensure that
setRemoteCredPair is only run after encryptionSetup. Note that the external
special remote bypasses the type safety, since creds can be set after the
initial remote config, if the external special remote program requests it.
Also note that IA remotes never use encryption, so encryptionSetup is not
run for them at all, and again the type safety is bypassed.
This leaves two open questions:
1. What to do about S3 and glacier remotes that were set up
using encryption=pubkey/hybrid with embedcreds?
Such a git repo has a security hole embedded in it, and this needs to be
communicated to the user. Is the changelog enough?
2. enableremote won't work in such a repo, because git-annex will
try to decrypt the embedded creds, which are not encrypted, so fails.
This needs to be dealt with, especially for ecryption=shared repos,
which are not really broken, just inconsistently configured.
Noticing that problem for encryption=shared is what led to commit
fbdeeeed5fa276d94be587c8916d725eddcaf546, which tried to
fix the problem by not decrypting the embedded creds.
This commit was sponsored by Josh Taylor.
diff --git a/Creds.hs b/Creds.hs
index 7273ed9..aad3996 100644
--- a/Creds.hs
+++ b/Creds.hs
@@ -23,7 +23,7 @@ import Annex.Perms
 import Utility.FileMode
 import Crypto
 import Types.Remote (RemoteConfig, RemoteConfigKey)
-import Remote.Helper.Encryptable (remoteCipher, embedCreds)
+import Remote.Helper.Encryptable (remoteCipher, embedCreds, EncryptionIsSetup)
 import Utility.Env (getEnv)
 
 import qualified Data.ByteString.Lazy.Char8 as L
@@ -40,12 +40,17 @@ data CredPairStorage = CredPairStorage
 
 {- Stores creds in a remote's configuration, if the remote allows
  - that. Otherwise, caches them locally.
- - The creds are found in storage if not provided. -}
-setRemoteCredPair :: RemoteConfig -> CredPairStorage -> Maybe CredPair -> Annex RemoteConfig
-setRemoteCredPair c storage Nothing = 
-	maybe (return c) (setRemoteCredPair c storage . Just)
+ - The creds are found in storage if not provided.
+ -
+ - The remote's configuration should have already had a cipher stored in it
+ - if that's going to be done, so that the creds can be encrypted using the
+ - cipher. The EncryptionIsSetup phantom type ensures that is the case.
+ -}
+setRemoteCredPair :: EncryptionIsSetup -> RemoteConfig -> CredPairStorage -> Maybe CredPair -> Annex RemoteConfig
+setRemoteCredPair encsetup c storage Nothing = 
+	maybe (return c) (setRemoteCredPair encsetup c storage . Just)
 		=<< getRemoteCredPair c storage
-setRemoteCredPair c storage (Just creds)
+setRemoteCredPair _ c storage (Just creds)
 	| embedCreds c = case credPairRemoteKey storage of
 		Nothing -> localcache
 		Just key -> storeconfig key =<< remoteCipher c
diff --git a/Remote/Bup.hs b/Remote/Bup.hs
index 0de0e29..cc64d6f 100644
--- a/Remote/Bup.hs
+++ b/Remote/Bup.hs
@@ -94,7 +94,7 @@ bupSetup mu _ c = do
 	-- verify configuration is sane
 	let buprepo = fromMaybe (error "Specify buprepo=") $
 		M.lookup "buprepo" c
-	c' <- encryptionSetup c
+	(c', _encsetup) <- encryptionSetup c
 
 	-- bup init will create the repository.
 	-- (If the repository already exists, bup init again appears safe.)
diff --git a/Remote/Ddar.hs b/Remote/Ddar.hs
index fc226dd..1db482b 100644
--- a/Remote/Ddar.hs
+++ b/Remote/Ddar.hs
@@ -84,7 +84,7 @@ ddarSetup mu _ c = do
 	-- verify configuration is sane
 	let ddarrepo = fromMaybe (error "Specify ddarrepo=") $
 		M.lookup "ddarrepo" c
-	c' <- encryptionSetup c
+	(c', _encsetup) <- encryptionSetup c
 
 	-- The ddarrepo is stored in git config, as well as this repo's
 	-- persistant state, so it can vary between hosts.
diff --git a/Remote/Directory.hs b/Remote/Directory.hs
index 3137c95..fa4d027 100644
--- a/Remote/Directory.hs
+++ b/Remote/Directory.hs
@@ -81,7 +81,7 @@ directorySetup mu _ c = do
 	absdir <- liftIO $ absPath dir
 	liftIO $ unlessM (doesDirectoryExist absdir) $
 		error $ "Directory does not exist: " ++ absdir
-	c' <- encryptionSetup c
+	(c', _encsetup) <- encryptionSetup c
 
 	-- The directory is stored in git config, not in this remote's
 	-- persistant state, so it can vary between hosts.
diff --git a/Remote/External.hs b/Remote/External.hs
index 6ba0e2f..c3ea7e1 100644
--- a/Remote/External.hs
+++ b/Remote/External.hs
@@ -77,7 +77,7 @@ externalSetup mu _ c = do
 	u <- maybe (liftIO genUUID) return mu
 	let externaltype = fromMaybe (error "Specify externaltype=") $
 		M.lookup "externaltype" c
-	c' <- encryptionSetup c
+	(c', _encsetup) <- encryptionSetup c
 
 	external <- newExternal externaltype u c'
 	handleRequest external INITREMOTE Nothing $ \resp -> case resp of
@@ -191,7 +191,7 @@ handleRequest' lck external req mp responsehandler
 		send $ VALUE value
 	handleRemoteRequest (SETCREDS setting login password) = do
 		c <- liftIO $ atomically $ readTMVar $ externalConfig external
-		c' <- setRemoteCredPair c (credstorage setting) $
+		c' <- setRemoteCredPair encryptionAlreadySetup c (credstorage setting) $
 			Just (login, password)
 		void $ liftIO $ atomically $ swapTMVar (externalConfig external) c'
 	handleRemoteRequest (GETCREDS setting) = do
diff --git a/Remote/GCrypt.hs b/Remote/GCrypt.hs
index a95f216..f1d561d 100644
--- a/Remote/GCrypt.hs
+++ b/Remote/GCrypt.hs
@@ -168,7 +168,7 @@ gCryptSetup mu _ c = go $ M.lookup "gitrepo" c
 	remotename = fromJust (M.lookup "name" c)
   	go Nothing = error "Specify gitrepo="
 	go (Just gitrepo) = do
-		c' <- encryptionSetup c
+		(c', _encsetup) <- encryptionSetup c
 		inRepo $ Git.Command.run 
 			[ Params "remote add"
 			, Param remotename
diff --git a/Remote/Glacier.hs b/Remote/Glacier.hs
index 18038a7..ba3cc55 100644
--- a/Remote/Glacier.hs
+++ b/Remote/Glacier.hs
@@ -76,12 +76,12 @@ gen r u c gc = new <$> remoteCost gc veryExpensiveRemoteCost
 glacierSetup :: Maybe UUID -> Maybe CredPair -> RemoteConfig -> Annex (RemoteConfig, UUID)
 glacierSetup mu mcreds c = do
 	u <- maybe (liftIO genUUID) return mu
-	c' <- setRemoteCredPair c (AWS.creds u) mcreds
-	glacierSetup' (isJust mu) u c'
-glacierSetup' :: Bool -> UUID -> RemoteConfig -> Annex (RemoteConfig, UUID)
-glacierSetup' enabling u c = do
-	c' <- encryptionSetup c
-	let fullconfig = c' `M.union` defaults
+	glacierSetup' (isJust mu) u mcreds c
+glacierSetup' :: Bool -> UUID -> Maybe CredPair -> RemoteConfig -> Annex (RemoteConfig, UUID)
+glacierSetup' enabling u mcreds c = do
+	(c', encsetup) <- encryptionSetup c
+	c'' <- setRemoteCredPair encsetup c' (AWS.creds u) mcreds
+	let fullconfig = c'' `M.union` defaults
 	unless enabling $
 		genVault fullconfig u
 	gitConfigSpecialRemote u fullconfig "glacier" "true"
diff --git a/Remote/Helper/Encryptable.hs b/Remote/Helper/Encryptable.hs
index dd032ce..e8e9d3b 100644
--- a/Remote/Helper/Encryptable.hs
+++ b/Remote/Helper/Encryptable.hs
@@ -5,7 +5,17 @@
  - Licensed under the GNU GPL version 3 or higher.
  -}
 
-module Remote.Helper.Encryptable where
+module Remote.Helper.Encryptable (
+	EncryptionIsSetup,
+	encryptionSetup,
+	noEncryptionUsed,
+	encryptionAlreadySetup,
+	remoteCipher,
+	embedCreds,
+	cipherKey,
+	storeCipher,
+	extractCipher,
+) where
 
 import qualified Data.Map as M
 
@@ -16,11 +26,26 @@ import Types.Crypto
 import qualified Annex
 import Utility.Base64
 
+-- Used to ensure that encryption has been set up before trying to
+-- eg, store creds in the remote config that would need to use the
+-- encryption setup.
+data EncryptionIsSetup = EncryptionIsSetup | NoEncryption
+
+-- Remotes that don't use encryption can use this instead of
+-- encryptionSetup.
+noEncryptionUsed :: EncryptionIsSetup
+noEncryptionUsed = NoEncryption
+
+-- Using this avoids the type-safe check, so you'd better be sure
+-- of what you're doing.
+encryptionAlreadySetup :: EncryptionIsSetup
+encryptionAlreadySetup = EncryptionIsSetup
+
 {- Encryption setup for a remote. The user must specify whether to use
  - an encryption key, or not encrypt. An encrypted cipher is created, or is
  - updated to be accessible to an additional encryption key. Or the user
  - could opt to use a shared cipher, which is stored unencrypted. -}
-encryptionSetup :: RemoteConfig -> Annex RemoteConfig
+encryptionSetup :: RemoteConfig -> Annex (RemoteConfig, EncryptionIsSetup)
 encryptionSetup c = maybe genCipher updateCipher $ extractCipher c
   where
 	-- The type of encryption
@@ -28,7 +53,7 @@ encryptionSetup c = maybe genCipher updateCipher $ extractCipher c
 	-- Generate a new cipher, depending on the chosen encryption scheme
 	genCipher = case encryption of
 		_ | M.member "cipher" c || M.member "cipherkeys" c -> cannotchange
-		Just "none" -> return c
+		Just "none" -> return (c, NoEncryption)
 		Just "shared" -> use "encryption setup" . genSharedCipher
 			=<< highRandomQuality
 		-- hybrid encryption is the default when a keyid is
@@ -48,7 +73,7 @@ encryptionSetup c = maybe genCipher updateCipher $ extractCipher c
 	cannotchange = error "Cannot set encryption type of existing remotes."
 	-- Update an existing cipher if possible.
 	updateCipher v = case v of
-		SharedCipher _ | maybe True (== "shared") encryption -> return c'
+		SharedCipher _ | maybe True (== "shared") encryption -> return (c', EncryptionIsSetup)
 		EncryptedCipher _ variant _

(Diff truncated)
clarify that sync only commits changes to files already added to the repo
diff --git a/doc/git-annex.mdwn b/doc/git-annex.mdwn
index 71f0c0b..011b6d9 100644
--- a/doc/git-annex.mdwn
+++ b/doc/git-annex.mdwn
@@ -148,7 +148,8 @@ subdirectories).
   Or specify `--fast` to sync with the remotes with the
   lowest annex-cost value.
 
-  The sync process involves first committing all local changes,
+  The sync process involves first committing any local changes to files
+  that have previously been added to the repository,
   then fetching and merging the `synced/master` and the `git-annex` branch
   from the remote repositories, and finally pushing the changes back to
   those branches on the remote repositories. You can use standard git

Added a comment
diff --git a/doc/forum/SSH_remote_transfers_queued_but_no_movement/comment_1_fea4e2317f850d6166480cddba088ae5._comment b/doc/forum/SSH_remote_transfers_queued_but_no_movement/comment_1_fea4e2317f850d6166480cddba088ae5._comment
new file mode 100644
index 0000000..d9bf5a9
--- /dev/null
+++ b/doc/forum/SSH_remote_transfers_queued_but_no_movement/comment_1_fea4e2317f850d6166480cddba088ae5._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="108.236.230.124"
+ subject="comment 1"
+ date="2014-09-18T19:41:39Z"
+ content="""
+First, take a look at the output of `ps fax` .. you should see a `git-annex assistant` process and near it there ought to be a `git annex transferkeys` process. See if that process has any children under it, like perhaps a rsync. If so, it might just be stalled talking to the host for some reason.
+
+The best way to debug it further is probably to run `git annex copy --to $remote` at the command line, passing the name of your remote repository. See if it also stalls there. If so, add a --debug and you can see the actual rsync commands it's using, and perhaps work out the problem from there.
+"""]]

Added a comment
diff --git a/doc/bugs/box.com/comment_1_d904a08519424cb9f599b2154d1ef953._comment b/doc/bugs/box.com/comment_1_d904a08519424cb9f599b2154d1ef953._comment
new file mode 100644
index 0000000..d230e52
--- /dev/null
+++ b/doc/bugs/box.com/comment_1_d904a08519424cb9f599b2154d1ef953._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="108.236.230.124"
+ subject="comment 1"
+ date="2014-09-18T19:28:56Z"
+ content="""
+Ok, I managed to reproduce this. In my case, there was no \"Bad creds\" message because the broken creds data it used happened to contain a newline, but same problem; the creds stored by the webapp are not used properly when re-enabling the box.com remote elsewhere. Same problem would affect other special remotes using embedded creds and shared encryption.
+
+Seems to be a bug introduced in [[!commit fbdeeeed5fa276d94be587c8916d725eddcaf546]]. Despite what the commit says, the embedded creds did get encrypted with the shared gpg key. I have reverted that commit to fix this problem.
+"""]]

Revert "S3, Glacier, WebDAV: Fix bug that prevented accessing the creds when the repository was configured with encryption=shared embedcreds=yes."
This reverts commit fbdeeeed5fa276d94be587c8916d725eddcaf546.
I can find no basis for that commit and think that I made it in error.
setRemoteCredPair always encrypts using the cipher from remoteCipher,
even when the cipher is shared.
diff --git a/Creds.hs b/Creds.hs
index 73d631f..7273ed9 100644
--- a/Creds.hs
+++ b/Creds.hs
@@ -23,7 +23,7 @@ import Annex.Perms
 import Utility.FileMode
 import Crypto
 import Types.Remote (RemoteConfig, RemoteConfigKey)
-import Remote.Helper.Encryptable (remoteCipher, remoteCipher', embedCreds)
+import Remote.Helper.Encryptable (remoteCipher, embedCreds)
 import Utility.Env (getEnv)
 
 import qualified Data.ByteString.Lazy.Char8 as L
@@ -85,19 +85,15 @@ getRemoteCredPair c storage = maybe fromcache (return . Just) =<< fromenv
 	fromcache = maybe fromconfig (return . Just) =<< readCacheCredPair storage
 	fromconfig = case credPairRemoteKey storage of
 		Just key -> do
-			mcipher <- remoteCipher' c
-			case (mcipher, M.lookup key c) of
-				(_, Nothing) -> return Nothing
-				(Just (_cipher, SharedCipher {}), Just bcreds) ->
-					-- When using a shared cipher, the
-					-- creds are not stored encrypted.
-					fromcreds $ fromB64 bcreds
-				(Just (cipher, _), Just enccreds) -> do
+			mcipher <- remoteCipher c
+			case (M.lookup key c, mcipher) of
+				(Nothing, _) -> return Nothing
+				(Just enccreds, Just cipher) -> do
 					creds <- liftIO $ decrypt cipher
 						(feedBytes $ L.pack $ fromB64 enccreds)
 						(readBytes $ return . L.unpack)
 					fromcreds creds
-				(Nothing, Just bcreds) ->
+				(Just bcreds, Nothing) ->
 					fromcreds $ fromB64 bcreds
 		Nothing -> return Nothing
 	fromcreds creds = case decodeCredPair creds of
diff --git a/Remote/Helper/Encryptable.hs b/Remote/Helper/Encryptable.hs
index 69216a7..dd032ce 100644
--- a/Remote/Helper/Encryptable.hs
+++ b/Remote/Helper/Encryptable.hs
@@ -71,21 +71,18 @@ encryptionSetup c = maybe genCipher updateCipher $ extractCipher c
 {- Gets encryption Cipher. The decrypted Ciphers are cached in the Annex
  - state. -}
 remoteCipher :: RemoteConfig -> Annex (Maybe Cipher)
-remoteCipher = fmap fst <$$> remoteCipher'
-
-remoteCipher' :: RemoteConfig -> Annex (Maybe (Cipher, StorableCipher))
-remoteCipher' c = go $ extractCipher c
+remoteCipher c = go $ extractCipher c
   where
 	go Nothing = return Nothing
 	go (Just encipher) = do
 		cache <- Annex.getState Annex.ciphers
 		case M.lookup encipher cache of
-			Just cipher -> return $ Just (cipher, encipher)
+			Just cipher -> return $ Just cipher
 			Nothing -> do
 				showNote "gpg"
 				cipher <- liftIO $ decryptCipher encipher
 				Annex.changeState (\s -> s { Annex.ciphers = M.insert encipher cipher cache })
-				return $ Just (cipher, encipher)
+				return $ Just cipher
 
 {- Checks if the remote's config allows storing creds in the remote's config.
  - 
diff --git a/debian/changelog b/debian/changelog
index d0bff04..91b2c89 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -8,6 +8,8 @@ git-annex (5.20140916) UNRELEASED; urgency=medium
     (Bug introduced in version 5.20140817.)
   * add: In direct mode, adding an annex symlink will check it into git,
     as was already done in indirect mode.
+  * Fix reversion in handling creds with encryption=shared embedcreds=yes
+    introduced in 5.20140817.
 
  -- Joey Hess <joeyh@debian.org>  Mon, 15 Sep 2014 14:39:17 -0400
 
diff --git a/doc/bugs/box.com.mdwn b/doc/bugs/box.com.mdwn
index 7f3bcf5..6f431b2 100644
--- a/doc/bugs/box.com.mdwn
+++ b/doc/bugs/box.com.mdwn
@@ -31,3 +31,5 @@ Mac OS X 10.9.4
 
 # End of transcript or log.
 """]]
+
+> [[fixed|done]] --[[Joey]]

Added a comment
diff --git a/doc/forum/Move_unsynced_file_in_direct_mode/comment_2_f3aec24668c35780a033f2b035df10ee._comment b/doc/forum/Move_unsynced_file_in_direct_mode/comment_2_f3aec24668c35780a033f2b035df10ee._comment
new file mode 100644
index 0000000..971e70c
--- /dev/null
+++ b/doc/forum/Move_unsynced_file_in_direct_mode/comment_2_f3aec24668c35780a033f2b035df10ee._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="xn"
+ ip="71.59.214.243"
+ subject="comment 2"
+ date="2014-09-18T19:03:30Z"
+ content="""
+Thanks for tracking down that bug and for clearing up my confusion about `annex.autocommit`, Joey.
+
+I didn't realize `annex.autocommit=true` is only used by `git annex assistant` and `git annex watch`.  I thought that running `git annex sync` with `annex.autocommit=true` would also commit the change.
+
+A few small changes to `git-annex(1)` could clarify:
+
+    sync [remote ...]
+         ...
+         The sync process involves first committing all local *staged* changes...
+
+    annex.autocommit
+       Set to false to prevent git-annex assistant and *git-annex watch* from automatically committing changes to files in the repository.
+
+"""]]

mention old-style chunking
diff --git a/doc/chunking.mdwn b/doc/chunking.mdwn
index 119a85c..71b330d 100644
--- a/doc/chunking.mdwn
+++ b/doc/chunking.mdwn
@@ -28,4 +28,16 @@ To change the chunk size, pass a `chunk=nnMiB` parameter to
 `git annex enableremote`. This only affects the chunk sized used when
 storing new content.
 
+# old-style chunking
+
+Note that older versions of git-annex used a different chunk method, which
+was configured by passing `chunksize=nnMib` when initializing a remote.
+
+The old-style chunking had a number of problems, including being less
+efficient, and not allowing resumes of encrypted uploads.
+
+It's not possible to change a remote using that old chunking method to the
+new one, but git-annex continues to support the old-style chunking to
+support such remotes.
+
 See also: [[design document|design/assistant/chunks]]

Added a comment
diff --git a/doc/bugs/Upload_to_S3_fails_/comment_2_f33ce058c9460cf7d151e739bff0440a._comment b/doc/bugs/Upload_to_S3_fails_/comment_2_f33ce058c9460cf7d151e739bff0440a._comment
new file mode 100644
index 0000000..dcf719b
--- /dev/null
+++ b/doc/bugs/Upload_to_S3_fails_/comment_2_f33ce058c9460cf7d151e739bff0440a._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="108.236.230.124"
+ subject="comment 2"
+ date="2014-09-18T18:52:17Z"
+ content="""
+If you're using the new chunking system, git-annex should support resuming the upload to S3. Next time you try to send the file, it should find the chunks that were successfully sent, and resume at the chunk where it failed.
+
+Supporting this even for encrypted uploads was a major benefit of the new chunking system, so I hope it works...?
+"""]]

Added a comment
diff --git a/doc/bugs/Upload_to_S3_fails_/comment_1_398c014921f9af957fb5e9a92ed0ef4d._comment b/doc/bugs/Upload_to_S3_fails_/comment_1_398c014921f9af957fb5e9a92ed0ef4d._comment
new file mode 100644
index 0000000..a18ca1d
--- /dev/null
+++ b/doc/bugs/Upload_to_S3_fails_/comment_1_398c014921f9af957fb5e9a92ed0ef4d._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="108.236.230.124"
+ subject="comment 1"
+ date="2014-09-18T18:49:43Z"
+ content="""
+This is using the old hS3 library. So, each chunk is sent using a new http connection. It seems that the connection must be being closed by S3 part way through the upload of a chunk.
+
+It may be that the new aws library somehow avoids this problem. So, a git-annex built with the `s3-aws` branch merged in may help with this bug. OTOH, that new branch makes a single http connection be reused for all the chunks in a file, so it might also make things worse.
+"""]]

Added a comment
diff --git a/doc/forum/Move_unsynced_file_in_direct_mode/comment_1_12a797cba753168dfde9e6339c00f481._comment b/doc/forum/Move_unsynced_file_in_direct_mode/comment_1_12a797cba753168dfde9e6339c00f481._comment
new file mode 100644
index 0000000..73a164d
--- /dev/null
+++ b/doc/forum/Move_unsynced_file_in_direct_mode/comment_1_12a797cba753168dfde9e6339c00f481._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="108.236.230.124"
+ subject="comment 1"
+ date="2014-09-18T18:27:37Z"
+ content="""
+Well, you can run `git annex assistant` or `git annex watch` and it will automatically notice the moved file and commit it. I think this is what you were trying to do when you set annex.autocommit to true (which is the default so accomplished nothing).
+
+But your example does show a bug: `git annex add` should add the dangling symlink to git in direct mode, as it already does in indirect mode. Fixed in [[!commit 44e7d6e1fe6e13091adbd572f66412e3601df3c5]].
+"""]]

Added a comment
diff --git a/doc/forum/How_do_I_sync_files_from_mobile_to_a_repo__63__/comment_5_3dcdaef370d0df38e7285f1fa11c6bb3._comment b/doc/forum/How_do_I_sync_files_from_mobile_to_a_repo__63__/comment_5_3dcdaef370d0df38e7285f1fa11c6bb3._comment
new file mode 100644
index 0000000..7bcce97
--- /dev/null
+++ b/doc/forum/How_do_I_sync_files_from_mobile_to_a_repo__63__/comment_5_3dcdaef370d0df38e7285f1fa11c6bb3._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="108.236.230.124"
+ subject="comment 5"
+ date="2014-09-18T18:05:33Z"
+ content="""
+It occurs to me that another way you could have gotten confused is, if ssh://machineB:/~/annex was eg, created in the first place by running the git-annex webapp on machineB, then it would be a direct mode repo. In this case, yes core.bare=true, but so does annex.direct=true. And that repository will not be a bare repo really; it will contain the same file tree as you have on your mobile.
+"""]]

Added a comment
diff --git a/doc/forum/How_do_I_sync_files_from_mobile_to_a_repo__63__/comment_4_404a8f9daa86c20a046b4c9f9051dfc0._comment b/doc/forum/How_do_I_sync_files_from_mobile_to_a_repo__63__/comment_4_404a8f9daa86c20a046b4c9f9051dfc0._comment
new file mode 100644
index 0000000..cbe73a0
--- /dev/null
+++ b/doc/forum/How_do_I_sync_files_from_mobile_to_a_repo__63__/comment_4_404a8f9daa86c20a046b4c9f9051dfc0._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="108.236.230.124"
+ subject="comment 4"
+ date="2014-09-18T18:00:42Z"
+ content="""
+I have double-checked, and when I already have an existing, non-bare repository, pointing the webapp at it over ssh keeps it as a non-bare repository. As I would expect.
+
+> I even tried to do git remote add B ssh://machineB:/~/annex but to no avail, the created annex on machine B becomes a bare repo.
+
+I didn't try this because it's such a violation of the way git actually works that I just can't believe it could happen. If it does, you've found the git bug of the year.
+
+But, I think you just got confused about whether the repository existed before, or gave the wrong path to the existing repository which would result in a new, bare repository being created in the location you told it.
+
+If you really think this happens, show a transcript with enough details for me, or the git developers, to reproduce the problem.
+"""]]

Added a comment
diff --git a/doc/forum/Local_and_remote_in_direct_mode/comment_3_859ec2b3a8e938073b2099fdc5781109._comment b/doc/forum/Local_and_remote_in_direct_mode/comment_3_859ec2b3a8e938073b2099fdc5781109._comment
new file mode 100644
index 0000000..f39c95c
--- /dev/null
+++ b/doc/forum/Local_and_remote_in_direct_mode/comment_3_859ec2b3a8e938073b2099fdc5781109._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="108.236.230.124"
+ subject="comment 3"
+ date="2014-09-18T17:55:21Z"
+ content="""
+Petter_petterson, I think you're mistaken about that. If you were right, that would be a massive bug in git -- nothing git-annex specific about that command after all.
+"""]]

Added a comment
diff --git a/doc/forum/Git_remote__63_____40__bitbucket__44___github__41__/comment_1_8a6de753ac0aa56f470b2aefca628388._comment b/doc/forum/Git_remote__63_____40__bitbucket__44___github__41__/comment_1_8a6de753ac0aa56f470b2aefca628388._comment
new file mode 100644
index 0000000..c6c7f6e
--- /dev/null
+++ b/doc/forum/Git_remote__63_____40__bitbucket__44___github__41__/comment_1_8a6de753ac0aa56f470b2aefca628388._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="108.236.230.124"
+ subject="comment 1"
+ date="2014-09-18T17:43:44Z"
+ content="""
+You can use any git repository as a git remote in git-annex, since git-annex uses plain old git repos.
+
+You will need to add some kind of [[special_remote|special_remotes]] to hold the content of the files stored in git-annex however.
+"""]]

Added a comment
diff --git a/doc/forum/annex_merge_creates___34__synced__47____42____34___branches/comment_3_1a0384edd20cc379e53fe7d7f650f7e2._comment b/doc/forum/annex_merge_creates___34__synced__47____42____34___branches/comment_3_1a0384edd20cc379e53fe7d7f650f7e2._comment
new file mode 100644
index 0000000..cb80c07
--- /dev/null
+++ b/doc/forum/annex_merge_creates___34__synced__47____42____34___branches/comment_3_1a0384edd20cc379e53fe7d7f650f7e2._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="108.236.230.124"
+ subject="comment 3"
+ date="2014-09-18T17:39:19Z"
+ content="""
+`git annex merge` does not create any synced/* branches. These branches will be pulled down by `git pull` or `git annex sync`.
+"""]]

Added a comment
diff --git a/doc/forum/big_overhead/comment_11_cbf25217e4149f2cfad4e2bf94f2b4ca._comment b/doc/forum/big_overhead/comment_11_cbf25217e4149f2cfad4e2bf94f2b4ca._comment
new file mode 100644
index 0000000..e2a7406
--- /dev/null
+++ b/doc/forum/big_overhead/comment_11_cbf25217e4149f2cfad4e2bf94f2b4ca._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="108.236.230.124"
+ subject="comment 11"
+ date="2014-09-18T17:32:09Z"
+ content="""
+I knew I *had* used \"Initial commit\" somewhere ... etckeeper uses that message. And commits as root. Could an etckeeper repo have somehow gotten merged into your git-annex repo? Seems strange, and the filenames and contents don't really look like /etc to me, but it otherwise somewhat fits.
+"""]]

Added a comment
diff --git a/doc/forum/big_overhead/comment_10_d5f4e353e7f711d8c38cdcc222339bca._comment b/doc/forum/big_overhead/comment_10_d5f4e353e7f711d8c38cdcc222339bca._comment
new file mode 100644
index 0000000..2ebd56d
--- /dev/null
+++ b/doc/forum/big_overhead/comment_10_d5f4e353e7f711d8c38cdcc222339bca._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="108.236.230.124"
+ subject="comment 10"
+ date="2014-09-18T17:27:36Z"
+ content="""
+In the meantime, I've been looking over the Annex.Branch code. 
+
+`stageJournal` is only ever called in code paths that commit the updated index, so those code paths cannot result in dangling objects unless git-annex is interrupted before it can commit. (This may explain some of my own repos having a few dangling refs, that were not commits; I could have ctrl-c'd git-annex.)
+
+It's possible for a forced update of the local git-annex branch, done by eg a push from another repo, to overwrite a commit made to it. In this case, the git-annex index is merged with the branch, resulting in a new commit, and the old commit that was overwritten will indeed be dangling. However, `git annex sync` doesn't overwrite the git-annex branch; it pushes to synced/git-annex, or does a `taggedPush` to a private ref. It is the case that both those pushes are forced pushes, so can overwrite a branch ref and leave the old commit it pointed to dangling. In the case of `taggedPush`, the old commit should be a parent of the new, so it won't dangle. In the case of synced/git-annex being overwritten, the old commit could dangle, but only until whatever repo pushed it syncs again, at which time it should get incorporated as one of the parents of the new synced/git-annex it pushes. So, I don't see how long-term dangling commits could happen this way, except for in the case where a repository stops syncing/goes missing/rebases its git-annex branch (ie, git-annex forget is used). (This may explain the 2 dangling commits I found on elephant; we did delete some clones of that repository recently.)
+
+At this point I'm not convinced that the dangling objects I found in my own repos are due to some systematic problem, the above seems like it could explain them, and the above is not a problem on the class of the one Rasmus is having. Of course, it's hard to be sure you've spotted all possible ways that a resource leak can happen, and that's what these dangling objects basically are.
+"""]]

Added a comment
diff --git a/doc/forum/big_overhead/comment_9_5fa681ea0d6bd0dcac7142d40df9d54f._comment b/doc/forum/big_overhead/comment_9_5fa681ea0d6bd0dcac7142d40df9d54f._comment
new file mode 100644
index 0000000..856f326
--- /dev/null
+++ b/doc/forum/big_overhead/comment_9_5fa681ea0d6bd0dcac7142d40df9d54f._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="108.236.230.124"
+ subject="comment 9"
+ date="2014-09-18T16:54:10Z"
+ content="""
+That is a very strange commit by every metric. Weird author, weird date, weird filenames in it (not files that git-annex uses!), with apparently some weird binary content (which git-annex would not be committing). Even a weird commit message -- git-annex never makes a commit with a message of \"Initial commit\", and as far as I can tell using `git log -S`, it never has. (OTOH, it's a pretty common example message used in eg, git documentation.) So, I feel pretty sure that dangling commit was not made by git-annex.
+
+I think you need to take a look at some of the 4+mb unreachable blobs, to get some idea of what these files are. One way is to use git-show on the hash of one of the blobs to get its content, and then, perhaps pass it to `file` or `strings`. Or, you could stop the assistant, `git checkout 478425bef867782e8ff22aca24316e9421288c49` and have a look at this strange tree that was apparently committed in 2012 to see what's in there.
+
+It might be possible that the dangling commits come somehow from the remote server. I'm not 100% sure, but I think that a git pack can end up with dangling objects in it, and then git can pull down that pack to get other, non-dangling objects. You should use `git show` on the server on some of the dangling shas to see if they are present there.
+"""]]

retitle
diff --git a/doc/forum/big_overhead.mdwn b/doc/forum/big_overhead.mdwn
index 0c5b742..f16b959 100644
--- a/doc/forum/big_overhead.mdwn
+++ b/doc/forum/big_overhead.mdwn
@@ -1,3 +1,5 @@
+[[!meta title="unreachable git objects"]]
+
 Hi,
 
 I am been seeing quite big overheads using `git-annex`.  Is this is normal?

Added a comment
diff --git a/doc/forum/big_overhead/comment_8_4a66f57c6c0bdc6123618cb69a719be5._comment b/doc/forum/big_overhead/comment_8_4a66f57c6c0bdc6123618cb69a719be5._comment
new file mode 100644
index 0000000..fdbebf4
--- /dev/null
+++ b/doc/forum/big_overhead/comment_8_4a66f57c6c0bdc6123618cb69a719be5._comment
@@ -0,0 +1,65 @@
+[[!comment format=mdwn
+ username="rasmus"
+ ip="217.130.110.20"
+ subject="comment 8"
+ date="2014-09-18T11:28:45Z"
+ content="""
+Hi Joey,
+
+Thanks for your careful reply.  
+
+Easy things first:
+
+I *never* add anything from the terminal, though I may do checks and `git annex get`, since sometimes the assistance actually grab the updated files.  Until recently I started git annex automatically on boot, but at the moment it simply renders my laptop useless for too long -- presumably due to the errors investigated here.
+
+I use btrfs (don't ask me why).  Searching online, I did not find a way to find the size of inodes, but I assume that it's sensible?  tune2fs doesn't work but as I understand it is designed for ext*.
+
+What takes up space in my `.git/objects` is files of several Mb.  So at the moment the `pack` folder is 700mb.  In the next biggest folder there's three files that are 73,4mb and 8 files that are 4kb.  This pattern repeats.  A couple of large files (73,4 shows up quite a bit as well as 45) and many small files. 
+
+I have an astonishing amount of dangling objects.  In the `doc.annex` `git rev-list HEAD --count` gives 27354.  In this repo I have 1108 unreachable blobs and commits, respectively 569 and 539.  This probably explains why `git prune` solves my problem but I don't understand why all these large files reappears when I sync -- even after having run `git prune` on both laptops.  Could they come from the `annex` on my remote server?
+
+`git show` isn't nice on blobs, but here is an example of a dangling commit
+
+
+    commit 478425bef867782e8ff22aca24316e9421288c49
+    Author: root <root@localhost>
+    Date:   Mon Dec 31 19:00:01 2012 -0400
+
+        Initial commit
+
+    diff --git a/6e5039464b41f39088a4aece64ced787aa2b04ec2dd5ac6f6c6ca4b9a06a99e5 b/6e5039464b41f39088a4aece64ced787aa2b04ec2dd5ac6f6c6ca4b9a06a99e5
+    new file mode 100644
+    index 0000000..af12763
+    Binary files /dev/null and b/6e5039464b41f39088a4aece64ced787aa2b04ec2dd5ac6f6c6ca4b9a06a99e5 differ
+    diff --git a/8ae4ee273eb540fb71b78152d10010ea2dd3d1bb82afe410ecf3d811cb72bd6d b/8ae4ee273eb540fb71b78152d10010ea2dd3d1bb82afe410ecf3d811cb72bd6d
+    new file mode 100644
+    index 0000000..0a6af91
+    Binary files /dev/null and b/8ae4ee273eb540fb71b78152d10010ea2dd3d1bb82afe410ecf3d811cb72bd6d differ
+    diff --git a/91bd0c092128cf2e60e1a608c31e92caf1f9c1595f83f2890ef17c0e4881aa0a b/91bd0c092128cf2e60e1a608c31e92caf1f9c1595f83f2890ef17c0e4881aa0a
+    new file mode 100644
+    index 0000000..26d921e
+    Binary files /dev/null and b/91bd0c092128cf2e60e1a608c31e92caf1f9c1595f83f2890ef17c0e4881aa0a differ
+    diff --git a/9f7728197cfcd9792eef1ff5930a4ab580e38e64291037130f1ad0914e34a1fc b/9f7728197cfcd9792eef1ff5930a4ab580e38e64291037130f1ad0914e34a1fc
+    new file mode 100644
+    index 0000000..2a92974
+    Binary files /dev/null and b/9f7728197cfcd9792eef1ff5930a4ab580e38e64291037130f1ad0914e34a1fc differ
+    diff --git a/ac801235d97275e761efa12a76ee009472cae8549a0835d5be8bd3f6657047fb b/ac801235d97275e761efa12a76ee009472cae8549a0835d5be8bd3f6657047fb
+    new file mode 100644
+    index 0000000..543430c
+    Binary files /dev/null and b/ac801235d97275e761efa12a76ee009472cae8549a0835d5be8bd3f6657047fb differ
+    diff --git a/d400d0f616a980ea5e3ef68a1f9d670d1eeccbd27f34d1cb7ea976e1f98e2fb7 b/d400d0f616a980ea5e3ef68a1f9d670d1eeccbd27f34d1cb7ea976e1f98e2fb7
+    new file mode 100644
+    index 0000000..7b7eadd
+    Binary files /dev/null and b/d400d0f616a980ea5e3ef68a1f9d670d1eeccbd27f34d1cb7ea976e1f98e2fb7 differ
+    diff --git a/e988a26fbabe3f498e2a564096948eafb289ccadfb186423c1f63c5a3b2c19db b/e988a26fbabe3f498e2a564096948eafb289ccadfb186423c1f63c5a3b2c19db
+    new file mode 100644
+    index 0000000..3bd1dfa
+    Binary files /dev/null and b/e988a26fbabe3f498e2a564096948eafb289ccadfb186423c1f63c5a3b2c19db differ
+
+There are several things I don't understand.  Why is the author root?  I never run `git annex` with `sudo` or as root.  I think the date is bogus.  I'm pretty sure I wasn't even running `git annex` in 2012 much less working with this repo. . . What is weird is that this is the date for *all* lost commits!  (Same for Author).  Over all lost commits there are 2352 binary files that differ.  Of these there are 284 unique hashes. . .  I don't know what this means other than my repo being seriously messed up.  I don't understand what I did wrong to end up in this state as I have been fairly careful in mainly using the `webapp`.
+
+I wonder if the best way to proceed is to start over, or whether this repo can be recovered.
+
+Thanks,
+Rasmus
+"""]]

Added a comment
diff --git a/doc/devblog/day_219__catching_up_and_looking_back/comment_5_7997305d7ec7db072b78dd0c31ecd824._comment b/doc/devblog/day_219__catching_up_and_looking_back/comment_5_7997305d7ec7db072b78dd0c31ecd824._comment
new file mode 100644
index 0000000..91e4dc5
--- /dev/null
+++ b/doc/devblog/day_219__catching_up_and_looking_back/comment_5_7997305d7ec7db072b78dd0c31ecd824._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="anarcat"
+ ip="70.83.139.100"
+ subject="comment 5"
+ date="2014-09-17T20:53:01Z"
+ content="""
+i haven't tried it at all - only looked at [this one demo video](https://www.youtube.com/watch?v=yxSzQIwXM1k) that reminded me of git-annex a lot...
+"""]]

Added a comment: Camlistore
diff --git a/doc/devblog/day_219__catching_up_and_looking_back/comment_4_23c4ede3db0ea8165311466881cfa6a2._comment b/doc/devblog/day_219__catching_up_and_looking_back/comment_4_23c4ede3db0ea8165311466881cfa6a2._comment
new file mode 100644
index 0000000..8e24916
--- /dev/null
+++ b/doc/devblog/day_219__catching_up_and_looking_back/comment_4_23c4ede3db0ea8165311466881cfa6a2._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmH7o6q2l99M-PQolOfbR3_i5B_jtTIcAE"
+ nickname="Giovanni"
+ subject="Camlistore"
+ date="2014-09-17T20:36:43Z"
+ content="""
+anarcat, have you used it? I tried, but it is buggy. They seem to be at [\"the Archivist\"](http://git-annex.branchable.com/) group of people, but if you don't have a hard drive to store the things, everything breaks up. I paid a lot of money to Amazon because I believed I could use Camlistore to organize data stored at S3, but apparently S3 is \"just for backup\", and if it is your only storage, then Camlistore will keep fetching data over and over \"to index it\" and in the end you pay.
+
+Yes, it keeps working, so you need some server online at all times, with Camlistore running.
+"""]]

Added a comment
diff --git a/doc/forum/big_overhead/comment_7_a762eb55addf81c1c5350c7968598d0f._comment b/doc/forum/big_overhead/comment_7_a762eb55addf81c1c5350c7968598d0f._comment
new file mode 100644
index 0000000..1ec6a6e
--- /dev/null
+++ b/doc/forum/big_overhead/comment_7_a762eb55addf81c1c5350c7968598d0f._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="108.236.230.124"
+ subject="comment 7"
+ date="2014-09-17T20:20:40Z"
+ content="""
+There are a few things that can cause git to leave unreachable objects. These include: Rebasing; interrupting a pull before it updates the refs; running git add on a file and then changing the file's content and adding it a second time before committing.
+
+I can think of one case where this happens when using git-annex at the command line: `git annex add $file; git mv $file other-directory; git commit` will result in a dangling object storing the old symlink target before the file was moved.
+
+It'd be useful to investigate, by using `git fsck --unreachable` to get a list of currently unreachable objects, and then use `git show` to look at the objects and try to determine where they came from. Ie, are they symlink targets or are they git-annex location log files (formatted as columns of timestamps and uuids). Any unreachable commits would be the most useful to investigate.
+
+I see a few loose objects here and there in my annexes, but not very many, and git-gc has cleaned up old ones (> 1 month old). Some of them seem to be location log files. I see those in both repositories where I use the assistant, and repositories where I use only command line git-annex. I was able to find 2 unreachable commits in a repository that runs the assistant full-time; both commits were \"merging origin/synced/git-annex into git-annex\". This suggests to me that perhaps the assistant merged the git-annex branch but that merge was overwritten by another thread that committed changes to the branch at the same time.
+
+You should also check the size of inodes on your system; a thousand small loose objects in .git/objects does not normally take up gigabytes of space; with typical inode sizes it might use up a few megabytes. With 1 mb inodes, those same thousand files would use 1 gb..
+"""]]

Added a comment: camlistore
diff --git a/doc/devblog/day_219__catching_up_and_looking_back/comment_3_9699d5a9de5ea64fbc876352e20261c4._comment b/doc/devblog/day_219__catching_up_and_looking_back/comment_3_9699d5a9de5ea64fbc876352e20261c4._comment
new file mode 100644
index 0000000..91fc494
--- /dev/null
+++ b/doc/devblog/day_219__catching_up_and_looking_back/comment_3_9699d5a9de5ea64fbc876352e20261c4._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="anarcat"
+ ip="70.83.139.100"
+ subject="camlistore"
+ date="2014-09-17T20:18:56Z"
+ content="""
+have you looked at [camlistore](http://camlistore.org/) at all? it's a fairly new project, but it seems like it could be an interesting backend, or at least inspiration for git-annex's design. --[[anarcat]]
+"""]]

Added a comment
diff --git a/doc/forum/annex_merge_creates___34__synced__47____42____34___branches/comment_2_cb6971a766a28bd8c094d0b986272c65._comment b/doc/forum/annex_merge_creates___34__synced__47____42____34___branches/comment_2_cb6971a766a28bd8c094d0b986272c65._comment
new file mode 100644
index 0000000..5db94a7
--- /dev/null
+++ b/doc/forum/annex_merge_creates___34__synced__47____42____34___branches/comment_2_cb6971a766a28bd8c094d0b986272c65._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlog_5wIICaMcrKTexlFNA6IO6UTp323aE"
+ nickname="Torkaly"
+ subject="comment 2"
+ date="2014-09-17T08:47:03Z"
+ content="""
+Thank you for the answer.
+
+There are no origin/synced/* branches, only a origin/git-annex and the local git-annex branch. What i need git annex merge to do, is to merge the fetched remote git-annex with the local git-annex. There is no need for creating or merging the synced-branches as there are no.
+
+"""]]

removed
diff --git a/doc/bugs/cotinually_prompting_for_gpg_passphrase/comment_1_ef6b4df2ff78acf9f211c8e5f35b13c7._comment b/doc/bugs/cotinually_prompting_for_gpg_passphrase/comment_1_ef6b4df2ff78acf9f211c8e5f35b13c7._comment
deleted file mode 100644
index 22ea351..0000000
--- a/doc/bugs/cotinually_prompting_for_gpg_passphrase/comment_1_ef6b4df2ff78acf9f211c8e5f35b13c7._comment
+++ /dev/null
@@ -1,8 +0,0 @@
-[[!comment format=mdwn
- username="pot"
- ip="83.170.117.176"
- subject="comment 1"
- date="2014-09-17T03:51:37Z"
- content="""
-I know this was answered, but I just returned to read (and implement) the solution, and it's gone - currently I can't see any responses to this topic. Did it get deleted sowehow?
-"""]]

Added a comment
diff --git a/doc/bugs/cotinually_prompting_for_gpg_passphrase/comment_1_ef6b4df2ff78acf9f211c8e5f35b13c7._comment b/doc/bugs/cotinually_prompting_for_gpg_passphrase/comment_1_ef6b4df2ff78acf9f211c8e5f35b13c7._comment
new file mode 100644
index 0000000..22ea351
--- /dev/null
+++ b/doc/bugs/cotinually_prompting_for_gpg_passphrase/comment_1_ef6b4df2ff78acf9f211c8e5f35b13c7._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="pot"
+ ip="83.170.117.176"
+ subject="comment 1"
+ date="2014-09-17T03:51:37Z"
+ content="""
+I know this was answered, but I just returned to read (and implement) the solution, and it's gone - currently I can't see any responses to this topic. Did it get deleted sowehow?
+"""]]

Added a comment
diff --git a/doc/forum/usability:_creating_an_archive_on_a_new_external_drive/comment_2_b3a6b5ff0aaddd78903fc7bc7fbd6ee2._comment b/doc/forum/usability:_creating_an_archive_on_a_new_external_drive/comment_2_b3a6b5ff0aaddd78903fc7bc7fbd6ee2._comment
new file mode 100644
index 0000000..e264c8f
--- /dev/null
+++ b/doc/forum/usability:_creating_an_archive_on_a_new_external_drive/comment_2_b3a6b5ff0aaddd78903fc7bc7fbd6ee2._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://id.koumbit.net/anarcat"
+ ip="70.83.139.100"
+ subject="comment 2"
+ date="2014-09-16T20:35:23Z"
+ content="""
+i wouldn't expect those changes to be committed. it's an external drive, and unless i manually sync it, it should take into account my changes.
+
+i am more surprised by the bare repository than i would be surprised by my changes not propagating back, i think. --[[anarcat]]
+"""]]

devblog
diff --git a/doc/devblog/day_220__working_through_backlog.mdwn b/doc/devblog/day_220__working_through_backlog.mdwn
new file mode 100644
index 0000000..4685e3f
--- /dev/null
+++ b/doc/devblog/day_220__working_through_backlog.mdwn
@@ -0,0 +1,14 @@
+Made a release yesterday, which was all bugfixes.
+
+Today, a few more bug fixes. Looked into making the webapp
+create non-bare repositories on removable drives, but before I got too far
+into the code, I noticed [there's a big problem with that idea](http://git-annex.branchable.com/forum/usability:_creating_an_archive_on_a_new_external_drive/).
+
+Rest of day was spent getting caught up on forum posts etc. I'm happy to
+read lots of good answers that have been posted while I've been away.
+Here's an excellent example: <http://git-annex.branchable.com/install/fromsource/#comment-5f8ceb060643ae71cd2adc72f0fca3f0>
+
+That led to rewriting the docs for building git-annex from source.
+New page: [[install/fromsource]].
+
+Backlog is now down to 117.

Added a comment
diff --git a/doc/forum/adding_files_without_hashing_them/comment_1_c3113d7aff6b64a325a32b8b281df605._comment b/doc/forum/adding_files_without_hashing_them/comment_1_c3113d7aff6b64a325a32b8b281df605._comment
new file mode 100644
index 0000000..56577ca
--- /dev/null
+++ b/doc/forum/adding_files_without_hashing_them/comment_1_c3113d7aff6b64a325a32b8b281df605._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.22"
+ subject="comment 1"
+ date="2014-09-16T19:50:41Z"
+ content="""
+You can edit files that use the WORM backend, as long as the editing changes their size or mtime, or both. If neither changes, git-annex won't be able to keep your edits separate when using WORM.
+
+A perhaps safer compromise can be to use the WORM backend initially, but them `git annex migrate --backend=SHA256E` when you have spare CPU cycles. 
+
+Or, when you commit a change to a file that had been using WORM, use `git annex add $wormy_file --backend=SHA256E` to make the new version use the better backend.
+"""]]