Recent changes to this wiki:

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.
+"""]]

Added a comment
diff --git a/doc/install/fromsource/comment_46_954de34275d33bc4590927f911761563._comment b/doc/install/fromsource/comment_46_954de34275d33bc4590927f911761563._comment
new file mode 100644
index 0000000..c0f283f
--- /dev/null
+++ b/doc/install/fromsource/comment_46_954de34275d33bc4590927f911761563._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.22"
+ subject="comment 46"
+ date="2014-09-16T19:33:11Z"
+ content="""
+Britt's comment is spot on, but git-annex tries pretty hard to work with lots of older versions of haskell libraries, as well as the latest and greatest. So it should be ok to install haskell libraries with apt-get and use them to build git-annex, as the (revised) instructions above show.
+
+What tends not to work so well is use apt-get to install older versions of haskell libraries and then cabal install on top to add newer stuff. Gets complicated and I'd recommend not going there. The instructions above show using either apt-get or cabal to install the haskell libraries, but not both.
+"""]]

Added a comment: no need for c2hs
diff --git a/doc/install/fromsource/comment_45_d9cccbb9620cc8218e72b5380fd89a05._comment b/doc/install/fromsource/comment_45_d9cccbb9620cc8218e72b5380fd89a05._comment
new file mode 100644
index 0000000..e8666b0
--- /dev/null
+++ b/doc/install/fromsource/comment_45_d9cccbb9620cc8218e72b5380fd89a05._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.22"
+ subject="no need for c2hs"
+ date="2014-09-16T19:28:09Z"
+ content="""
+The c2hs mentioned in some of the above comments is not needed any longer; ghc 7.6.3 and newer come with a hsc2hs command that is used.
+"""]]

Added a comment
diff --git a/doc/forum/git-annex_in_sane_language_for_mere_humans_of_us__63__/comment_6_25ce5eddeb1b65aacd5d86e09c3719b8._comment b/doc/forum/git-annex_in_sane_language_for_mere_humans_of_us__63__/comment_6_25ce5eddeb1b65aacd5d86e09c3719b8._comment
new file mode 100644
index 0000000..f9fa78e
--- /dev/null
+++ b/doc/forum/git-annex_in_sane_language_for_mere_humans_of_us__63__/comment_6_25ce5eddeb1b65aacd5d86e09c3719b8._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.22"
+ subject="comment 6"
+ date="2014-09-16T19:19:00Z"
+ content="""
+There is too much negativity on this page, starting perhaps with its title.
+
+The \"this is not recommended\" is not because we don't want people to build git-annex from source. It's to try to dissuade users who just want to get git-annex installed, and who would be scared off by a transient build failure, from building from source, when there are many builds provided by Linux distributions, etc that would be better choices for them to get started. Hopefully the new page and new wording gets this across better: \"Experienced users should not find it too hard to build and install it from source.\"
+
+If someone wants to reimplement git-annex, or parts of it, I think that the existing documentation (eg [[internals]]) should get them most of the way there.
+
+"""]]

comment reorg
diff --git a/doc/install/cabal/comment_10_7ebe353b05d4df29897dc9a4f45c8a91._comment b/doc/install/cabal/comment_10_7ebe353b05d4df29897dc9a4f45c8a91._comment
deleted file mode 100644
index 5b813ba..0000000
--- a/doc/install/cabal/comment_10_7ebe353b05d4df29897dc9a4f45c8a91._comment
+++ /dev/null
@@ -1,8 +0,0 @@
-[[!comment format=mdwn
- username="http://joeyh.name/"
- ip="4.152.246.110"
- subject="comment 10"
- date="2013-07-27T17:49:07Z"
- content="""
-@Henning; see the [[OSX]] page for full installation instructions for OSX. Which include all the neccesary brew incantations.
-"""]]
diff --git a/doc/install/cabal/comment_11_0d06702e6e0ae3cd331cf748a9f6f273._comment b/doc/install/cabal/comment_11_0d06702e6e0ae3cd331cf748a9f6f273._comment
deleted file mode 100644
index 9491971..0000000
--- a/doc/install/cabal/comment_11_0d06702e6e0ae3cd331cf748a9f6f273._comment
+++ /dev/null
@@ -1,44 +0,0 @@
-[[!comment format=mdwn
- username="https://www.google.com/accounts/o8/id?id=AItOawlXEIT2PEAuHuInLP4UYVzWE0lceMYd2lA"
- nickname="Gregor"
- subject="Installation on tonidoplug"
- date="2013-08-03T07:19:54Z"
- content="""
-I tried various ways to install git-annex on my [TonidoPlug](http://www.tonidoplug.com/).
-
-System Info:
-
-	root@TonidoPlug2:~# uname -a
-	Linux TonidoPlug2 2.6.31.8-topkick1281p2-001-004-20101214 #1 Thu Jun 16 10:06:20 CST 2011 armv5tel GNU/Linux
-
-`apt-get` didn't work.
-
-	root@TonidoPlug2:~# apt-get install git-annex
-	Reading package lists... Done
-	Building dependency tree       
-	Reading state information... Done
-	E: Unable to locate package git-annex
-
-The Linux standalone installation results in an error message like this, when calling `git-annex` (or `git annex`)
-
-	~$ git-annex.linux/git-annex
-	/home/gitolite/git-annex.linux/bin/git-annex: 1: Syntax error: \")\" unexpected
-
-(git-annex.linux/bin/git-annex is a binary file and works fine on other distros)
-
-When installing with cabal, I get the error message (tried as root and gitolite user)
-
-	~$ cabal install git-annex --bindir=$HOME/bin -f\"-assistant -webapp -webdav -pairing -xmpp -dns\"
-	Resolving dependencies...
-	cabal: cannot configure git-annex-4.20130802. It requires base >=4.5 && <4.8
-	For the dependency on base >=4.5 && <4.8 there are these packages:
-	base-4.5.0.0, base-4.5.1.0, base-4.6.0.0 and base-4.6.0.1. However none of
-	them are available.
-	base-4.5.0.0 was excluded because of the top level dependency base -any
-	base-4.5.1.0 was excluded because of the top level dependency base -any
-	base-4.6.0.0 was excluded because of the top level dependency base -any
-	base-4.6.0.1 was excluded because of the top level dependency base -any
-
-Any help is appreciated.
-Thanks for providing git-annex. I started cleaning up my backups with it yesterday and really like it.
-"""]]
diff --git a/doc/install/cabal/comment_12_b93ca271dffca3f948645d3e1326c1d9._comment b/doc/install/cabal/comment_12_b93ca271dffca3f948645d3e1326c1d9._comment
deleted file mode 100644
index 8d9c978..0000000
--- a/doc/install/cabal/comment_12_b93ca271dffca3f948645d3e1326c1d9._comment
+++ /dev/null
@@ -1,12 +0,0 @@
-[[!comment format=mdwn
- username="http://joeyh.name/"
- ip="2001:4978:f:21a::2"
- subject="comment 12"
- date="2013-08-07T16:31:30Z"
- content="""
-The Linux standalone builds for i386 and amd64 will not work on Arm systems.
-
-There are builds of git-annex for arm in eg, Debian. You should be able to use one of those if this system is running Debian. You may need to upgrade to eg, Debian stable, which includes git-annex.
-
-It looks like you have an old and/or broken GHC compiler too. You could upgrade that to a newer version (eg from Debian stable) and build it that way, but it seems like the long way around if you have a Debian system there.
-"""]]
diff --git a/doc/install/cabal/comment_13_3dac019cda71bf99878c0a1d9382323b._comment b/doc/install/cabal/comment_13_3dac019cda71bf99878c0a1d9382323b._comment
deleted file mode 100644
index 80e3a6a..0000000
--- a/doc/install/cabal/comment_13_3dac019cda71bf99878c0a1d9382323b._comment
+++ /dev/null
@@ -1,8 +0,0 @@
-[[!comment format=mdwn
- username="https://www.google.com/accounts/o8/id?id=AItOawlXEIT2PEAuHuInLP4UYVzWE0lceMYd2lA"
- nickname="Gregor"
- subject="TonidoPlug"
- date="2013-08-09T17:46:28Z"
- content="""
-@Joey Thanks for the answer. I didn't want to mess around too much with the TonidoPlug. I am currently setting up a raspberry pi, which works fine. 
-"""]]
diff --git a/doc/install/cabal/comment_14_14b46470593f84f8c3768a91cb77bdab._comment b/doc/install/cabal/comment_14_14b46470593f84f8c3768a91cb77bdab._comment
deleted file mode 100644
index 93fca16..0000000
--- a/doc/install/cabal/comment_14_14b46470593f84f8c3768a91cb77bdab._comment
+++ /dev/null
@@ -1,9 +0,0 @@
-[[!comment format=mdwn
- username="https://www.google.com/accounts/o8/id?id=AItOawlfIVXjkzrYE9qJAO2A0H7K6tKGMaSgc3U"
- nickname="Daniel"
- subject="Problems with cryptocipher"
- date="2013-08-22T01:36:50Z"
- content="""
-I had problems following these directions on recent releases of Fedora/Ubuntu. The install attempts failed on cryptocipher-0.3.1, which I think came as a dependency of Yesod.
-I was able to work around this by installing yesod-platform with cabal first, then installing git-annex.
-"""]]
diff --git a/doc/install/cabal/comment_15_c3a5b0aad28a90e0bb8da31a430578eb._comment b/doc/install/cabal/comment_15_c3a5b0aad28a90e0bb8da31a430578eb._comment
deleted file mode 100644
index fc64af2..0000000
--- a/doc/install/cabal/comment_15_c3a5b0aad28a90e0bb8da31a430578eb._comment
+++ /dev/null
@@ -1,8 +0,0 @@
-[[!comment format=mdwn
- username="RaspberryPie"
- ip="77.247.181.162"
- subject="git-annex assistant on Arm"
- date="2013-08-23T03:07:11Z"
- content="""
-I'd like to use the assistant's power on a Raspberry Pi to build an always-on file/sync server. Is there a way to get the assistant running on Arm? I know there's a Debian package, but it's Version 3.20120629 and comes without the assistant. Has anyone ever successfully built a recent git-annex version on Arm? What would I need in order to do it myself? 
-"""]]
diff --git a/doc/install/cabal/comment_16_4faf214f97f9516898d7c17d743ef825._comment b/doc/install/cabal/comment_16_4faf214f97f9516898d7c17d743ef825._comment
deleted file mode 100644
index be14b39..0000000
--- a/doc/install/cabal/comment_16_4faf214f97f9516898d7c17d743ef825._comment
+++ /dev/null
@@ -1,10 +0,0 @@
-[[!comment format=mdwn
- username="http://joeyh.name/"
- ip="4.154.0.63"
- subject="comment 16"
- date="2013-08-23T17:37:52Z"
- content="""
-The git-annex assistant can easily be built on arm. But not the webapp. It's entirely possible to use the assistant without the webapp though; you just have to make the git repository and configure the remotes by hand, and then the assistant will sync them the same way the webapp does.
-
-It is possible but very involved to build the webapp for arm. I do not anticipate doing it in the Debian package until ghc gets proper template haskell support for arm. See [[forum/Webapp_on_ARM]]
-"""]]
diff --git a/doc/install/cabal/comment_17_2a9d6807a3a13815c824985521757167._comment b/doc/install/cabal/comment_17_2a9d6807a3a13815c824985521757167._comment
deleted file mode 100644
index c0b570d..0000000
--- a/doc/install/cabal/comment_17_2a9d6807a3a13815c824985521757167._comment
+++ /dev/null
@@ -1,10 +0,0 @@
-[[!comment format=mdwn
- username="RaspberryPie"
- ip="77.247.181.162"
- subject="comment 17"
- date="2013-08-23T18:51:51Z"
- content="""
-Thanks for the quick answer. I will try to build git-annex with just the assistant, as you suggest, and once it works set up the server by hand as you suggest. 
-
-BTW: Awesome job you're doing with git-annex. I appreciate your enthusiasm.
-"""]]
diff --git a/doc/install/cabal/comment_18_1efa0c7a963ec452fc6336fbe4964f6e._comment b/doc/install/cabal/comment_18_1efa0c7a963ec452fc6336fbe4964f6e._comment
deleted file mode 100644
index e3a523e..0000000
--- a/doc/install/cabal/comment_18_1efa0c7a963ec452fc6336fbe4964f6e._comment
+++ /dev/null
@@ -1,10 +0,0 @@
-[[!comment format=mdwn
- username="RaspberryPie"
- ip="96.47.226.20"
- subject="git-annex assistant for the Raspberry Pi"
- date="2013-09-04T03:58:37Z"
- content="""
-It took a while and a few tries, but I finally built the git-annex binary including the assistant on a Raspberry Pi. The build comes without the flags webapp, webdav, and dbus as these rely on a Template Haskell compiler that hasn't been ported to Arm architecture yet. 
-
-I put the binary up on Github in case anyone's interested: <https://github.com/tradloff/git-annex-RPi>
-"""]]
diff --git a/doc/install/cabal/comment_19_6f42f9234f9ff6a2ca6bbb4d2643843e._comment b/doc/install/cabal/comment_19_6f42f9234f9ff6a2ca6bbb4d2643843e._comment
deleted file mode 100644
index 27a3e8c..0000000
--- a/doc/install/cabal/comment_19_6f42f9234f9ff6a2ca6bbb4d2643843e._comment
+++ /dev/null
@@ -1,44 +0,0 @@
-[[!comment format=mdwn
- username="https://www.google.com/accounts/o8/id?id=AItOawlu7K3h7Ry1uDAU_ERYGuqt0LoGNJqGuRo"
- nickname="Nathan"
- subject="Cabal installing git-annex on Ubuntu 12.04 Precise with GHC 7.6.3"
- date="2013-09-25T22:39:04Z"
- content="""
-I now realize [there is a Ubuntu 12.04 Precise PPA with a current
-version of
-git-annex](http://git-annex.branchable.com/install/Ubuntu/), so that's
-probably a better choice, but here's how I cabal isntalled git-annex.
-
-1. Apt install non-cabal dependencies:
-
-       sudo aptitude install c2hs libgsasl7-dev libxml2-dev
-
-2. Manually cabal install yesod-platform to avoid the [cryptocipher problem 
-   mentioned above](
-   http://git-annex.branchable.com/install/cabal/#comment-1807da37dc144b572b76aaf4b574bb54):
-
-       cabal install yesod-platform
-

(Diff truncated)
improve
diff --git a/doc/install/fromsource.mdwn b/doc/install/fromsource.mdwn
index baa4e1b..98a517b 100644
--- a/doc/install/fromsource.mdwn
+++ b/doc/install/fromsource.mdwn
@@ -31,7 +31,8 @@ First, install everything git-annex needs to build:
 
 	sudo apt-get build-dep git-annex
 
-Now you can build git-annex using either `make` or `cabal build`.
+Now you can build git-annex by running either `make` or `cabal build`
+inside the source tree.
 
 ## minimal build with cabal
 
@@ -39,24 +40,29 @@ This can be done anywhere, and builds git-annex without some features that
 require C libraries, that can be harder to get installed. This is plenty to
 get started using it, although it does not include the assistant or webapp.
 
-Be warned that this involves building a lot of Haskell libraries from
-source, and so it has a lot of moving parts, and it's not uncommon for it
-to be broken from time to time.
+Inside the source tree, run:
 
 	cabal configure -f"-assistant -webapp -webdav -pairing -xmpp -dns"
+	cabal install --only-dependencies
 	cabal build
 	PATH=$HOME/bin:$PATH
 	cabal install --bindir=$HOME/bin
 
+Be warned that this involves building a lot of Haskell libraries from
+source, and so it has a lot of moving parts, and it's not uncommon for it
+to be broken from time to time.
+
 ## full build with cabal
 
 To build with all features enabled, including the assistant and webapp,
 you will need to install several C libraries and their headers,
 including libgnutls, libgsasl, libxml2, and zlib. How to do that for
-your OS is beyond the scope of this page. Once the C libraries are
-installed:
+your OS is beyond the scope of this page. 
+
+Once the C libraries are installed, run inside the source tree:
 
 	cabal configure
+	cabal install --only-dependencies
 	cabal build
 	PATH=$HOME/bin:$PATH
 	cabal install --bindir=$HOME/bin

reorg and rewrote build-from-source instructions
diff --git a/doc/contribute.mdwn b/doc/contribute.mdwn
index 71bce6c..bc08734 100644
--- a/doc/contribute.mdwn
+++ b/doc/contribute.mdwn
@@ -24,7 +24,8 @@ you'll make Joey more productive!
 
 ## code contributions
 
-[[download]] the source code and send patches!
+[[download]] the source code, [[build|install/fromsource]] it
+and send patches!
 
 If you know Haskell, git-annex has lots of Haskell code that
 could be improved. See the [[coding_style]] and have at it.
diff --git a/doc/install.mdwn b/doc/install.mdwn
index 7fe21c9..adaaa3e 100644
--- a/doc/install.mdwn
+++ b/doc/install.mdwn
@@ -22,15 +22,13 @@ detailed instructions             | quick install
 All the downloads above use https for security. For added security, see
 [[verifying_downloads]].
 
-## Using cabal
+## Building it yourself
 
-As a haskell package, git-annex can be installed from source pretty easily
-[[using cabal|cabal]].
-
-## Installation from scratch
-
-This is not recommended, but if you really want to, see [[fromscratch]].
+git-annex is [[Free Software|license]], written in [Haskell](http://www.haskell.org/).
+Experienced users should not find it too hard to build and install
+it [[from source|fromsource]].
 
 ## See also
 
+
 [[autobuild overview|builds]]
diff --git a/doc/install/Linux_standalone.mdwn b/doc/install/Linux_standalone.mdwn
index f7aca5b..fbb3b97 100644
--- a/doc/install/Linux_standalone.mdwn
+++ b/doc/install/Linux_standalone.mdwn
@@ -1,5 +1,5 @@
 If your Linux distribution does not have git-annex packaged up for you,
-you can either build it [[fromscratch]], or you can use a handy
+you can either build it [[fromsource]], or you can use a handy
 prebuilt tarball of the most recent release.
 
 This tarball should work on most Linux systems. It has basically no
diff --git a/doc/install/OSX/porting.mdwn b/doc/install/OSX/porting.mdwn
index 2003af6..7aeb1c1 100644
--- a/doc/install/OSX/porting.mdwn
+++ b/doc/install/OSX/porting.mdwn
@@ -3,4 +3,5 @@ from eg [[HomeBrew]] or the regular [[OSX]] prebuilt app, you
 can try building git-annex from source on OSX, using haskell's cabal package
 manager.
 
-For general instructions for using cabal, see [[this page|/install/cabal]].
+For general instructions on building git-annex from source see
+[[install/fromsource]]
diff --git a/doc/install/cabal.mdwn b/doc/install/cabal.mdwn
deleted file mode 100644
index 3270dd0..0000000
--- a/doc/install/cabal.mdwn
+++ /dev/null
@@ -1,58 +0,0 @@
-As a haskell package, git-annex can be installed using cabal. 
-
-This involves building a lot of haskell packages from source, and so it has
-a lot of moving parts, and it's not uncommon for it to be broken from time
-to time.
-
-If you are not comfortable tracking down and dealing with library build
-problems, installing git-annex with cabal is probably not the right choice
-for you!
-
-## prerequisites
-
-Start by installing the [Haskell Platform][]. In Debian, this is as
-simple as:
-
-    sudo apt-get install haskell-platform
-
- [Haskell Platform]: http://hackage.haskell.org/platform/
-
-## minimal build
-
-This builds git-annex without some features that require C libraries, that
-can be harder to get installed. This is plenty to get started using it,
-although it does not include the assistant or webapp.
-
-	cabal update
-	PATH=$HOME/bin:$PATH
-	cabal install git-annex --bindir=$HOME/bin -f"-assistant -webapp -webdav -pairing -xmpp -dns"
-
-## full build
-
-To build with all features enabled, including the assistant and webapp,
-you will need to install several C libraries and their headers,
-including libgnutls, libgsasl, libxml2, and zlib. Then run:
-
-	cabal update
-	PATH=$HOME/bin:$PATH
-	cabal install c2hs --bindir=$HOME/bin
-	cabal install git-annex --bindir=$HOME/bin
-
-## building from git checkout
-
-But maybe you want something newer (or older). Then [[download]] the version
-you want, and use cabal as follows inside its source tree:
-
-	cabal update
-	PATH=$HOME/bin:$PATH
-	cabal install c2hs --bindir=$HOME/bin
-	cabal install --only-dependencies
-	cabal configure
-	cabal build
-	cabal install --bindir=$HOME/bin
-
-## EKG
-
-When building with cabal, you can optionally enable the 
-[[EKG monitoring interface|ekg]]. This is great for debugging resource
-usage problems.
diff --git a/doc/install/fromscratch.mdwn b/doc/install/fromscratch.mdwn
deleted file mode 100644
index 46ee5a0..0000000
--- a/doc/install/fromscratch.mdwn
+++ /dev/null
@@ -1,27 +0,0 @@
-To install git-annex from scratch, you need a lot of stuff. Really
-quite a lot.
-
-* Haskell stuff
-  * [The Haskell Platform](http://haskell.org/platform/) (GHC 7.4 or newer)
-  * A ton of haskell libraries. Rather than try to list them all here,
-    see git-annex.cabal. Probably the easiest way to install them:
-    `cabal update; cabal install git-annex --only-dependencies`
-* Shell commands
-  * [git](http://git-scm.com/) (1.7.2 or newer; 1.8.5 or newer recommended)
-  * [xargs](http://savannah.gnu.org/projects/findutils/)
-  * [rsync](http://rsync.samba.org/)
-  * [curl](http://http://curl.haxx.se/) (optional, but recommended)
-  * [wget](http://www.gnu.org/software/wget/) (optional)
-  * [sha*sum](ftp://ftp.gnu.org/gnu/coreutils/) (optional)
-  * [gpg](http://gnupg.org/) (optional; needed for encryption)
-  * [lsof](ftp://lsof.itap.purdue.edu/pub/tools/unix/lsof/)
-    (optional; recommended for watch mode)
-  * [gcrypt](https://github.com/joeyh/git-remote-gcrypt)
-    (optional)
-  * [nocache](https://github.com/Feh/nocache)
-    (optional)
-  * multicast DNS support, provided on linux by [nss-mdns](http://www.0pointer.de/lennart/projects/nss-mdns/)
-    (optional; recommended for the assistant to support pairing well)
-  * [ikiwiki](http://ikiwiki.info) (optional; used to build the docs)
-
-Then just [[download]] git-annex and run: `make; make install`
diff --git a/doc/install/fromsource.mdwn b/doc/install/fromsource.mdwn
new file mode 100644
index 0000000..baa4e1b
--- /dev/null
+++ b/doc/install/fromsource.mdwn
@@ -0,0 +1,68 @@
+So you want to build git-annex from source. This is encouraged for
+users with experience building code from source. But the build may
+require some care and feeding. This page will start with the easy
+methods and work up to the harder ones.
+
+## prerequisites
+
+Start by installing the 
+[Haskell Platform](http://hackage.haskell.org/platform/).
+
+In Debian, this is as simple as:
+
+	sudo apt-get install haskell-platform
+
+## downloading the source code
+
+The easiest way is using git; see [[download]] or just:
+
+	git clone git://git-annex.branchable.com/ git-annex
+
+Or, you can use cabal to get the source code:
+
+	cabal update; cabal unpack git-annex
+
+## building from source on Debian
+
+This is the method used by git-annex's author, and so it's the one most
+likely to work without problems.
+
+First, install everything git-annex needs to build:
+
+	sudo apt-get build-dep git-annex
+
+Now you can build git-annex using either `make` or `cabal build`.
+
+## minimal build with cabal

(Diff truncated)
Added a comment
diff --git a/doc/design/assistant/blog/day_232__headless_webapp/comment_5_7e51a197ff9970ae50cf47bd3a922257._comment b/doc/design/assistant/blog/day_232__headless_webapp/comment_5_7e51a197ff9970ae50cf47bd3a922257._comment
new file mode 100644
index 0000000..de4be25
--- /dev/null
+++ b/doc/design/assistant/blog/day_232__headless_webapp/comment_5_7e51a197ff9970ae50cf47bd3a922257._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.22"
+ subject="comment 5"
+ date="2014-09-16T18:36:18Z"
+ content="""
+Note that --listen=address:port had to be removed.
+
+OTOH, the webapp can be run with a https certificate now, which makes remote access much more secure.
+
+The webapp will use HTTPS if it finds
+a .git/annex/privkey.pem and .git/annex/certificate.pem. Here's
+one way to generate those files, using a self-signed certificate:
+
+    openssl genrsa -out .git/annex/privkey.pem 4096
+    openssl req -new -x509 -key .git/annex/privkey.pem > .git/annex/certificate.pem
+
+"""]]

Added a comment
diff --git a/doc/forum/annex_merge_creates___34__synced__47____42____34___branches/comment_1_4667fadb05c594b0a212bf455ee65298._comment b/doc/forum/annex_merge_creates___34__synced__47____42____34___branches/comment_1_4667fadb05c594b0a212bf455ee65298._comment
new file mode 100644
index 0000000..90643ca
--- /dev/null
+++ b/doc/forum/annex_merge_creates___34__synced__47____42____34___branches/comment_1_4667fadb05c594b0a212bf455ee65298._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.22"
+ subject="comment 1"
+ date="2014-09-16T18:22:11Z"
+ content="""
+Why is this a problem? You can delete the branch at any time of course if it's in the way.
+
+It would be possible for `git-annex sync` to avoid creating the synced/master branch at all when syncing with a bare git repository, but this would actually make it less efficient and slower. Where currently it makes one push, updating the remote's master branch when possible, and forcing an update of its synced/master branch at the same time, it would instead need to first try to update remote's master, then check if that succeeded and if not force the update of synced/master. Also, it's not clear how to check if the push to master succeeded, since something else might update it further in a race.
+
+I suppose that `git annex sync/merge` could delete the local synced/* branches once it was done merging them. This wouldn't prevent `git pull` from pulling down those branches, though.
+"""]]

Added a comment
diff --git a/doc/forum/schedule_repository___91__expression__93__/comment_1_b123b657a92897017973927e3e47673b._comment b/doc/forum/schedule_repository___91__expression__93__/comment_1_b123b657a92897017973927e3e47673b._comment
new file mode 100644
index 0000000..a0c4e82
--- /dev/null
+++ b/doc/forum/schedule_repository___91__expression__93__/comment_1_b123b657a92897017973927e3e47673b._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.22"
+ subject="comment 1"
+ date="2014-09-16T18:13:18Z"
+ content="""
+Only fscking can be scheduled. From the man page:
+
+       These  actions  are available: \"fsck self\", \"fsck UUID\" 
+
+It won't be expanded to allow arbitrary commands, because that would let anyone who you share an annex with schedule arbitrary commands to run on your computer..
+"""]]

Added a comment
diff --git a/doc/forum/usability:_creating_an_archive_on_a_new_external_drive/comment_1_27b5283c65c402f330263426e4ca6ac1._comment b/doc/forum/usability:_creating_an_archive_on_a_new_external_drive/comment_1_27b5283c65c402f330263426e4ca6ac1._comment
new file mode 100644
index 0000000..1b5508f
--- /dev/null
+++ b/doc/forum/usability:_creating_an_archive_on_a_new_external_drive/comment_1_27b5283c65c402f330263426e4ca6ac1._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.22"
+ subject="comment 1"
+ date="2014-09-16T18:07:54Z"
+ content="""
+I started to make this change, and then I realized this problem: If a non-bare repository is made on an external drive, then to the user this is another place they can edit their files. Which means they will expect their changes made there to be committed. Which is highly problematic, because the assistant cannot be left running on an external drive or it won't be able to be unmounted. Or, a periodic `git annex add; git annex sync` could be run on the external drive, but that is a more expensive process (especially when run on a slow drive) and would not meet the expectations of users of the assistant that their changes will promptly propagate.
+
+So, I feel that leaving bare repositories is actually the best choice.
+"""]]

Windows: Avoid crashing trying to list gpg secret keys, for gcrypt which is not yet supported on Windows.
diff --git a/Utility/Gpg.hs b/Utility/Gpg.hs
index 69a47c7..f9b60f2 100644
--- a/Utility/Gpg.hs
+++ b/Utility/Gpg.hs
@@ -163,8 +163,9 @@ type UserId = String
 {- All of the user's secret keys, with their UserIds.
  - Note that the UserId may be empty. -}
 secretKeys :: IO (M.Map KeyId UserId)
-secretKeys = M.fromList . parse . lines <$> readStrict params
+secretKeys = catchDefaultIO M.empty makemap
   where
+	makemap = M.fromList . parse . lines <$> readStrict params
   	params = [Params "--with-colons --list-secret-keys --fixed-list-mode"]
 	parse = extract [] Nothing . map (split ":")
 	extract c (Just keyid) (("uid":_:_:_:_:_:_:_:_:userid:_):rest) =
diff --git a/debian/changelog b/debian/changelog
index cd6cfd2..825d8d4 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -2,6 +2,8 @@ git-annex (5.20140916) UNRELEASED; urgency=medium
 
   * 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
+    which is not yet supported on Windows.
 
  -- Joey Hess <joeyh@debian.org>  Mon, 15 Sep 2014 14:39:17 -0400
 
diff --git a/doc/bugs/webapp_on_windows_7_64_bit_fail_to_add_server_repo.mdwn b/doc/bugs/webapp_on_windows_7_64_bit_fail_to_add_server_repo.mdwn
index cb58b91..c076dfc 100644
--- a/doc/bugs/webapp_on_windows_7_64_bit_fail_to_add_server_repo.mdwn
+++ b/doc/bugs/webapp_on_windows_7_64_bit_fail_to_add_server_repo.mdwn
@@ -64,3 +64,13 @@ secmem usage: 0/0 bytes in 0/0 blocks of pool 0/65536
 
 # End of transcript or log.
 """]]
+
+> Thanks for reporting this problem. I've fixed it to not crash when gpg 
+> fails to list secret keys.
+> 
+> That doesn't fix the problem that the cygnus build of gpg does not find
+> the user's home directory properly. But that's only needed for the
+> encrypted repository (gcrypt) support, which is listed in
+> [[windows_support]] as not yet available for Windows.
+>
+> So, not leaving this bug report open. [[done]] --[[Joey]]

Added a comment
diff --git a/doc/forum/Local_and_remote_in_direct_mode/comment_2_90eeb2bffdb2db8032f9a0eac630ed56._comment b/doc/forum/Local_and_remote_in_direct_mode/comment_2_90eeb2bffdb2db8032f9a0eac630ed56._comment
new file mode 100644
index 0000000..539ad13
--- /dev/null
+++ b/doc/forum/Local_and_remote_in_direct_mode/comment_2_90eeb2bffdb2db8032f9a0eac630ed56._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Petter_petterson"
+ ip="89.160.15.173"
+ subject="comment 2"
+ date="2014-09-16T08:15:05Z"
+ content="""
+Doing git remote add B ssh://machineB:/~/annex still makes the repository on machineB a bare one, just try it and check git config -l | grep core.bare...
+"""]]

Added a comment
diff --git a/doc/forum/How_do_I_sync_files_from_mobile_to_a_repo__63__/comment_3_5a11c45f92bae1328a5120945bee1fa0._comment b/doc/forum/How_do_I_sync_files_from_mobile_to_a_repo__63__/comment_3_5a11c45f92bae1328a5120945bee1fa0._comment
new file mode 100644
index 0000000..8a9f6cd
--- /dev/null
+++ b/doc/forum/How_do_I_sync_files_from_mobile_to_a_repo__63__/comment_3_5a11c45f92bae1328a5120945bee1fa0._comment
@@ -0,0 +1,36 @@
+[[!comment format=mdwn
+ username="Petter_petterson"
+ ip="89.160.15.173"
+ subject="comment 3"
+ date="2014-09-16T08:13:59Z"
+ content="""
+Thanks Justin, but that wont work. Even pointing out a normal, non-bare repo and then adding it as a ssh remote will convert it into a bare repo. I confirmed that, and then I read this post:
+
+    http://git-annex.branchable.com/forum/Local_and_remote_in_direct_mode/
+
+that states that
+> The \"Remote server using ssh\" option in the webapp is intended to set up a bare git repository on a server, not a non-bare git repository on a client.\"
+
+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.
+
+The only way to do it for me was to do the following,
+Assume my cellphone is device A, and my desktop is device B:
+
+On machine B:
+
+    cd ~/DCIM
+    git init
+    git annex init \"B\"
+    git annex direct
+    echo '*/5 * * * * * cd ~/DCIM; git annex sync' > crontab
+
+On machine A:
+
+    git clone ssh://user@machineB:/home/user/DCIM
+    git annex sync
+    git annex webapp
+
+now pictures are synced to the computer in direct, non-bare format every 5 minutes. I have spent literally days on this and now I finally nailed it in a crude but working fashion. 
+"""]]

Added a comment: Installing debs
diff --git a/doc/install/fromscratch/comment_5_4aea55dc5b24d84e0953382ccfea1a01._comment b/doc/install/fromscratch/comment_5_4aea55dc5b24d84e0953382ccfea1a01._comment
new file mode 100644
index 0000000..c14b75b
--- /dev/null
+++ b/doc/install/fromscratch/comment_5_4aea55dc5b24d84e0953382ccfea1a01._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmfEGTjv4GsWkSG2lpuBitRDxVkml7yEQg"
+ nickname="Britt"
+ subject="Installing debs"
+ date="2014-09-16T02:16:28Z"
+ content="""
+@azul - the problem with installing dependencies from apt-get is that the Ubuntu haskell packages are rather old. It shouldn't be this way (and it has gotten a LOT better - I suggest installing the newest version of the Haskell Platform that you can), but often cabal will complain about a package it is unable to install because it failed on the install of that package's dependencies. You should try to cabal install $FAILED_DEPENDENCY (not an actual env variable), and you will often get more informative error messages - some packages require non-haskell dependencies (take gtk3, for instance) which cabal doesn't know how to handle at this point, because that would require some cross platform foo (cabal install runs on Windows and OSX, which don't have native package managers at all). 
+
+@Paul - It looks like you ran into a bug, because http-client no longer depends on network>=2.6, it now can take network 2.4 - 2.6 or 2.6 or greater. If you try again it should work. 
+
+Please don't be put off by haskell because of things like this - git annex is a very large and complicated project, and developing on large projects such as this pretty much require you to have pretty recent versions of all haskell packages. I really suggest you take a look at this book http://learnyouahaskell.com/introduction. Haskell is a beautiful language and it doesn't have to be esoteric, academic, or difficult at all. It's obvious since you are attempting to build this from source that you are either interested in haskell or you are only interested in the development of git-annex. Either way, it would behoove you to read that book. It is short, full of great examples, and it even has pleasant illustrations. It may look like a children's book, but by the end of it you will know how to use all of the major monads (you may not know what a monad is, but that isn't really that important anyway - you just need to know how they are used).
+"""]]

removed
diff --git a/doc/tips/using_the_web_as_a_special_remote/comment_8_d0c0d5dfbe3f17f19226bb9ac286eeab._comment b/doc/tips/using_the_web_as_a_special_remote/comment_8_d0c0d5dfbe3f17f19226bb9ac286eeab._comment
deleted file mode 100644
index ba8815f..0000000
--- a/doc/tips/using_the_web_as_a_special_remote/comment_8_d0c0d5dfbe3f17f19226bb9ac286eeab._comment
+++ /dev/null
@@ -1,8 +0,0 @@
-[[!comment format=mdwn
- username="https://openid.stackexchange.com/user/7891307e-4b76-4697-8e71-083669c26e9f"
- nickname="MichaelK"
- subject="quvi in .gitattributes"
- date="2014-09-15T18:54:36Z"
- content="""
-Is there a way to put something like `* annex.quvi-options = -f best` in `.gitattributes`?  When trying to, I get ` is not a valid attribute name: .gitattributes:2`.
-"""]]

Added a comment: quvi in .gitattributes
diff --git a/doc/tips/using_the_web_as_a_special_remote/comment_8_d0c0d5dfbe3f17f19226bb9ac286eeab._comment b/doc/tips/using_the_web_as_a_special_remote/comment_8_d0c0d5dfbe3f17f19226bb9ac286eeab._comment
new file mode 100644
index 0000000..ba8815f
--- /dev/null
+++ b/doc/tips/using_the_web_as_a_special_remote/comment_8_d0c0d5dfbe3f17f19226bb9ac286eeab._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://openid.stackexchange.com/user/7891307e-4b76-4697-8e71-083669c26e9f"
+ nickname="MichaelK"
+ subject="quvi in .gitattributes"
+ date="2014-09-15T18:54:36Z"
+ content="""
+Is there a way to put something like `* annex.quvi-options = -f best` in `.gitattributes`?  When trying to, I get ` is not a valid attribute name: .gitattributes:2`.
+"""]]

add news item for git-annex 5.20140915
diff --git a/doc/news/version_5.20140707.mdwn b/doc/news/version_5.20140707.mdwn
deleted file mode 100644
index a00737b..0000000
--- a/doc/news/version_5.20140707.mdwn
+++ /dev/null
@@ -1,23 +0,0 @@
-git-annex 5.20140707 released with [[!toggle text="these changes"]]
-[[!toggleable text="""
-   * assistant: Fix bug, introduced in last release, that caused the assistant
-     to make many unncessary empty merge commits.
-   * assistant: Fix one-way assistant-&gt;assistant sync in direct mode.
-   * Fix bug in annex.queuesize calculation that caused much more
-     queue flushing than necessary.
-   * importfeed: When annex.genmetadata is set, metadata from the feed
-     is added to files that are imported from it.
-   * Support users who have set commit.gpgsign, by disabling gpg signatures
-     for git-annex branch commits and commits made by the assistant.
-   * Fix memory leak when committing millions of changes to the git-annex
-     branch, eg after git-annex add has run on 2 million files in one go.
-   * Support building with bloomfilter 2.0.0.
-   * Run standalone install process when the assistant is started
-     (was only being run when the webapp was opened).
-   * Android: patch git to avoid fchmod, which fails on /sdcard.
-   * Windows: Got rid of that pesky DOS box when starting the webapp.
-   * Windows: Added Startup menu item so assistant starts automatically
-     on login.
-   * Windows: Fix opening file browser from webapp when repo is in a
-     directory with spaces.
-   * Windows: Assistant now logs to daemon.log."""]]
\ No newline at end of file
diff --git a/doc/news/version_5.20140915.mdwn b/doc/news/version_5.20140915.mdwn
new file mode 100644
index 0000000..7aa6477
--- /dev/null
+++ b/doc/news/version_5.20140915.mdwn
@@ -0,0 +1,27 @@
+git-annex 5.20140915 released with [[!toggle text="these changes"]]
+[[!toggleable text="""
+   * New annex.hardlink setting. Closes: #[758593](http://bugs.debian.org/758593)
+   * init: Automatically detect when a repository was cloned with --shared,
+     and set annex.hardlink=true, as well as marking the repository as
+     untrusted.
+   * Fix parsing of ipv6 address in git remote address when it was not
+     formatted as an url.
+   * The annex-rsync-transport configuration is now also used when checking
+     if a key is present on a rsync remote, and when dropping a key from
+     the remote.
+   * Promote file not found warning message to an error.
+   * Fix transfer lock file FD leak that could occur when two separate
+     git-annex processes were both working to perform the same set of
+     transfers.
+   * sync: Ensure that pending changes to git-annex branch are committed
+     before push when in direct mode. (Fixing a very minor reversion.)
+   * WORM backend: Switched to include the relative path to the file inside
+     the repository, rather than just the file's base name. Note that if you're
+     relying on such things to keep files separate with WORM, you should really
+     be using a better backend.
+   * Rather than crashing when there's a problem with the requested bloomfilter
+     capacity/accuracy, fall back to a reasonable default bloom filter size.
+   * Fix build with optparse-applicative 0.10. Closes: #[761484](http://bugs.debian.org/761484)
+   * webapp: Fixed visual glitch in xmpp pairing that was reported live by a
+     user who tracked me down in front of a coffee cart in Portland.
+     (New bug reporting method of choice?)"""]]
\ No newline at end of file

Added a comment
diff --git a/doc/internals/comment_3_5a26ee5aab274f321a4ea6f8527f53bd._comment b/doc/internals/comment_3_5a26ee5aab274f321a4ea6f8527f53bd._comment
new file mode 100644
index 0000000..099f4c8
--- /dev/null
+++ b/doc/internals/comment_3_5a26ee5aab274f321a4ea6f8527f53bd._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="zardoz"
+ ip="134.147.14.84"
+ subject="comment 3"
+ date="2014-09-15T10:34:36Z"
+ content="""
+Some documentation that would be nice having added in the appropriate places:
+
+* Exactly how is the index file being used? Is this just a copy of the git index file that we would get when checking out the git-annex branch? Why is the file kept around? Which sort of operations are done on the index, e.g. when doing git annex add?
+
+* For all time-stamped data-structures: Exactly which significance does the time-stamp have? E.g., for uuid.log, is this the date the name was changed?
+"""]]

diff --git a/doc/bugs/webapp_on_windows_7_64_bit_fail_to_add_server_repo.mdwn b/doc/bugs/webapp_on_windows_7_64_bit_fail_to_add_server_repo.mdwn
new file mode 100644
index 0000000..cb58b91
--- /dev/null
+++ b/doc/bugs/webapp_on_windows_7_64_bit_fail_to_add_server_repo.mdwn
@@ -0,0 +1,66 @@
+### Please describe the problem.
+Cant add Server repo
+
+### What steps will reproduce the problem?
+install linux prebuild torball on server (readynas pro 600)
+un-tar and run with ./git-annex
+(git-annex test pass without error)
+install windows client on win7 64 bit and start webapp
+try add server repo as second repo will led to an internal server error about gpg
+
+followed the assistend video
+### What version of git-annex are you using? On what operating system?
+Readynas (Linux):
+annex@readynas-pro:~/git-annex.linux$ ./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
+
+Windows:
+Version: 5.20140914-gb169612
+Build flags: Assistant Webapp Webapp-secure Pairing Testsuite S3 WebDAV DNS Feeds Quvi TDFA CryptoHash 
+
+Git on Windows:
+C:\Users\Xaver>git --version
+git version 1.9.4.msysgit.1
+
+GPG on Windows:
+C:\Users\Xaver>gpg --version
+gpg (GnuPG) 2.0.26 (Gpg4win 2.2.2)
+libgcrypt 1.6.1
+Copyright (C) 2013 Free Software Foundation, Inc.
+License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
+This is free software: you are free to change and redistribute it.
+There is NO WARRANTY, to the extent permitted by law.
+
+Home: C:/Users/Xaver/AppData/Roaming/gnupg
+Unterstützte Verfahren:
+Öff. Schlüssel: RSA, ELG, DSA
+Verschlü.: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,
+          CAMELLIA128, CAMELLIA192, CAMELLIA256
+Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
+Komprimierung: nicht komprimiert, ZIP, ZLIB, BZIP2
+### Please provide any additional information below.
+Internal Server Error
+user error (gpg ["--quiet","--trust-model","always","--with-colons","--list-secret-keys","--fixed-list-mode"] exited 2)
+
+gpg: fatal: can't create directory `/home/Xaver/.gnupg': No such file or directory
+
+makes no sense on windows machine
+
+must be like "C:\Users\Xaver\AppData\Roaming\gnupg" or %Username%\AppData\Roaming\gnupg I guess.
+
+gpg itself works fine I use it with thunderbird
+
+[[!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
+gpg: WARNING: using insecure memory!
+gpg: please see http://www.gnupg.org/documentation/faqs.html for more information
+gpg: fatal: can't create directory `/home/Xaver/.gnupg': No such file or directory
+secmem usage: 0/0 bytes in 0/0 blocks of pool 0/65536
+14/Sep/2014:23:17:08 +0200 [Error#yesod-core] user error (gpg ["--quiet","--trust-model","always","--with-colons","--list-secret-keys","--fixed-list-mode"] exited 2) @(yesod-core-1.2.19:Yesod.Core.Class.Yesod .\Yesod\Core\Class\Yesod.hs:503:5)
+
+# End of transcript or log.
+"""]]

Added a comment
diff --git a/doc/forum/How_do_I_sync_files_from_mobile_to_a_repo__63__/comment_2_fd5257eff7f94971557c031a94ac2766._comment b/doc/forum/How_do_I_sync_files_from_mobile_to_a_repo__63__/comment_2_fd5257eff7f94971557c031a94ac2766._comment
new file mode 100644
index 0000000..97724fd
--- /dev/null
+++ b/doc/forum/How_do_I_sync_files_from_mobile_to_a_repo__63__/comment_2_fd5257eff7f94971557c031a94ac2766._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmBUR4O9mofxVbpb8JV9mEbVfIYv670uJo"
+ nickname="Justin"
+ subject="comment 2"
+ date="2014-09-14T18:57:12Z"
+ content="""
+If `/computer1/annex/` was already an annex repository you should have synced the phone to that, not to a new bare repository at `/computer1/annex/mobile/`
+"""]]

Added a comment
diff --git a/doc/devblog/day_219__catching_up_and_looking_back/comment_2_460c064bebb5061fcba2a6c79f039362._comment b/doc/devblog/day_219__catching_up_and_looking_back/comment_2_460c064bebb5061fcba2a6c79f039362._comment
new file mode 100644
index 0000000..a00d33d
--- /dev/null
+++ b/doc/devblog/day_219__catching_up_and_looking_back/comment_2_460c064bebb5061fcba2a6c79f039362._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="https://id.koumbit.net/anarcat"
+ ip="72.0.72.144"
+ subject="comment 2"
+ date="2014-09-14T17:38:34Z"
+ content="""
+thanks so much for your work on git-annex, joeyh. it's hard to imagine that just 4 years ago, we didn't have anything even close to this tool and how far it went since then. 
+
+~~~~
+anarcat@marcos:git-annex$ pepper age
+Loading cache index... done
+git-annex is 3 years old
+git-annex's birthday is in about 1 month (October 19th)
+~~~~
+
+birthday is coming soon! :)
+
+it's also quite impressive how much work can be done in a single year with some (fairly minimal) funding to dedicate a full dev on a project. very inspiring - keep up the good work! -- [[anarcat]]
+"""]]

fixed
diff --git a/doc/bugs/Bloom_filter_capacity_too_large_to_represent.mdwn b/doc/bugs/Bloom_filter_capacity_too_large_to_represent.mdwn
index 2fb6952..56d3d8f 100644
--- a/doc/bugs/Bloom_filter_capacity_too_large_to_represent.mdwn
+++ b/doc/bugs/Bloom_filter_capacity_too_large_to_represent.mdwn
@@ -39,3 +39,6 @@ annexed files in working tree: 35300
 size of annexed files in working tree: 193.76 gigabytes
 bloom filter size: git-annex: Data.BloomFilter.Util.suggestSizing: capacity too large to represent
 """]]
+
+> I've worked around this problem in the arm autobuilder (only build
+> affected), so [[done]] --[[Joey]]

diff --git a/doc/forum/Git_remote__63_____40__bitbucket__44___github__41__.mdwn b/doc/forum/Git_remote__63_____40__bitbucket__44___github__41__.mdwn
new file mode 100644
index 0000000..245b298
--- /dev/null
+++ b/doc/forum/Git_remote__63_____40__bitbucket__44___github__41__.mdwn
@@ -0,0 +1 @@
+Is it possible to use bitbucket as a remote?

Added a comment: How to publish your files to the public
diff --git a/doc/tips/using_Amazon_S3/comment_7_cf6755d88463878f2ea6e4c300899027._comment b/doc/tips/using_Amazon_S3/comment_7_cf6755d88463878f2ea6e4c300899027._comment
new file mode 100644
index 0000000..3c7b817
--- /dev/null
+++ b/doc/tips/using_Amazon_S3/comment_7_cf6755d88463878f2ea6e4c300899027._comment
@@ -0,0 +1,33 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmH7o6q2l99M-PQolOfbR3_i5B_jtTIcAE"
+ nickname="Giovanni"
+ subject="How to publish your files to the public"
+ date="2014-09-13T15:29:18Z"
+ content="""
+I don't know if this is what Jack wanted, but you can upload your files to S3 and let them be accessible through a public URL.
+
+First, go to (or create) the bucket you will use at [S3](https://console.aws.amazon.com/s3/) and add a public get policy to it:
+
+```
+   {
+    	\"Version\": \"2008-10-17\",
+    	\"Statement\": [
+    		{
+    			\"Sid\": \"AllowPublicRead\",
+    			\"Effect\": \"Allow\",
+    			\"Principal\": {
+    				\"AWS\": \"*\"
+    			},
+    			\"Action\": \"s3:GetObject\",
+    			\"Resource\": \"arn:aws:s3:::BUCKETNAME/*\"
+    		}
+    	]
+    }
+```
+
+Then set up your special remote with the options `encryption=none`, `bucket='BUCKETNAME'` `chunk=0` (and any others you want).
+
+Your files will be accessible through `http://BUCKETNAME.s3-website-LOCATION.amazonaws.com/KEY` where location is the one specified through the options `datacenter` and KEY is the SHA-SOMETHING hash of the file, created by git annex and accessible if you run `git annex lookupkey FILEPATH`.
+
+This way you can share a link to each file you have at your S3 remote.
+"""]]

Added a comment: addition
diff --git a/doc/forum/How_do_I_sync_files_from_mobile_to_a_repo__63__/comment_1_fc914b5998a09943fc8c1917a0e36096._comment b/doc/forum/How_do_I_sync_files_from_mobile_to_a_repo__63__/comment_1_fc914b5998a09943fc8c1917a0e36096._comment
new file mode 100644
index 0000000..ac49670
--- /dev/null
+++ b/doc/forum/How_do_I_sync_files_from_mobile_to_a_repo__63__/comment_1_fc914b5998a09943fc8c1917a0e36096._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Petter_petterson"
+ ip="89.160.15.173"
+ subject="addition"
+ date="2014-09-13T07:54:58Z"
+ content="""
+I understand that the copy of the cellphones' photos are stored on the server too, when typing git annex whereis <photo> I see that it exists on the server, but I need to be able to, at will copy out the jpg files for editing and using in other places.
+"""]]

Added a comment: Hard linking on local clone
diff --git a/doc/devblog/day_219__catching_up_and_looking_back/comment_1_16b13b2510183a9da5f960ae5765e581._comment b/doc/devblog/day_219__catching_up_and_looking_back/comment_1_16b13b2510183a9da5f960ae5765e581._comment
new file mode 100644
index 0000000..5b839b5
--- /dev/null
+++ b/doc/devblog/day_219__catching_up_and_looking_back/comment_1_16b13b2510183a9da5f960ae5765e581._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkRGMQkg9ck_pr47JXZV_C2DJQXrO8LgpI"
+ nickname="Michael"
+ subject="Hard linking on local clone"
+ date="2014-09-13T06:28:01Z"
+ content="""
+Thanks for this feature. It will save a lot of space when working on one-off projects with big scientific datasets.
+
+Unfortunately, there is probably no easy solution to achieve similar savings across file systems. On our shared cluster individual labs have their data in separate ZFS volumes (to ease individual backup handling), but data is often shared (i.e. copied) across volumes when cloning an annex. We need expensive de-duplication on the backup-server to, at least, prevent this kind of waste to hit the backups -- but the master file server still suffers (de-duplication ratio sometimes approaching a factor of 2.0).
+"""]]

mark annex.genmetadata as code.
diff --git a/doc/design/metadata.mdwn b/doc/design/metadata.mdwn
index 10e79b9..9da0a36 100644
--- a/doc/design/metadata.mdwn
+++ b/doc/design/metadata.mdwn
@@ -53,7 +53,7 @@ once, and can be left alone when refining a view.
 
 ## automatically added metadata
 
-When annex.genmetadata is set, git annex add automatically attaches
+When `annex.genmetadata` is set, git annex add automatically attaches
 some metadata to a file. Currently year and month fields, from its mtime.
 
 There's also a post-commit-annex hook script.

diff --git a/doc/forum/How_do_I_sync_files_from_mobile_to_a_repo__63__.mdwn b/doc/forum/How_do_I_sync_files_from_mobile_to_a_repo__63__.mdwn
new file mode 100644
index 0000000..d63af38
--- /dev/null
+++ b/doc/forum/How_do_I_sync_files_from_mobile_to_a_repo__63__.mdwn
@@ -0,0 +1,13 @@
+I have a local repo on a computer with some folder on the path
+/computer1/annex/
+
+Then I tried to run git annex on my phone and added a remote ssh repo syncing to
+/computer1/annex/mobile/ from my mobile's picture folder.
+
+But the files ending up there are:
+ls /computer1/annex/mobile/
+annex  branches  config  description  HEAD  hooks  info  objects  refs 
+
+I chose "full backup"
+
+Why dont I see my pictures there, even if they are hiding in the metadata ?

Added a comment
diff --git a/doc/forum/special_remote_for_IMAP/comment_4_0f8e01c453afb02aebf44b3fb2c9a7c1._comment b/doc/forum/special_remote_for_IMAP/comment_4_0f8e01c453afb02aebf44b3fb2c9a7c1._comment
new file mode 100644
index 0000000..6e39fd7
--- /dev/null
+++ b/doc/forum/special_remote_for_IMAP/comment_4_0f8e01c453afb02aebf44b3fb2c9a7c1._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmH7o6q2l99M-PQolOfbR3_i5B_jtTIcAE"
+ nickname="Giovanni"
+ subject="comment 4"
+ date="2014-09-12T18:57:07Z"
+ content="""
+Does this somehow scan the IMAP server for attachments already there?
+"""]]

removed
diff --git a/doc/forum/special_remote_for_IMAP/comment_4_1594457620463aa001ebb4a92eced276._comment b/doc/forum/special_remote_for_IMAP/comment_4_1594457620463aa001ebb4a92eced276._comment
deleted file mode 100644
index 07392aa..0000000
--- a/doc/forum/special_remote_for_IMAP/comment_4_1594457620463aa001ebb4a92eced276._comment
+++ /dev/null
@@ -1,8 +0,0 @@
-[[!comment format=mdwn
- username="https://www.google.com/accounts/o8/id?id=AItOawmH7o6q2l99M-PQolOfbR3_i5B_jtTIcAE"
- nickname="Giovanni"
- subject="comment 4"
- date="2014-09-12T18:55:45Z"
- content="""
-Does this somehow scan the IMAP server for attachments already there?
-"""]]

Added a comment
diff --git a/doc/forum/special_remote_for_IMAP/comment_4_1594457620463aa001ebb4a92eced276._comment b/doc/forum/special_remote_for_IMAP/comment_4_1594457620463aa001ebb4a92eced276._comment
new file mode 100644
index 0000000..07392aa
--- /dev/null
+++ b/doc/forum/special_remote_for_IMAP/comment_4_1594457620463aa001ebb4a92eced276._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmH7o6q2l99M-PQolOfbR3_i5B_jtTIcAE"
+ nickname="Giovanni"
+ subject="comment 4"
+ date="2014-09-12T18:55:45Z"
+ content="""
+Does this somehow scan the IMAP server for attachments already there?
+"""]]

diff --git a/doc/forum/Move_unsynced_file_in_direct_mode.mdwn b/doc/forum/Move_unsynced_file_in_direct_mode.mdwn
new file mode 100644
index 0000000..015b5f5
--- /dev/null
+++ b/doc/forum/Move_unsynced_file_in_direct_mode.mdwn
@@ -0,0 +1,97 @@
+When I rename unsynced files in a direct mode repo, the original symlink gets removed from git, but the new symlink doesn't get added back by autocommit or by explicitly using `git annex add`.
+
+First, I create a file in a git-annex repo:
+
+        $ mkdir annex1
+        $ cd annex1
+        $ git init
+        Initialized empty Git repository in /home/cwarden/annex1/.git/
+        $ git annex init
+        init  ok
+        (Recording state in git...)
+        $ echo test > test1
+        $ git annex add test1
+        add test1 ok
+        (Recording state in git...)
+        $ git annex sync
+        commit  ok
+        $ ls -l
+        total 4
+        lrwxrwxrwx 1 cwarden cwarden 178 Sep 12 10:14 test1 -> .git/annex/objects/w8/pv/SHA256E-s5--f2ca1bb6c7e907d06dafe4687e579fce76b37e4e93b7605022da52e6ccc26fd2/SHA256E-s5--f2ca1bb6c7e907d06dafe4687e579fce76b37e4e93b7605022da52e6ccc26fd2
+        $ cat test1
+        test
+
+Now, I clone the repo and enable autocommit and direct mode in the second repo:
+
+        $ cd ..
+        $ git clone annex1 annex2
+        Cloning into 'annex2'...
+        done.
+        $ cd annex2
+        $ git config annex.autocommit true
+        $ git annex direct
+        commit
+        On branch master
+        Your branch is up-to-date with 'origin/master'.
+
+        nothing to commit, working directory clean
+        ok
+        direct  ok
+
+I drop the file, then rename it:
+
+        $ git annex drop test1
+        (merging origin/git-annex into git-annex...)
+        (Recording state in git...)
+        $ mv test1 test2
+        $ ls -l
+        total 4
+        lrwxrwxrwx 1 cwarden cwarden 178 Sep 12 10:14 test2 -> .git/annex/objects/w8/pv/SHA256E-s5--f2ca1bb6c7e907d06dafe4687e579fce76b37e4e93b7605022da52e6ccc26fd2/SHA256E-s5--f2ca1bb6c7e907d06dafe4687e579fce76b37e4e93b7605022da52e6ccc26fd2
+        $ git annex sync
+        commit  (Recording state in git...)
+        ok
+        pull origin
+        ok
+        push origin
+        Counting objects: 6, done.
+        Delta compression using up to 4 threads.
+        Compressing objects: 100% (5/5), done.
+        Writing objects: 100% (6/6), 674 bytes | 0 bytes/s, done.
+        Total 6 (delta 1), reused 0 (delta 0)
+        To /home/cwarden/annex1
+                2772756..ffcb7a1  annex/direct/master -> synced/master
+         * [new branch]      git-annex -> synced/git-annex
+        ok
+        (Recording state in git...)
+
+Now, I want to get the renamed file:
+
+        $ git annex get test2
+        $ ls -l
+        total 4
+        lrwxrwxrwx 1 cwarden cwarden 178 Sep 12 10:14 test2 -> .git/annex/objects/w8/pv/SHA256E-s5--f2ca1bb6c7e907d06dafe4687e579fce76b37e4e93b7605022da52e6ccc26fd2/SHA256E-s5--f2ca1bb6c7e907d06dafe4687e579fce76b37e4e93b7605022da52e6ccc26fd2
+        $ cat test2
+        cat: test2: No such file or directory
+
+Explicitly adding test2 doesn't work:
+
+        $ git annex add test2
+        $ git annex get test2
+        $ cat test2
+        cat: test2: No such file or directory
+
+`git annex fsck` doesn't help:
+
+        $ git annex fsck
+        $ cat test2
+        cat: test2: No such file or directory
+
+The only way I've found to get the renamed file back into git is to use `core.bare=false`, but the [documentation](http://git-annex.branchable.com/direct_mode/) says that "there should be no good reason to need to do this, ever".
+
+        $ git -c core.bare=false add test2
+        $ git -c core.bare=false commit -m'force renamed file back into git'
+        $ git annex get test2
+        $ cat test2
+        test
+
+Is there a better solution?

Added a comment: turns out to be an upstream bug already filed
diff --git a/doc/bugs/Bloom_filter_capacity_too_large_to_represent/comment_4_9fb9fdbc6218d6b86b0921f411f78891._comment b/doc/bugs/Bloom_filter_capacity_too_large_to_represent/comment_4_9fb9fdbc6218d6b86b0921f411f78891._comment
new file mode 100644
index 0000000..77097e0
--- /dev/null
+++ b/doc/bugs/Bloom_filter_capacity_too_large_to_represent/comment_4_9fb9fdbc6218d6b86b0921f411f78891._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.132"
+ subject="turns out to be an upstream bug already filed"
+ date="2014-09-12T17:46:23Z"
+ content="""
+It seems that this is a bug on bloomfilter 2.0.0.0 on armel generally. It's also preventing this newer version from building on armel currently:
+
+<http://bugs.debian.org/756801>
+
+The git-annex standalone arm autobuilder installed it with cabal, so ended up with the newer, broken version. 
+"""]]

diff --git a/doc/forum/usability:_creating_an_archive_on_a_new_external_drive.mdwn b/doc/forum/usability:_creating_an_archive_on_a_new_external_drive.mdwn
index 9a2d6d4..a6bc0b7 100644
--- a/doc/forum/usability:_creating_an_archive_on_a_new_external_drive.mdwn
+++ b/doc/forum/usability:_creating_an_archive_on_a_new_external_drive.mdwn
@@ -6,7 +6,7 @@ expected result: i see files
 
 actual result: i see a bare git repository.
 
-if i first `git init` the directory so it's not bare, at least i get a better handle on it.
+if i first `git init` the directory so it's not bare, at least i get a better handle on it: i can sync with the assistant, then `git merge synced/master` to see the files.
 
 really confusing to me, sorry if it's a dupe... 
 

sigh - typo, no sleep again :(
diff --git a/doc/forum/usability:_creating_an_archive_on_a_new_external_drive.mdwn b/doc/forum/usability:_creating_an_archive_on_a_new_external_drive.mdwn
index a9dc8b3..9a2d6d4 100644
--- a/doc/forum/usability:_creating_an_archive_on_a_new_external_drive.mdwn
+++ b/doc/forum/usability:_creating_an_archive_on_a_new_external_drive.mdwn
@@ -10,4 +10,4 @@ if i first `git init` the directory so it's not bare, at least i get a better ha
 
 really confusing to me, sorry if it's a dupe... 
 
-workaround: use the commandline: `git clone <repo>` and `git annex get`. --[[anarcat]
+workaround: use the commandline: `git clone <repo>` and `git annex get`. --[[anarcat]]

workaround
diff --git a/doc/forum/usability:_creating_an_archive_on_a_new_external_drive.mdwn b/doc/forum/usability:_creating_an_archive_on_a_new_external_drive.mdwn
index d5fd768..a9dc8b3 100644
--- a/doc/forum/usability:_creating_an_archive_on_a_new_external_drive.mdwn
+++ b/doc/forum/usability:_creating_an_archive_on_a_new_external_drive.mdwn
@@ -6,4 +6,8 @@ expected result: i see files
 
 actual result: i see a bare git repository.
 
-really confusing to me, sorry if it's a dupe... --[[anarcat]
+if i first `git init` the directory so it's not bare, at least i get a better handle on it.
+
+really confusing to me, sorry if it's a dupe... 
+
+workaround: use the commandline: `git clone <repo>` and `git annex get`. --[[anarcat]

diff --git a/doc/forum/usability:_creating_an_archive_on_a_new_external_drive.mdwn b/doc/forum/usability:_creating_an_archive_on_a_new_external_drive.mdwn
new file mode 100644
index 0000000..d5fd768
--- /dev/null
+++ b/doc/forum/usability:_creating_an_archive_on_a_new_external_drive.mdwn
@@ -0,0 +1,9 @@
+story: i got a new drive from the store. plug it in. it's recognized by XFCE and mounted automatically. turns out it's NTFS, but Debian doesn't seem to mind.
+
+go in the assistant, add it as an "External drive", make it a "full backup" and let it sync.
+
+expected result: i see files
+
+actual result: i see a bare git repository.
+
+really confusing to me, sorry if it's a dupe... --[[anarcat]

Added a comment
diff --git a/doc/bugs/Bloom_filter_capacity_too_large_to_represent/comment_3_5790bbbe347e1806062ccb60fcad046a._comment b/doc/bugs/Bloom_filter_capacity_too_large_to_represent/comment_3_5790bbbe347e1806062ccb60fcad046a._comment
new file mode 100644
index 0000000..a11d0ef
--- /dev/null
+++ b/doc/bugs/Bloom_filter_capacity_too_large_to_represent/comment_3_5790bbbe347e1806062ccb60fcad046a._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.132"
+ subject="comment 3"
+ date="2014-09-12T16:38:47Z"
+ content="""
+I have reproduced the bug, using the standalone build on an arm box (turtle). 
+
+On the same box, the debian git-annex build works ok.
+
+Suggests to me the problem is related to the cross-compiling method used for the standalone arm build.
+"""]]

Added a comment
diff --git a/doc/bugs/Bloom_filter_capacity_too_large_to_represent/comment_2_9b74457549e2739ae45dccd128de946f._comment b/doc/bugs/Bloom_filter_capacity_too_large_to_represent/comment_2_9b74457549e2739ae45dccd128de946f._comment
new file mode 100644
index 0000000..803465e
--- /dev/null
+++ b/doc/bugs/Bloom_filter_capacity_too_large_to_represent/comment_2_9b74457549e2739ae45dccd128de946f._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.132"
+ subject="comment 2"
+ date="2014-09-12T16:34:56Z"
+ content="""
+However, in Greg's case he had no such configuration. Instead, I think something is broken with the use of floating point or bit math that bloomfilter uses, on the NAS where he's using git-annex.
+
+I have made git-annex not crash when this happens, just show a warning and fall back to a reasonable default bloom filter size. If the problem is with the bit math, then the bloom filter may not work either, which would probably show up as false negatives, so `git annex unused` not finding things that are unused. 
+
+I need to update the armel build with this so Greg can test it..
+"""]]

typo
diff --git a/doc/git-annex.mdwn b/doc/git-annex.mdwn
index 224580d..71f0c0b 100644
--- a/doc/git-annex.mdwn
+++ b/doc/git-annex.mdwn
@@ -513,7 +513,7 @@ subdirectories).
 * `fsck [path ...]`
 
   With no parameters, this command checks the whole annex for consistency,
-  and warns about or fixes any problems found. This is a good compliment to
+  and warns about or fixes any problems found. This is a good complement to
   `git fsck`.
 
   With parameters, only the specified files are checked.