Recent changes to this wiki:

diff --git a/doc/forum/Stale_keys_and_.cache_files_left_in_.git__47__annex__47__objects.mdwn b/doc/forum/Stale_keys_and_.cache_files_left_in_.git__47__annex__47__objects.mdwn
new file mode 100644
index 0000000..043a3f2
--- /dev/null
+++ b/doc/forum/Stale_keys_and_.cache_files_left_in_.git__47__annex__47__objects.mdwn
@@ -0,0 +1,39 @@
+I recently migrated some of my repositories from WORM to SHA1E, and
+noticed after finishing conversion and dropping all WORM keys that
+there are some stale files and directories left over in the
+.git/annex/objects directory. These seem to fall into two categories:
+
+1. There are some empty directories meant for WORM-keys. Strangely, I
+don’t believe the content of these keys has ever been present on this
+machine, and the corresponding .log files do not contain the local
+UUID. What might be the deal with those?
+
+Another set of empty WORM directories housed content I unannexed and
+checked into regular git on my other remote, and then pulled locally.
+A subsequent «dropunused» seems to have left the empty directories
+after dropping their content.
+
+I suppose the stale directories can be safely pruned away?
+
+One thing I noticed is that, while the terminal leaf in the objects
+directory is usually sticky (mode +t), the stale directories to
+content I unannexed are all non-sticky. Maybe this gives some
+indication where things got stuck? A few (though not all) of the other
+terminal directories are non-sticky, as well.
+
+2. There are some .map and .cache files leftover in
+.git/annex/objects. This is an indirect repository, but I briefly
+switched it to direct once. The stale files seem to belong to content
+with which I had some difficulties when «git annex add»’ing the files
+(I recall I had to add them multiple times before they were correctly
+indexed). I now examined these files again and noticed they were
+tracked via regular git. I «git rm»’ed them and readded them into the
+annex. Can the stale .cache and .map files be safely deleted?
+
+I noticed some of these keys have the format
+«WORM-s123-m-123456789--name», with an additional dash before the
+mtime. Has there been a format change, or does this indicate a
+problem?
+
+Best regards,
+Z.

Added a comment: Change the name of the bug
diff --git a/doc/bugs/Windows_build_has_hardcoded_paths/comment_3_f9543c0ca1ff81c4d495a01c77429ea8._comment b/doc/bugs/Windows_build_has_hardcoded_paths/comment_3_f9543c0ca1ff81c4d495a01c77429ea8._comment
new file mode 100644
index 0000000..ba06cd4
--- /dev/null
+++ b/doc/bugs/Windows_build_has_hardcoded_paths/comment_3_f9543c0ca1ff81c4d495a01c77429ea8._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="Hans_Ryding"
+ ip="81.229.194.7"
+ subject="Change the name of the bug"
+ date="2014-08-21T09:14:16Z"
+ content="""
+I can't seem to change the name of the bug to something more appropriate.
+Maybe you can?
+"""]]

Added a comment: Quite right
diff --git a/doc/bugs/Windows_build_has_hardcoded_paths/comment_2_58b856e19c8d5e59164b42399ba6b1fd._comment b/doc/bugs/Windows_build_has_hardcoded_paths/comment_2_58b856e19c8d5e59164b42399ba6b1fd._comment
new file mode 100644
index 0000000..a4784c6
--- /dev/null
+++ b/doc/bugs/Windows_build_has_hardcoded_paths/comment_2_58b856e19c8d5e59164b42399ba6b1fd._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="Hans_Ryding"
+ ip="81.229.194.7"
+ subject="Quite right"
+ date="2014-08-21T08:54:50Z"
+ content="""
+Incorrect assumption from my part.
+I reinstalled git into the expected path (C:\program files\Git)
+and the problem is still there.
+
+Running git-annex from command-line works.
+(I tried running git-annex test. It had 23 failed tests,
+most of them because of inability to access the remote: origin.
+But it ran just fine.)
+Running the web-app gives the error listed above.
+"""]]

devblog
diff --git a/doc/devblog/day_218__scary_locking.mdwn b/doc/devblog/day_218__scary_locking.mdwn
new file mode 100644
index 0000000..81afb26
--- /dev/null
+++ b/doc/devblog/day_218__scary_locking.mdwn
@@ -0,0 +1,24 @@
+Plan is to be on vacation and/or low activity this week before DebConf.
+However, today I got involved in fixing a bug that caused the assistant to
+keep files open after syncing with repositories on removable media.
+
+Part of that bug involved lock files not being opend close-on-exec, and
+while fixing that I noticed again that the locking code was scattered all
+around and rather repetitive. That led to a lot of refactoring, which is
+always fun when it involves scary locking code. Thanks goodness for
+referential transparency.
+
+Now there's a Utility.LockFile that works on both POSIX and Windows.
+Howver, that module actually exports very different functions for the two.
+While it might be tempting to try to do a portability layer, the
+two locking models are really very different, and there are lots of gotchas
+such a portability layer would face. The only API that's completely the
+same between the two is dropLock.
+
+This refactoring process and the cleaner, more expressive
+code it led to helped me spot a couple of bugs involving locking. See
+[[!commit e386e26ef207db742da6d406183ab851571047ff]]
+and [[!commit 0a4d301051e4933661b7b0a0791afa95bfe9a1d3]]
+Neither bug has ever seemed to cause
+a problem, but it's nice to be able to spot and fix such bugs before they
+do.

Added a comment: GHC 7.8 Issue
diff --git a/doc/install/cabal/comment_39_a86057d7e6d47113330f79e1812c3a5d._comment b/doc/install/cabal/comment_39_a86057d7e6d47113330f79e1812c3a5d._comment
new file mode 100644
index 0000000..7573b47
--- /dev/null
+++ b/doc/install/cabal/comment_39_a86057d7e6d47113330f79e1812c3a5d._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkftzaCvV7EDKVDfJhsQZ3E1Vn-0db516w"
+ nickname="Edward"
+ subject="GHC 7.8 Issue"
+ date="2014-08-20T20:06:01Z"
+ content="""
+Just an FYI: I tried to \"cabal install --only-dependencies\" with GHC 7.8 and it fails because DAV-1.0.1 is pulling in lens-3.10.3 which is not compatible with GHC 7.8 due to changes in Typeable. 
+
+I don't have enough experience with cabal to figure out why it's not trying to use a newer version of lens.
+"""]]

Added a comment
diff --git a/doc/bugs/Windows_build_has_hardcoded_paths/comment_1_03518523a823a89fbb97b6a57d650e2b._comment b/doc/bugs/Windows_build_has_hardcoded_paths/comment_1_03518523a823a89fbb97b6a57d650e2b._comment
new file mode 100644
index 0000000..f1a170e
--- /dev/null
+++ b/doc/bugs/Windows_build_has_hardcoded_paths/comment_1_03518523a823a89fbb97b6a57d650e2b._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="24.159.78.125"
+ subject="comment 1"
+ date="2014-08-20T14:37:30Z"
+ content="""
+git-annex does not hardcode any paths, and certianly not the path to git. Your system probably does not have the location you installed git added to the PATH. In that case, git-annex may do what windows programs do and look for git.exe in the same directory it was installed into.
+"""]]

diff --git a/doc/bugs/Windows_build_has_hardcoded_paths.mdwn b/doc/bugs/Windows_build_has_hardcoded_paths.mdwn
index 6c2cf84..a1d8ef5 100644
--- a/doc/bugs/Windows_build_has_hardcoded_paths.mdwn
+++ b/doc/bugs/Windows_build_has_hardcoded_paths.mdwn
@@ -11,7 +11,7 @@ You need to install git in order to use git-annex!"
 
 ### What version of git-annex are you using? On what operating system?
 
-Latest git-annex build, from 20140817.
+5.20140817-g71c2250.
 Windows XP.
 
 ### Please provide any additional information below.

diff --git a/doc/bugs/Windows_build_has_hardcoded_paths.mdwn b/doc/bugs/Windows_build_has_hardcoded_paths.mdwn
index 87130a1..6c2cf84 100644
--- a/doc/bugs/Windows_build_has_hardcoded_paths.mdwn
+++ b/doc/bugs/Windows_build_has_hardcoded_paths.mdwn
@@ -11,7 +11,8 @@ You need to install git in order to use git-annex!"
 
 ### What version of git-annex are you using? On what operating system?
 
-Latest windows build, from 20140817
+Latest git-annex build, from 20140817.
+Windows XP.
 
 ### Please provide any additional information below.
 

diff --git a/doc/bugs/Windows_build_has_hardcoded_paths.mdwn b/doc/bugs/Windows_build_has_hardcoded_paths.mdwn
new file mode 100644
index 0000000..87130a1
--- /dev/null
+++ b/doc/bugs/Windows_build_has_hardcoded_paths.mdwn
@@ -0,0 +1,24 @@
+### Please describe the problem.
+
+The windows build seems to be hardcoded to finding git at c:\program files\Git\
+I have git in another directory. Git-annex does not find it.
+
+### What steps will reproduce the problem?
+
+Install git-annex. Run the webapp.
+Get error "Internal Server Error 
+You need to install git in order to use git-annex!"
+
+### What version of git-annex are you using? On what operating system?
+
+Latest windows build, from 20140817
+
+### Please provide any additional information below.
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+
+
+# End of transcript or log.
+"""]]

Added a comment: Log with --debug
diff --git a/doc/bugs/git_annex_repair_fails_-___47__tmp__47__tmprepo.1__47__.git__47__gc.pid:_removeLink:_does_not_exist___40__No_such_file_or_directory__41__/comment_2_b8ee68b445c6a8d27121d90a2eeba0c7._comment b/doc/bugs/git_annex_repair_fails_-___47__tmp__47__tmprepo.1__47__.git__47__gc.pid:_removeLink:_does_not_exist___40__No_such_file_or_directory__41__/comment_2_b8ee68b445c6a8d27121d90a2eeba0c7._comment
new file mode 100644
index 0000000..6f5570e
--- /dev/null
+++ b/doc/bugs/git_annex_repair_fails_-___47__tmp__47__tmprepo.1__47__.git__47__gc.pid:_removeLink:_does_not_exist___40__No_such_file_or_directory__41__/comment_2_b8ee68b445c6a8d27121d90a2eeba0c7._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="jg123h12jh3y12g3y"
+ ip="86.62.100.131"
+ subject="Log with --debug"
+ date="2014-08-20T05:49:02Z"
+ content="""
+https://mega.co.nz/#!HYZmwSIb!gCd9jvVIyYye_bpsUq_vuEed4g7NTlEl2xDRheE1Lx4
+
+This is the log of git annex repair --debug.
+"""]]

Added a comment: brew doesn't include git-remote-gcrypt
diff --git a/doc/forum/gcrypt_os_x_app_vs_brew/comment_3_be4de1663a37f49a4e42d6b21c0178fe._comment b/doc/forum/gcrypt_os_x_app_vs_brew/comment_3_be4de1663a37f49a4e42d6b21c0178fe._comment
new file mode 100644
index 0000000..99f3b7c
--- /dev/null
+++ b/doc/forum/gcrypt_os_x_app_vs_brew/comment_3_be4de1663a37f49a4e42d6b21c0178fe._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="Ganwell"
+ ip="46.14.43.36"
+ subject="brew doesn't include git-remote-gcrypt"
+ date="2014-08-19T21:54:16Z"
+ content="""
+Brew doesn't include git-remote-gcrypt, so I installed your fork of it manually. That works well and if you use a symlink to include it in the PATH you can easily update (pull) the repo. If one can install git-remote-gcrypt using brew, I don't know how.
+
+Best, Jean-Louis
+"""]]

clarify that --all doesn't operate on a single file
diff --git a/doc/git-annex.mdwn b/doc/git-annex.mdwn
index 06e8794..11e086a 100644
--- a/doc/git-annex.mdwn
+++ b/doc/git-annex.mdwn
@@ -78,10 +78,11 @@ subdirectories).
   or transferring them from some kind of key-value store.
 
   Normally git-annex will choose which repository to copy the content from,
-  but you can override this using the `--from` option.  Only the last version
-  of the file is retrieved (use `--all` to retrieve all versions of
-  the file).  `--key=KEY` option can be used to retrieve a specified key
-  without the filename.
+  but you can override this using the `--from` option.
+ 
+  Rather than specifying a filename, the `--all` option can be used to 
+  get all available versions of all files, or the --key=KEY`
+  option can be used to get a specified key.
 
 * `drop [path ...]`
 

Added a comment: git annex view */=podcast
diff --git a/doc/tips/metadata_driven_views/comment_3_196f55e52a5d8a8f061603ab87ad04ad._comment b/doc/tips/metadata_driven_views/comment_3_196f55e52a5d8a8f061603ab87ad04ad._comment
new file mode 100644
index 0000000..e522ed8
--- /dev/null
+++ b/doc/tips/metadata_driven_views/comment_3_196f55e52a5d8a8f061603ab87ad04ad._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnPgn611P6ym5yyL0BS8rUzO0_ZKRldMt0"
+ nickname="Samuel"
+ subject="git annex view */=podcast"
+ date="2014-08-19T06:11:50Z"
+ content="""
+Hi,
+
+Would it be hard to handle the wildcard character in the location view before the = sign.
+
+    git annex foo/=*
+
+works but
+
+    git annex *=/bar
+
+does not.
+"""]]

doc/ minor typos/trailing whitespaces + extension on get options
diff --git a/doc/encryption.mdwn b/doc/encryption.mdwn
index 0dac527..3cbc37e 100644
--- a/doc/encryption.mdwn
+++ b/doc/encryption.mdwn
@@ -17,7 +17,7 @@ remote.
 You should decide whether to use encryption with a special remote before
 any data is stored in it. So, `git annex initremote` requires you
 to specify "encryption=none" when first setting up a remote in order
-to disable encryption. To use encryption, you run 
+to disable encryption. To use encryption, you run
 `git-annex initremote` in one of these ways:
 
 * `git annex initremote newremote type=... encryption=hybrid keyid=KEYID ...`
@@ -29,10 +29,10 @@ to disable encryption. To use encryption, you run
 The [[hybrid_key_design|design/encryption]] allows additional
 encryption keys to be added on to a special remote later. Due to this
 flexibility, it is the default and recommended encryption scheme.
- 
+
 	git annex initremote newremote type=... [encryption=hybrid] keyid=KEYID ...
 
-Here the KEYID(s) are passed to `gpg` to find encryption keys. 
+Here the KEYID(s) are passed to `gpg` to find encryption keys.
 Typically, you will say "keyid=2512E3C7" to use a specific gpg key.
 Or, you might say "keyid=joey@kitenet.net" to search for matching keys.
 
@@ -58,8 +58,8 @@ risks associated with encryption.
 Alternatively, you can configure git-annex to use a shared cipher to
 encrypt data stored in a remote. This shared cipher is stored,
 **unencrypted** in the git repository. So it's shared among every
-clone of the git repository. 
-	
+clone of the git repository.
+
 	git annex initremote newremote type=... encryption=shared
 
 The advantage is you don't need to set up gpg keys. The disadvantage is
@@ -74,10 +74,10 @@ and since it's exactly the way everyone else uses gpg.
 
 	git annex initremote newremote type=.... encryption=pubkey keyid=KEYID ...
 
-A disavantage is that it is not easy to later add additional public keys
+A disadvantage is that it is not easy to later add additional public keys
 to the special remote. While the `enableremote` parameters `keyid+=` and
 `keyid-=` can be used, they have **no effect** on files that are already
-present on the remote. Probably the only use for these parameters is 
+present on the remote. Probably the only use for these parameters is
 to replace a revoked key:
 
 	git annex enableremote myremote keyid-=2512E3C7 keyid+=788A3F4C
diff --git a/doc/git-annex.mdwn b/doc/git-annex.mdwn
index 673e86f..06e8794 100644
--- a/doc/git-annex.mdwn
+++ b/doc/git-annex.mdwn
@@ -64,7 +64,7 @@ subdirectories).
 
   Adds files in the path to the annex. If no path is specified, adds
   files from the current directory and below.
-  
+
   Files that are already checked into git, or that git has been configured
   to ignore will be silently skipped. (Use `--force` to add ignored files.)
 
@@ -78,7 +78,10 @@ subdirectories).
   or transferring them from some kind of key-value store.
 
   Normally git-annex will choose which repository to copy the content from,
-  but you can override this using the `--from` option.
+  but you can override this using the `--from` option.  Only the last version
+  of the file is retrieved (use `--all` to retrieve all versions of
+  the file).  `--key=KEY` option can be used to retrieve a specified key
+  without the filename.
 
 * `drop [path ...]`
 
@@ -272,10 +275,10 @@ subdirectories).
   (Other available variables: feedauthor, itemauthor, itemsummary, itemdescription, itemrights, itemid, itempubdate, title, author)
 
   The `--relaxed` and `--fast` options behave the same as they do in addurl.
-  
+
   When quvi is installed, links in the feed are tested to see if they
   are on a video hosting site, and the video is downloaded. This allows
-  importing eg, youtube playlists.
+  importing e.g., youtube playlists.
 
 * `watch`
 
@@ -319,7 +322,7 @@ subdirectories).
   This disables running a local web browser, and outputs the url you
   can use to open the webapp.
 
-  When using the webapp on a remote computer, you'll almost certianly
+  When using the webapp on a remote computer, you'll almost certainly
   want to enable HTTPS. 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:
@@ -388,7 +391,7 @@ subdirectories).
 
   The name of the remote is the same name used when originally
   creating that remote with "initremote". Run "git annex enableremote"
-  with no parameters to get a list of special remote names.
+  without any name to get a list of special remote names.
 
   Some special remotes may need parameters to be specified every time.
   For example, the directory special remote requires a directory= parameter.
@@ -425,7 +428,7 @@ subdirectories).
   Run without a number to get the current value.
 
   When git-annex is asked to drop a file, it first verifies that the
-  required number of copies can be satisfied amoung all the other
+  required number of copies can be satisfied among all the other
   repositories that have a copy of the file.
 
   This can be overridden on a per-file basis by the annex.numcopies setting
@@ -645,7 +648,7 @@ subdirectories).
   `--format`. The default output format is the same as `--format='${file}\\n'`
 
   These variables are available for use in formats: file, key, backend,
-  bytesize, humansize, keyname, hashdirlower, hashdirmixed, mtime (for 
+  bytesize, humansize, keyname, hashdirlower, hashdirmixed, mtime (for
   the mtime field of a WORM key).
 
 * `whereis [path ...]`
@@ -715,13 +718,13 @@ subdirectories).
 
 * `metadata [path ...] [-s field=value -s field+=value -s field-=value ...] [-g field]`
 
-  The content of a file can have any number of metadata fields 
+  The content of a file can have any number of metadata fields
   attached to it to describe it. Each metadata field can in turn
-  have any number of values. 
-  
+  have any number of values.
+
   This command can be used to set metadata, or show the currently set
   metadata.
-  
+
   To show current metadata, run without any -s parameters. The --json
   option will enable json output.
 
@@ -750,7 +753,7 @@ subdirectories).
   and checks out the view branch. Only files in the current branch whose
   metadata matches all the specified field values and tags will be
   shown in the view.
-  
+
   Multiple values for a metadata field can be specified, either by using
   a glob (`field="*"`) or by listing each wanted value. The resulting view
   will put files in subdirectories according to the value of their fields.
@@ -785,9 +788,9 @@ subdirectories).
   Changes the current view, adding an additional level of directories
   to categorize the files.
 
-  For example, when the view is by author/tag, `vadd year=*` will 
-  change it to year/author/tag. 
-  
+  For example, when the view is by author/tag, `vadd year=*` will
+  change it to year/author/tag.
+
   So will `vadd year=2014 year=2013`, but limiting the years in view
   to only those two.
 
@@ -934,7 +937,7 @@ subdirectories).
 * `findref [ref]`
 
   This is similar to the find command, but instead of finding files in the
-  current work tree, it finds files in the specified git ref. 
+  current work tree, it finds files in the specified git ref.
 
   Most MATCHING OPTIONS can be used with findref, to limit the files it
   finds. However, the --include and --exclude options will not work.
@@ -1125,7 +1128,7 @@ subdirectories).
   Caused a desktop notification to be displayed after each successful
   file download and upload.
 
-  (Only supported on some platforms, eg Linux with dbus. A no-op when
+  (Only supported on some platforms, e.g. Linux with dbus. A no-op when
   not supported.)
 
 * `--notify-start`
@@ -1316,7 +1319,7 @@ to e.g., fsck a repository on a removable drive when the drive gets
 connected.
 
 The scheduled jobs can be configured using `git annex vicfg` or
-`git annex schedule`. 
+`git annex schedule`.
 
 These actions are available: "fsck self", "fsck UUID" (where UUID
 is the UUID of a remote to fsck). After the action comes the duration
@@ -1372,7 +1375,7 @@ Here are all the supported configuration settings.
 
   This is a deprecated setting. You should instead use the
   `git annex numcopies` command to configure how many copies of files
-  are kept acros all repositories.
+  are kept across all repositories.
 
   This config setting is only looked at when `git annex numcopies` has
   never been configured.

(Diff truncated)
diff --git a/doc/forum/adding_files_without_hashing_them.mdwn b/doc/forum/adding_files_without_hashing_them.mdwn
new file mode 100644
index 0000000..a9aef30
--- /dev/null
+++ b/doc/forum/adding_files_without_hashing_them.mdwn
@@ -0,0 +1 @@
+I would like to be able to add files without having to hash its contents (like WORM) but being able to modify them and record its changes. Is this possible? In other words, I would like to provide other not-that-expensive mechanism for identifying files of a particular version.

Added a comment
diff --git a/doc/bugs/Possible_data-loss_if_WORM_keys_do_not_encode_relative_paths/comment_5_8378cd8c03fabdaa300194b66c1ea53c._comment b/doc/bugs/Possible_data-loss_if_WORM_keys_do_not_encode_relative_paths/comment_5_8378cd8c03fabdaa300194b66c1ea53c._comment
new file mode 100644
index 0000000..72bc4f8
--- /dev/null
+++ b/doc/bugs/Possible_data-loss_if_WORM_keys_do_not_encode_relative_paths/comment_5_8378cd8c03fabdaa300194b66c1ea53c._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="zardoz"
+ ip="78.48.163.229"
+ subject="comment 5"
+ date="2014-08-18T20:54:10Z"
+ content="""
+> True of a single filesystem, but not of a set of connected git repositories.
+
+That’s a good point. Might depend on the use case, though.
+
+> The probabilities of these seem low, but perhaps not as low as the probability that there will be two differing files with the same name+size+mtime in the first place. 
+
+This one I’m not completely sure about. E.g., I have an annex with web pages mirrored from the web. Due to the crawler implementation, there are lots of «index.html» or «favicon.ico» with the same mtime (in particular when mtime is read with a 1 sec. precision). Files like favicon are often bitmaps of the same resolution and often have the same size due to this. Because there are file-formats where both size and basename are semantically pre-determined, there is zero entropy from these sources alone (also cf. «readme.txt»). The entropy of mtime alone is not really large, I suppose, and in some use-cases will also approach zero (think «initializing a repo by cp -r on a fast disk without preserving mtime). The relative path could make a huge difference there. I believe this argument is actually what worried me the most. Does it seem valid?
+
+Apart from entropy, there’s the non-probabilistic advantage we discussed (granted, with some limiting constraints which one has to assure for oneself). Granted, one might argue a hash would be the better way, but this is not always practical in every setup.
+"""]]

Added a comment
diff --git a/doc/bugs/Possible_data-loss_if_WORM_keys_do_not_encode_relative_paths/comment_4_4241c05a0fa7ce597c75ff5992b71b89._comment b/doc/bugs/Possible_data-loss_if_WORM_keys_do_not_encode_relative_paths/comment_4_4241c05a0fa7ce597c75ff5992b71b89._comment
new file mode 100644
index 0000000..a02b1de
--- /dev/null
+++ b/doc/bugs/Possible_data-loss_if_WORM_keys_do_not_encode_relative_paths/comment_4_4241c05a0fa7ce597c75ff5992b71b89._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.7"
+ subject="comment 4"
+ date="2014-08-18T18:39:33Z"
+ content="""
+> Rather than saying that the relative path adds additional entropy, what I was aiming at is the file-system cannot have two alternate versions of one file name at the same path with the same mtime
+
+True of a single filesystem, but not of a set of connected git repositories. :)
+
+So there are multiple scenarios when encoding the file path in the key doesn't help. The probabilities of these seem low, but perhaps not as low as the probability that there will be two differing files with the same name+size+mtime in the first place. It's not clear to me that it adds more than a false sense of security to change from basename to git filename.
+"""]]

cleanup branch list
diff --git a/doc/download.mdwn b/doc/download.mdwn
index 8c6f5b5..46d397f 100644
--- a/doc/download.mdwn
+++ b/doc/download.mdwn
@@ -26,13 +26,10 @@ The git repository has some branches:
   (merge it into master if you need it)
 * `no-bloom` avoids using bloom filters. (merge it into master if you need it)
 * `no-s3` avoids using the S3 library (merge it into master if you need it)
-* `debian-stable` contains the latest backport of git-annex to Debian
-  stable.
+* `debian-*-backport` contains the latest backport of git-annex.
 * `tweak-fetch` adds support for the git tweak-fetch hook, which has
   been proposed and implemented but not yet accepted into git.
 * `setup` contains configuration for this website
-* `pristine-tar` contains [pristine-tar](http://kitenet.net/~joey/code/pristine-tar)
-  data to create tarballs of any past git-annex release.
 
 ----
 

add news item for git-annex 5.20140817
diff --git a/doc/news/version_5.20140606.mdwn b/doc/news/version_5.20140606.mdwn
deleted file mode 100644
index d7f26b8..0000000
--- a/doc/news/version_5.20140606.mdwn
+++ /dev/null
@@ -1,14 +0,0 @@
-git-annex 5.20140606 released with [[!toggle text="these changes"]]
-[[!toggleable text="""
-   * webapp: When adding a new local repository, fix bug that caused its
-     group and preferred content to be set in the current repository,
-     even when not combining.
-   * webapp: Avoid stomping on existing description, group and
-     preferred content settings when enabling or combining with
-     an already existing remote.
-   * assistant: Make sanity checker tmp dir cleanup code more robust.
-   * unused: Avoid checking view branches for unused files.
-   * webapp: Include ssh port in mangled hostname.
-   * Windows: Fix bug introduced in last release that caused files
-     in the git-annex branch to have lines teminated with \r.
-   * Windows: Fix retrieving of files from local bare git repositories."""]]
\ No newline at end of file
diff --git a/doc/news/version_5.20140817.mdwn b/doc/news/version_5.20140817.mdwn
new file mode 100644
index 0000000..82e44eb
--- /dev/null
+++ b/doc/news/version_5.20140817.mdwn
@@ -0,0 +1,42 @@
+git-annex 5.20140817 released with [[!toggle text="these changes"]]
+[[!toggleable text="""
+   * New chunk= option to chunk files stored in special remotes.
+     Supported by: directory, S3, webdav, gcrypt, rsync, and all external
+     and hook special remotes.
+   * Partially transferred files are automatically resumed when using
+     chunked remotes!
+   * The old chunksize= option is deprecated. Do not use for new remotes.
+   * Legacy code for directory remotes using the old chunksize= option
+     will keep them working, but more slowly than before.
+   * webapp: Automatically install Konqueror integration scripts
+     to get and drop files.
+   * repair: Removing bad objects could leave fsck finding no more
+     unreachable objects, but some branches no longer accessible.
+     Fix this, including support for fixing up repositories that
+     were incompletely repaired before.
+   * Fix cost calculation for non-encrypted remotes.
+   * Display exception message when a transfer fails due to an exception.
+   * WebDAV: Sped up by avoiding making multiple http connections
+     when storing a file.
+   * WebDAV: Avoid buffering whole file in memory when uploading and
+     downloading.
+   * WebDAV: Dropped support for DAV before 1.0.
+   * testremote: New command to test uploads/downloads to a remote.
+   * Dropping an object from a bup special remote now deletes the git branch
+     for the object, although of course the object's content cannot be deleted
+     due to the nature of bup.
+   * unlock: Better error handling; continue past files that are not available
+     or cannot be unlocked due to disk space, and try all specified files.
+   * Windows: Now uses actual inode equivilants in new direct mode
+     repositories, for safer detection of eg, renaming of files with the same
+     size and mtime.
+   * direct: Fix ugly warning messages.
+   * WORM backend: When adding a file in a subdirectory, avoid including the
+     subdirectory in the key name.
+   * S3, Glacier, WebDAV: Fix bug that prevented accessing the creds
+     when the repository was configured with encryption=shared embedcreds=yes.
+   * direct: Avoid leaving file content in misctemp if interrupted.
+   * git-annex-shell sendkey: Don't fail if a remote asks for a key to be sent
+     that already has a transfer lock file indicating it's being sent to that
+     remote. The remote may have moved between networks, or reconnected.
+   * Switched from the old haskell HTTP library to http-conduit."""]]
\ No newline at end of file

Added a comment
diff --git a/doc/devblog/day_216__various_minor_bugs/comment_3_05177e2ed414d22711dcec57a614e38c._comment b/doc/devblog/day_216__various_minor_bugs/comment_3_05177e2ed414d22711dcec57a614e38c._comment
new file mode 100644
index 0000000..4b3f024
--- /dev/null
+++ b/doc/devblog/day_216__various_minor_bugs/comment_3_05177e2ed414d22711dcec57a614e38c._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="EskildHustvedt"
+ ip="80.202.103.55"
+ subject="comment 3"
+ date="2014-08-16T15:22:35Z"
+ content="""
+Ah, well then, that sounds a lot more reasonable. Though legal, I have yet to hear of a sane reason for using newlines in filenames.
+"""]]

Added a comment
diff --git a/doc/bugs/Possible_data-loss_if_WORM_keys_do_not_encode_relative_paths/comment_3_bda1e0d3569a6becf374d0e820219469._comment b/doc/bugs/Possible_data-loss_if_WORM_keys_do_not_encode_relative_paths/comment_3_bda1e0d3569a6becf374d0e820219469._comment
new file mode 100644
index 0000000..54fe869
--- /dev/null
+++ b/doc/bugs/Possible_data-loss_if_WORM_keys_do_not_encode_relative_paths/comment_3_bda1e0d3569a6becf374d0e820219469._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="zardoz"
+ ip="78.48.163.229"
+ subject="comment 3"
+ date="2014-08-16T13:58:28Z"
+ content="""
+One scenario where the above guarantee would be violated is when one
+moves a new file of identical size, basename, and mtime, into a path
+where a key-colliding file has been kept before. Still, I’d consider
+this a scenario one could reasonably control for (especially in the
+archive usecase); plus, even without manual control such a
+move-induced collision would be much more unlikely than a collision of
+basenames only.
+
+"""]]

Added a comment
diff --git a/doc/bugs/Possible_data-loss_if_WORM_keys_do_not_encode_relative_paths/comment_2_e8f011263bfa4c3c3d04494ea1c88523._comment b/doc/bugs/Possible_data-loss_if_WORM_keys_do_not_encode_relative_paths/comment_2_e8f011263bfa4c3c3d04494ea1c88523._comment
new file mode 100644
index 0000000..90684d9
--- /dev/null
+++ b/doc/bugs/Possible_data-loss_if_WORM_keys_do_not_encode_relative_paths/comment_2_e8f011263bfa4c3c3d04494ea1c88523._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="zardoz"
+ ip="78.48.163.229"
+ subject="comment 2"
+ date="2014-08-16T11:42:22Z"
+ content="""
+Hm, I don’t quite follow the remark on having everything in a single
+directory. Rather than saying that the relative path adds additional
+entropy, what I was aiming at is the file-system cannot have two
+alternate versions of one file name at the same path with the same
+mtime, and that’s why it occurred to me that encoding both path and
+mtime within the key doesn’t just increase the odds, but effectively
+_guarantees_ that there won’t be any collisions. Does this seem to
+hold up, or am I missing something? (Of course one can fudge the
+mtimes, but that’s something under the user’s control.)
+
+While a large repo with many files very likely has lots of distinct
+files with identical basename, mtime (in s.) and size, all these files
+with the same mtime must necessarily be located at different paths.
+
+"""]]

devblog
diff --git a/doc/devblog/day_217__autobuilders.mdwn b/doc/devblog/day_217__autobuilders.mdwn
new file mode 100644
index 0000000..2a58e0c
--- /dev/null
+++ b/doc/devblog/day_217__autobuilders.mdwn
@@ -0,0 +1,10 @@
+Over the past couple days, got the arm autobuilder working again. It had
+been down since June with several problems. cabal install tended to crash;
+apparenty this has something to do with threading in user-mode qemu,
+because -j1 avoids that. And strange invalid character problems were fixed
+by downgrading file-embed. Also, with Yury's help I got the Windows
+autobuilder upgraded to the new Haskell Platform and working again.
+
+Today a last few finishing touches, including getting rid of the last
+dependency on the old haskell HTTP library, since http-conduit is being
+used now. Ready for the release!

Added a comment
diff --git a/doc/bugs/git-annex_branch_shows_commit_with_looong_commitlog/comment_4_094191b806ac76b2aef325733fe37136._comment b/doc/bugs/git-annex_branch_shows_commit_with_looong_commitlog/comment_4_094191b806ac76b2aef325733fe37136._comment
new file mode 100644
index 0000000..e80d66b
--- /dev/null
+++ b/doc/bugs/git-annex_branch_shows_commit_with_looong_commitlog/comment_4_094191b806ac76b2aef325733fe37136._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Francois"
+ ip="2001:788:5:1:29c2:de49:9811:51c8"
+ subject="comment 4"
+ date="2014-08-15T20:51:12Z"
+ content="""
+Bonus question: is there any way to bring this repo back into a working state (for instance with git-filter-branch?) ?
+"""]]

Added a comment
diff --git a/doc/bugs/git-annex_branch_shows_commit_with_looong_commitlog/comment_3_cbbeaa691d102bd7d29f5e9bad9d6f53._comment b/doc/bugs/git-annex_branch_shows_commit_with_looong_commitlog/comment_3_cbbeaa691d102bd7d29f5e9bad9d6f53._comment
new file mode 100644
index 0000000..8651405
--- /dev/null
+++ b/doc/bugs/git-annex_branch_shows_commit_with_looong_commitlog/comment_3_cbbeaa691d102bd7d29f5e9bad9d6f53._comment
@@ -0,0 +1,32 @@
+[[!comment format=mdwn
+ username="Francois"
+ ip="2001:788:5:1:29c2:de49:9811:51c8"
+ subject="comment 3"
+ date="2014-08-15T20:45:38Z"
+ content="""
+I've been experiencing the exact same problem and searching for **recovery from race** lead me to this bug report. Thanks for reporting it!
+
+For a few months, a repo storing ~19'000 files (mostly immutable pictures) started to launch memory hungry \"git log\" processes. For example:
+
+    4797 francois  20   0 8118296 7.719g   2032 D  22.3 50.2   0:11.61 git                                                                                                   
+
+    4797 pts/1    D+     0:12 git --git-dir=~/Pictures/.git --work-tree=~/Pictures -c core.bare=false log refs/heads/git-annex..52e44b967ad5d316d832562be02c5555c1f6d2a4 --oneline -n1
+
+Thanks to the hints found in this report, I was able to find many huge commit messages such as this one:
+
+    $ git show 6357b208 
+    commit 6357b2081e7c85dfe1ccc10824b75f3e212e6386
+    Author: Francois Deppierraz <francois@ctrlaltdel.ch>
+    Date:   Sat Jun 14 10:38:46 2014 +0200
+
+        update (recovery from race) (recovery from race) (recovery from race) (recovery from race) (recovery from race) [...]
+
+    $ git show 6357b208 | wc 
+      5  444026 3108236
+
+There were probably many new files added on Jun 14th and looking for a way to increase to sync speed, especially to a S3-like remote, I found the solution on this wiki for [multiple concurrent transfers](https://git-annex.branchable.com/forum/Feature_request:_Multiple_concurrent_transfers/).
+
+This looks like a likely culprit for generating race conditions. What do you think?
+
+    git-annex version: 5.20140412ubuntu1
+"""]]

silly markdown..
diff --git a/doc/devblog/day_216__various_minor_bugs.mdwn b/doc/devblog/day_216__various_minor_bugs.mdwn
index 0531ddb..a9c49a9 100644
--- a/doc/devblog/day_216__various_minor_bugs.mdwn
+++ b/doc/devblog/day_216__various_minor_bugs.mdwn
@@ -1,7 +1,7 @@
 Working on getting caught up with backlog. 73 messages remain.
 
 Several minor bugs were fixed today. All edge cases. The most edge case one
-of all, I could not fix: git-annex cannot add a file that has a space^Wnewline
+of all, I could not fix: git-annex cannot add a file that has a newline
 in its filename, because `git cat-file --batch`'s interface does not support such
 filenames.
 

Added a comment
diff --git a/doc/devblog/day_216__various_minor_bugs/comment_2_6b06b3f46f20a6d2e60684d1d59fca07._comment b/doc/devblog/day_216__various_minor_bugs/comment_2_6b06b3f46f20a6d2e60684d1d59fca07._comment
new file mode 100644
index 0000000..559689b
--- /dev/null
+++ b/doc/devblog/day_216__various_minor_bugs/comment_2_6b06b3f46f20a6d2e60684d1d59fca07._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.7"
+ subject="comment 2"
+ date="2014-08-15T19:45:28Z"
+ content="""
+That was a typo. Of course, spaces are no problem. Newlines in filenames, on the other hand..
+"""]]

fix link
diff --git a/doc/install.mdwn b/doc/install.mdwn
index 0d8bb1d..7fe21c9 100644
--- a/doc/install.mdwn
+++ b/doc/install.mdwn
@@ -3,7 +3,7 @@
 [[!table format=dsv header=yes data="""
 detailed instructions             | quick install
 [[OSX]]                           | [download git-annex.app](http://downloads.kitenet.net/git-annex/OSX/current/)
-&nbsp;&nbsp;[[Homebrew]]            | `brew install git-annex`
+&nbsp;&nbsp;[[OSX/Homebrew]]      | `brew install git-annex`
 [[Android]]                       | [download git-annex.apk](http://downloads.kitenet.net/git-annex/android/current/) **beta**
 [[Linux|linux_standalone]]        | [download prebuilt linux tarball](http://downloads.kitenet.net/git-annex/linux/current/)
 &nbsp;&nbsp;[[Debian]]            | `apt-get install git-annex`

Added a comment
diff --git a/doc/install/OSX/comment_8_b94193a0583605920effa7179a6164d9._comment b/doc/install/OSX/comment_8_b94193a0583605920effa7179a6164d9._comment
new file mode 100644
index 0000000..902d87d
--- /dev/null
+++ b/doc/install/OSX/comment_8_b94193a0583605920effa7179a6164d9._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.7"
+ subject="comment 8"
+ date="2014-08-15T19:26:07Z"
+ content="""
+@David, the bundle contains the man page since a while.
+
+@Michael, the best way to get a git-annex that does not use those bundled programs is probably to instead install it using homebrew.
+"""]]

more reorg
diff --git a/doc/install/OSX.mdwn b/doc/install/OSX.mdwn
index 775771e..0eab6eb 100644
--- a/doc/install/OSX.mdwn
+++ b/doc/install/OSX.mdwn
@@ -36,4 +36,4 @@ MacPorts tools. See [[MacPorts]].
 
 ## building it yourself
 
-See [[cabal]].
+See [[porting]].
diff --git a/doc/install/OSX/cabal.mdwn b/doc/install/OSX/cabal.mdwn
deleted file mode 100644
index b3629c6..0000000
--- a/doc/install/OSX/cabal.mdwn
+++ /dev/null
@@ -1,6 +0,0 @@
-If you cannot get a OSX build of git-annex suitable for your computer,
-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]].
diff --git a/doc/install/OSX/cabal/comment_11_740fa80e2e54e6fb570f820ff1f56440._comment b/doc/install/OSX/cabal/comment_11_740fa80e2e54e6fb570f820ff1f56440._comment
deleted file mode 100644
index d0c74d6..0000000
--- a/doc/install/OSX/cabal/comment_11_740fa80e2e54e6fb570f820ff1f56440._comment
+++ /dev/null
@@ -1,8 +0,0 @@
-[[!comment format=mdwn
- username="https://www.google.com/accounts/o8/id?id=AItOawmyFvkaewo432ELwtCoecUGou4v3jCP0Pc"
- nickname="Eric"
- subject="Updating to latest build"
- date="2013-01-25T06:05:35Z"
- content="""
-What is the appropriate way to update to the latest build of git-annex using cabal?
-"""]]
diff --git a/doc/install/OSX/cabal/comment_13_d6f1db401858ffea23c123db49f5b296._comment b/doc/install/OSX/cabal/comment_13_d6f1db401858ffea23c123db49f5b296._comment
deleted file mode 100644
index 875db34..0000000
--- a/doc/install/OSX/cabal/comment_13_d6f1db401858ffea23c123db49f5b296._comment
+++ /dev/null
@@ -1,8 +0,0 @@
-[[!comment format=mdwn
- username="http://joeyh.name/"
- ip="4.154.3.125"
- subject="comment 13"
- date="2013-02-05T19:46:29Z"
- content="""
-@eric `cabal update && cabal upgrade git-annex`
-"""]]
diff --git a/doc/install/OSX/cabal/comment_14_035f856923276b0edad879e196e94097._comment b/doc/install/OSX/cabal/comment_14_035f856923276b0edad879e196e94097._comment
deleted file mode 100644
index 1072dbc..0000000
--- a/doc/install/OSX/cabal/comment_14_035f856923276b0edad879e196e94097._comment
+++ /dev/null
@@ -1,9 +0,0 @@
-[[!comment format=mdwn
- username="https://www.google.com/accounts/o8/id?id=AItOawmCmNS-oUgYfNg85-LPuxzTZJUp0sIgprM"
- nickname="Jonas"
- subject="more homebrew"
- date="2013-02-16T19:46:47Z"
- content="""
-i had macports installed. then i installed brew, instaled haskell via brew. i needed to set 
-    PATH=$HOME/bin:/usr/local/bin:$PATH
-"""]]
diff --git a/doc/install/OSX/cabal/comment_15_336e0acb00e84943715e69917643a69e._comment b/doc/install/OSX/cabal/comment_15_336e0acb00e84943715e69917643a69e._comment
deleted file mode 100644
index 05f5654..0000000
--- a/doc/install/OSX/cabal/comment_15_336e0acb00e84943715e69917643a69e._comment
+++ /dev/null
@@ -1,35 +0,0 @@
-[[!comment format=mdwn
- username="https://launchpad.net/~wincus"
- nickname="Juan Moyano"
- subject="git annex on Snow Leopard"
- date="2013-03-26T16:02:54Z"
- content="""
-I'm having the same issue as @Pere, with a newer version of DAV :(
-
-cabal: Error: some packages failed to install:
-DAV-0.3.1 failed during the building phase. The exception was:
-ExitFailure 11
-git-annex-4.20130323 depends on shakespeare-css-1.0.3 which failed to install.
-persistent-1.1.5.1 failed during the building phase. The exception was:
-ExitFailure 11
-persistent-template-1.1.3.1 depends on persistent-1.1.5.1 which failed to
-install.
-shakespeare-css-1.0.3 failed during the building phase. The exception was:
-ExitFailure 11
-yesod-1.1.9.2 depends on shakespeare-css-1.0.3 which failed to install.
-yesod-auth-1.1.5.3 depends on shakespeare-css-1.0.3 which failed to install.
-yesod-core-1.1.8.2 depends on shakespeare-css-1.0.3 which failed to install.
-yesod-default-1.1.3.2 depends on shakespeare-css-1.0.3 which failed to
-install.
-yesod-form-1.2.1.3 depends on shakespeare-css-1.0.3 which failed to install.
-yesod-json-1.1.2.2 depends on shakespeare-css-1.0.3 which failed to install.
-yesod-persistent-1.1.0.1 depends on shakespeare-css-1.0.3 which failed to
-install.
-yesod-static-1.1.2.2 depends on shakespeare-css-1.0.3 which failed to install.
-
-
-
-*Any ideas?*
-
-
-"""]]
diff --git a/doc/install/OSX/cabal/comment_16_1befafa862b7d07b1f6e57c0182497cf._comment b/doc/install/OSX/cabal/comment_16_1befafa862b7d07b1f6e57c0182497cf._comment
deleted file mode 100644
index 0098e74..0000000
--- a/doc/install/OSX/cabal/comment_16_1befafa862b7d07b1f6e57c0182497cf._comment
+++ /dev/null
@@ -1,36 +0,0 @@
-[[!comment format=mdwn
- username="https://www.google.com/accounts/o8/id?id=AItOawkurjhi0CRJvgm7QNaZDWS9hitBtavqIpc"
- nickname="Bret"
- subject="Snow Leopard Issues"
- date="2013-04-14T20:17:17Z"
- content="""
-I was able to build snow leopard completely for the first time over last night (it took a very long time to build all the tools and dependancies).  Woohoo!
-
-The way I was able to fully build on a 32-bit 10.6 machine was this
-
-1. Delete ~/.ghc and ~/.cabal.  They were full of random things and were causing problems.
-2. `brew uninstall ghc and haskell-platform`
-3. `brew update`
-4. `brew install git ossp-uuid md5sha1sum coreutils libgsasl gnutls libidn libgsasl pkg-config libxml2`
-5. `brew upgrade git ossp-uuid md5sha1sum coreutils libgsasl gnutls libidn libgsasl pkg-config libxml2` (Some of these were already installed/up to date.
-6. `brew link libxml2`
-7. `brew install haskell-platform`  (This takes a long, long time).
-8. `cabal update` (assuming you have added `~/.cabal/bin` to your path
-9. `cabal install cablal-install`
-10. `cabal install c2hs`
-11. `cabal install git-annex`
-
-
-It also appears to be running fairly smoothly than it had in the past on a 32-bit SL system.  Thats also neat.  
-
-The problem is that it seems to not really work as git annex though, probably due to the error relating you get when you start up the webapp:
-Running
-`git annex webapp` 
-The browser starts up, and I get 3 of these errors:
-`Watcher crashed: Need at least OSX 10.7.0 for file-level FSEvents`
-
-Pairing with a local computer appears to work to systems running 10.7, but when you complete the process, they never show up in the repository list.
-
-
-Also on a side note, when running `git annex webapp` it triggers the opening of an html file in whatever the default html file handler is.  I edit a lot of html, so for me that is usually a text editor.  I had to change the file handler to open html files with my web browser for the `git annex webapp` to actually work.  Is there a way to change that so that `git annex webapp` uses the default web browser for the system rather than the default html file handler?
-"""]]
diff --git a/doc/install/OSX/cabal/comment_22_6b5f44a98f9d37a1c6ecfe19a60fe6c5._comment b/doc/install/OSX/cabal/comment_22_6b5f44a98f9d37a1c6ecfe19a60fe6c5._comment
deleted file mode 100644
index 7dfa481..0000000
--- a/doc/install/OSX/cabal/comment_22_6b5f44a98f9d37a1c6ecfe19a60fe6c5._comment
+++ /dev/null
@@ -1,12 +0,0 @@
-[[!comment format=mdwn
- username="https://www.google.com/accounts/o8/id?id=AItOawmRFKwny4rArBaz-36xTcsJYqKIgdDaw5Q"
- nickname="Andrew"
- subject="comment 22"
- date="2013-07-25T02:19:53Z"
- content="""
-Rather than specifying --bindir on the command line for cabal, I edited my ~/.cabal/config to add this line:
-
-    symlink-bindir: /usr/local/bin
-
-This installs the binaries to ~/.cabal/bin but symlinks them into /usr/local/bin alongside the links that homebrew installs. Additionally, I symlinked /usr/local/bin/git-annex-shell to /usr/local/bin/git-annex which made things work great from remote hosts via ssh.
-"""]]
diff --git a/doc/install/OSX/cabal/comment_23_3d82a270dd4b0159f4aab5675166e1e3._comment b/doc/install/OSX/cabal/comment_23_3d82a270dd4b0159f4aab5675166e1e3._comment
deleted file mode 100644
index 08792aa..0000000
--- a/doc/install/OSX/cabal/comment_23_3d82a270dd4b0159f4aab5675166e1e3._comment
+++ /dev/null
@@ -1,30 +0,0 @@
-[[!comment format=mdwn
- username="https://www.google.com/accounts/o8/id?id=AItOawmL8pteP2jbYJUn1M3CbeLDvz2SWAA1wtg"
- nickname="Kristian"
- subject="Build failure using Haskel Platform"
- date="2013-09-15T18:49:01Z"
- content="""
-I get this error when I try to build git-annex using \"cabal install git-annex\"
-
-    [ 34 of 347] Compiling Utility.Misc     ( Utility/Misc.hs, dist/build/git-annex/git-annex-tmp/Utility/Misc.o )
-    [ 35 of 347] Compiling Utility.Process  ( Utility/Process.hs, dist/build/git-annex/git-annex-tmp/Utility/Process.o )
-    [ 36 of 347] Compiling Utility.Network  ( Utility/Network.hs, dist/build/git-annex/git-annex-tmp/Utility/Network.o )
-    [ 37 of 347] Compiling Utility.SRV      ( Utility/SRV.hs, dist/build/git-annex/git-annex-tmp/Utility/SRV.o )
-    
-    Utility/SRV.hs:70:54:
-        Couldn't match expected type `Maybe
-                                        [(Int, Int, Integer, B8.ByteString)]'
-                    with actual type `Either
-                                        dns-1.0.0:Network.DNS.Internal.DNSError
-                                        [(Int, Int, Int, dns-1.0.0:Network.DNS.Internal.Domain)]'
-        In the third argument of `maybe', namely `r'
-        In the second argument of `($)', namely
-          `maybe [] (orderHosts . map tohosts) r'
-        In a stmt of a 'do' block:
-          return $ maybe [] (orderHosts . map tohosts) r
-    Failed to install git-annex-4.20130909
-    cabal: Error: some packages failed to install:
-    git-annex-4.20130909 failed during the building phase. The exception was:
-    ExitFailure 1

(Diff truncated)
move cabal on OSX stuff to its own page
diff --git a/doc/install/OSX.mdwn b/doc/install/OSX.mdwn
index edfeff6..775771e 100644
--- a/doc/install/OSX.mdwn
+++ b/doc/install/OSX.mdwn
@@ -32,4 +32,8 @@ git-annex is now [[available in Homebrew|Homebrew]]!
 ## using MacPorts
 
 git-annex is not available in MacPorts, but can be built from source using
-MacPorts tools. See [[MacPorts]]
+MacPorts tools. See [[MacPorts]].
+
+## building it yourself
+
+See [[cabal]].
diff --git a/doc/install/OSX/cabal.mdwn b/doc/install/OSX/cabal.mdwn
new file mode 100644
index 0000000..b3629c6
--- /dev/null
+++ b/doc/install/OSX/cabal.mdwn
@@ -0,0 +1,6 @@
+If you cannot get a OSX build of git-annex suitable for your computer,
+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]].
diff --git a/doc/install/OSX/cabal/comment_11_740fa80e2e54e6fb570f820ff1f56440._comment b/doc/install/OSX/cabal/comment_11_740fa80e2e54e6fb570f820ff1f56440._comment
new file mode 100644
index 0000000..d0c74d6
--- /dev/null
+++ b/doc/install/OSX/cabal/comment_11_740fa80e2e54e6fb570f820ff1f56440._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmyFvkaewo432ELwtCoecUGou4v3jCP0Pc"
+ nickname="Eric"
+ subject="Updating to latest build"
+ date="2013-01-25T06:05:35Z"
+ content="""
+What is the appropriate way to update to the latest build of git-annex using cabal?
+"""]]
diff --git a/doc/install/OSX/cabal/comment_13_d6f1db401858ffea23c123db49f5b296._comment b/doc/install/OSX/cabal/comment_13_d6f1db401858ffea23c123db49f5b296._comment
new file mode 100644
index 0000000..875db34
--- /dev/null
+++ b/doc/install/OSX/cabal/comment_13_d6f1db401858ffea23c123db49f5b296._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.3.125"
+ subject="comment 13"
+ date="2013-02-05T19:46:29Z"
+ content="""
+@eric `cabal update && cabal upgrade git-annex`
+"""]]
diff --git a/doc/install/OSX/cabal/comment_14_035f856923276b0edad879e196e94097._comment b/doc/install/OSX/cabal/comment_14_035f856923276b0edad879e196e94097._comment
new file mode 100644
index 0000000..1072dbc
--- /dev/null
+++ b/doc/install/OSX/cabal/comment_14_035f856923276b0edad879e196e94097._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmCmNS-oUgYfNg85-LPuxzTZJUp0sIgprM"
+ nickname="Jonas"
+ subject="more homebrew"
+ date="2013-02-16T19:46:47Z"
+ content="""
+i had macports installed. then i installed brew, instaled haskell via brew. i needed to set 
+    PATH=$HOME/bin:/usr/local/bin:$PATH
+"""]]
diff --git a/doc/install/OSX/cabal/comment_15_336e0acb00e84943715e69917643a69e._comment b/doc/install/OSX/cabal/comment_15_336e0acb00e84943715e69917643a69e._comment
new file mode 100644
index 0000000..05f5654
--- /dev/null
+++ b/doc/install/OSX/cabal/comment_15_336e0acb00e84943715e69917643a69e._comment
@@ -0,0 +1,35 @@
+[[!comment format=mdwn
+ username="https://launchpad.net/~wincus"
+ nickname="Juan Moyano"
+ subject="git annex on Snow Leopard"
+ date="2013-03-26T16:02:54Z"
+ content="""
+I'm having the same issue as @Pere, with a newer version of DAV :(
+
+cabal: Error: some packages failed to install:
+DAV-0.3.1 failed during the building phase. The exception was:
+ExitFailure 11
+git-annex-4.20130323 depends on shakespeare-css-1.0.3 which failed to install.
+persistent-1.1.5.1 failed during the building phase. The exception was:
+ExitFailure 11
+persistent-template-1.1.3.1 depends on persistent-1.1.5.1 which failed to
+install.
+shakespeare-css-1.0.3 failed during the building phase. The exception was:
+ExitFailure 11
+yesod-1.1.9.2 depends on shakespeare-css-1.0.3 which failed to install.
+yesod-auth-1.1.5.3 depends on shakespeare-css-1.0.3 which failed to install.
+yesod-core-1.1.8.2 depends on shakespeare-css-1.0.3 which failed to install.
+yesod-default-1.1.3.2 depends on shakespeare-css-1.0.3 which failed to
+install.
+yesod-form-1.2.1.3 depends on shakespeare-css-1.0.3 which failed to install.
+yesod-json-1.1.2.2 depends on shakespeare-css-1.0.3 which failed to install.
+yesod-persistent-1.1.0.1 depends on shakespeare-css-1.0.3 which failed to
+install.
+yesod-static-1.1.2.2 depends on shakespeare-css-1.0.3 which failed to install.
+
+
+
+*Any ideas?*
+
+
+"""]]
diff --git a/doc/install/OSX/cabal/comment_16_1befafa862b7d07b1f6e57c0182497cf._comment b/doc/install/OSX/cabal/comment_16_1befafa862b7d07b1f6e57c0182497cf._comment
new file mode 100644
index 0000000..0098e74
--- /dev/null
+++ b/doc/install/OSX/cabal/comment_16_1befafa862b7d07b1f6e57c0182497cf._comment
@@ -0,0 +1,36 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkurjhi0CRJvgm7QNaZDWS9hitBtavqIpc"
+ nickname="Bret"
+ subject="Snow Leopard Issues"
+ date="2013-04-14T20:17:17Z"
+ content="""
+I was able to build snow leopard completely for the first time over last night (it took a very long time to build all the tools and dependancies).  Woohoo!
+
+The way I was able to fully build on a 32-bit 10.6 machine was this
+
+1. Delete ~/.ghc and ~/.cabal.  They were full of random things and were causing problems.
+2. `brew uninstall ghc and haskell-platform`
+3. `brew update`
+4. `brew install git ossp-uuid md5sha1sum coreutils libgsasl gnutls libidn libgsasl pkg-config libxml2`
+5. `brew upgrade git ossp-uuid md5sha1sum coreutils libgsasl gnutls libidn libgsasl pkg-config libxml2` (Some of these were already installed/up to date.
+6. `brew link libxml2`
+7. `brew install haskell-platform`  (This takes a long, long time).
+8. `cabal update` (assuming you have added `~/.cabal/bin` to your path
+9. `cabal install cablal-install`
+10. `cabal install c2hs`
+11. `cabal install git-annex`
+
+
+It also appears to be running fairly smoothly than it had in the past on a 32-bit SL system.  Thats also neat.  
+
+The problem is that it seems to not really work as git annex though, probably due to the error relating you get when you start up the webapp:
+Running
+`git annex webapp` 
+The browser starts up, and I get 3 of these errors:
+`Watcher crashed: Need at least OSX 10.7.0 for file-level FSEvents`
+
+Pairing with a local computer appears to work to systems running 10.7, but when you complete the process, they never show up in the repository list.
+
+
+Also on a side note, when running `git annex webapp` it triggers the opening of an html file in whatever the default html file handler is.  I edit a lot of html, so for me that is usually a text editor.  I had to change the file handler to open html files with my web browser for the `git annex webapp` to actually work.  Is there a way to change that so that `git annex webapp` uses the default web browser for the system rather than the default html file handler?
+"""]]
diff --git a/doc/install/OSX/cabal/comment_22_6b5f44a98f9d37a1c6ecfe19a60fe6c5._comment b/doc/install/OSX/cabal/comment_22_6b5f44a98f9d37a1c6ecfe19a60fe6c5._comment
new file mode 100644
index 0000000..7dfa481
--- /dev/null
+++ b/doc/install/OSX/cabal/comment_22_6b5f44a98f9d37a1c6ecfe19a60fe6c5._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmRFKwny4rArBaz-36xTcsJYqKIgdDaw5Q"
+ nickname="Andrew"
+ subject="comment 22"
+ date="2013-07-25T02:19:53Z"
+ content="""
+Rather than specifying --bindir on the command line for cabal, I edited my ~/.cabal/config to add this line:
+
+    symlink-bindir: /usr/local/bin
+
+This installs the binaries to ~/.cabal/bin but symlinks them into /usr/local/bin alongside the links that homebrew installs. Additionally, I symlinked /usr/local/bin/git-annex-shell to /usr/local/bin/git-annex which made things work great from remote hosts via ssh.
+"""]]
diff --git a/doc/install/OSX/cabal/comment_23_3d82a270dd4b0159f4aab5675166e1e3._comment b/doc/install/OSX/cabal/comment_23_3d82a270dd4b0159f4aab5675166e1e3._comment
new file mode 100644
index 0000000..08792aa
--- /dev/null
+++ b/doc/install/OSX/cabal/comment_23_3d82a270dd4b0159f4aab5675166e1e3._comment
@@ -0,0 +1,30 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmL8pteP2jbYJUn1M3CbeLDvz2SWAA1wtg"
+ nickname="Kristian"
+ subject="Build failure using Haskel Platform"
+ date="2013-09-15T18:49:01Z"
+ content="""
+I get this error when I try to build git-annex using \"cabal install git-annex\"
+
+    [ 34 of 347] Compiling Utility.Misc     ( Utility/Misc.hs, dist/build/git-annex/git-annex-tmp/Utility/Misc.o )
+    [ 35 of 347] Compiling Utility.Process  ( Utility/Process.hs, dist/build/git-annex/git-annex-tmp/Utility/Process.o )
+    [ 36 of 347] Compiling Utility.Network  ( Utility/Network.hs, dist/build/git-annex/git-annex-tmp/Utility/Network.o )
+    [ 37 of 347] Compiling Utility.SRV      ( Utility/SRV.hs, dist/build/git-annex/git-annex-tmp/Utility/SRV.o )
+    
+    Utility/SRV.hs:70:54:
+        Couldn't match expected type `Maybe
+                                        [(Int, Int, Integer, B8.ByteString)]'
+                    with actual type `Either
+                                        dns-1.0.0:Network.DNS.Internal.DNSError
+                                        [(Int, Int, Int, dns-1.0.0:Network.DNS.Internal.Domain)]'
+        In the third argument of `maybe', namely `r'
+        In the second argument of `($)', namely
+          `maybe [] (orderHosts . map tohosts) r'
+        In a stmt of a 'do' block:
+          return $ maybe [] (orderHosts . map tohosts) r

(Diff truncated)
reorg, moving MacPorts to a separate page
diff --git a/doc/install/Homebrew.mdwn b/doc/install/Homebrew.mdwn
deleted file mode 100644
index bd9a840..0000000
--- a/doc/install/Homebrew.mdwn
+++ /dev/null
@@ -1,21 +0,0 @@
-[Homebrew](http://brew.sh/) has [a formula](https://github.com/Homebrew/homebrew/commits/master/Library/Formula/git-annex.rb) for git-annex.
-
-Homebrew users can simply run `brew install git-annex` to install git-annex.
-
-## buiding git-annex from sources
-
-This is the old recipe for building git-annex from source, using
-packages from homebrew. Useful if you want a newer version than the version
-in homebrew.
-
-<pre>
-brew install haskell-platform git ossp-uuid md5sha1sum coreutils gnutls libidn gsasl pkg-config libxml2
-brew link libxml2 --force
-cabal update
-mkdir $HOME/bin
-PATH=$HOME/bin:$PATH
-PATH=$HOME/.cabal/bin:$PATH
-cabal install c2hs --bindir=$HOME/bin
-cabal install gnuidn
-cabal install git-annex --bindir=$HOME/bin
-</pre>
diff --git a/doc/install/OSX.mdwn b/doc/install/OSX.mdwn
index 5a1505c..edfeff6 100644
--- a/doc/install/OSX.mdwn
+++ b/doc/install/OSX.mdwn
@@ -31,25 +31,5 @@ git-annex is now [[available in Homebrew|Homebrew]]!
 
 ## using MacPorts
 
-Install the Haskell Platform from [[http://hackage.haskell.org/platform/mac.html]].
-The version provided by Macports is too old to work with current versions of git-annex.
-Then execute
-
-<pre>
-sudo port install git-core ossp-uuid md5sha1sum coreutils gnutls libxml2 libgsasl pkgconfig
-sudo cabal update
-PATH=$HOME/bin:$PATH
-cabal install c2hs git-annex --bindir=$HOME/bin
-</pre>
-
-## PATH setup
-
-Do not forget to add to your PATH variable your ~/bin folder. In your .bashrc, for example:
-<pre>
-PATH=$HOME/bin:$PATH
-</pre>
-
-See also:
-
-* [[forum/OSX__39__s_haskell-platform_statically_links_things]]
-* [[forum/OSX__39__s_default_sshd_behaviour_has_limited_paths_set]]
+git-annex is not available in MacPorts, but can be built from source using
+MacPorts tools. See [[MacPorts]]
diff --git a/doc/install/OSX/Homebrew.mdwn b/doc/install/OSX/Homebrew.mdwn
new file mode 100644
index 0000000..bd9a840
--- /dev/null
+++ b/doc/install/OSX/Homebrew.mdwn
@@ -0,0 +1,21 @@
+[Homebrew](http://brew.sh/) has [a formula](https://github.com/Homebrew/homebrew/commits/master/Library/Formula/git-annex.rb) for git-annex.
+
+Homebrew users can simply run `brew install git-annex` to install git-annex.
+
+## buiding git-annex from sources
+
+This is the old recipe for building git-annex from source, using
+packages from homebrew. Useful if you want a newer version than the version
+in homebrew.
+
+<pre>
+brew install haskell-platform git ossp-uuid md5sha1sum coreutils gnutls libidn gsasl pkg-config libxml2
+brew link libxml2 --force
+cabal update
+mkdir $HOME/bin
+PATH=$HOME/bin:$PATH
+PATH=$HOME/.cabal/bin:$PATH
+cabal install c2hs --bindir=$HOME/bin
+cabal install gnuidn
+cabal install git-annex --bindir=$HOME/bin
+</pre>
diff --git a/doc/install/OSX/MacPorts.mdwn b/doc/install/OSX/MacPorts.mdwn
new file mode 100644
index 0000000..379e42d
--- /dev/null
+++ b/doc/install/OSX/MacPorts.mdwn
@@ -0,0 +1,27 @@
+This is not a recommended way to install git-annex. Use [[HomeBrew]] or the
+prebuilt app bundle instead.
+
+But if you really want to use MacPorts:
+
+Install the Haskell Platform from [[http://hackage.haskell.org/platform/mac.html]].
+The version provided by Macports is too old to work with current versions of git-annex.
+Then execute
+
+<pre>
+sudo port install git-core ossp-uuid md5sha1sum coreutils gnutls libxml2 libgsasl pkgconfig
+sudo cabal update
+PATH=$HOME/bin:$PATH
+cabal install c2hs git-annex --bindir=$HOME/bin
+</pre>
+
+## PATH setup
+
+Do not forget to add to your PATH variable your ~/bin folder. In your .bashrc, for example:
+<pre>
+PATH=$HOME/bin:$PATH
+</pre>
+
+See also:
+
+* [[forum/OSX__39__s_haskell-platform_statically_links_things]]
+* [[forum/OSX__39__s_default_sshd_behaviour_has_limited_paths_set]]
diff --git a/doc/install/OSX/MacPorts/comment_21_987f1302f56107c926b6daf83e124654._comment b/doc/install/OSX/MacPorts/comment_21_987f1302f56107c926b6daf83e124654._comment
new file mode 100644
index 0000000..e7d42b5
--- /dev/null
+++ b/doc/install/OSX/MacPorts/comment_21_987f1302f56107c926b6daf83e124654._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmJdzisfT6DhorwRz0kKJ_9-zQbccCopu4"
+ nickname="Alejandro"
+ subject="Macports _iconv"
+ date="2013-07-18T14:23:02Z"
+ content="""
+If you get an error like `undefined symbol _iconv for x86_64`, you're most likely using libiconv installed by macports. You can fix this by running
+
+    cabal install c2hs git-annex --bindir=$HOME/bin --extra-lib-dirs=/usr/lib
+
+"""]]
diff --git a/doc/install/OSX/MacPorts/comment_3_47a77a03040fe628109bd54f82f9ad7a._comment b/doc/install/OSX/MacPorts/comment_3_47a77a03040fe628109bd54f82f9ad7a._comment
new file mode 100644
index 0000000..69f3f0f
--- /dev/null
+++ b/doc/install/OSX/MacPorts/comment_3_47a77a03040fe628109bd54f82f9ad7a._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlDDW-g2WLLsLpcnCm4LykAquFY_nwbIrU"
+ nickname="Daniel"
+ subject="comment 3"
+ date="2013-01-15T15:22:43Z"
+ content="""
+Installing via the MacPorts method. I ran into this error.
+
+    \"_locale_charset\", referenced from: _localeEncoding in libHSbase-4.5.1.0.a(PrelIOUtils.o) 
+    ld: symbol(s) not found for architecture x86_64
+
+I was able to solve and get git-annex to build buy providing the --extra-lib-dirs parameter
+
+    cabal install c2hs git-annex --bindir=$HOME/bin --extra-lib-dirs=/usr/lib
+
+Cheers, [Daniel Wozniak](http://woz.io)
+"""]]
diff --git a/doc/install/OSX/comment_21_987f1302f56107c926b6daf83e124654._comment b/doc/install/OSX/comment_21_987f1302f56107c926b6daf83e124654._comment
deleted file mode 100644
index e7d42b5..0000000
--- a/doc/install/OSX/comment_21_987f1302f56107c926b6daf83e124654._comment
+++ /dev/null
@@ -1,11 +0,0 @@
-[[!comment format=mdwn
- username="https://www.google.com/accounts/o8/id?id=AItOawmJdzisfT6DhorwRz0kKJ_9-zQbccCopu4"
- nickname="Alejandro"
- subject="Macports _iconv"
- date="2013-07-18T14:23:02Z"
- content="""
-If you get an error like `undefined symbol _iconv for x86_64`, you're most likely using libiconv installed by macports. You can fix this by running
-
-    cabal install c2hs git-annex --bindir=$HOME/bin --extra-lib-dirs=/usr/lib
-
-"""]]
diff --git a/doc/install/OSX/comment_3_47a77a03040fe628109bd54f82f9ad7a._comment b/doc/install/OSX/comment_3_47a77a03040fe628109bd54f82f9ad7a._comment
deleted file mode 100644
index 69f3f0f..0000000
--- a/doc/install/OSX/comment_3_47a77a03040fe628109bd54f82f9ad7a._comment
+++ /dev/null
@@ -1,17 +0,0 @@
-[[!comment format=mdwn
- username="https://www.google.com/accounts/o8/id?id=AItOawlDDW-g2WLLsLpcnCm4LykAquFY_nwbIrU"
- nickname="Daniel"
- subject="comment 3"
- date="2013-01-15T15:22:43Z"
- content="""
-Installing via the MacPorts method. I ran into this error.
-
-    \"_locale_charset\", referenced from: _localeEncoding in libHSbase-4.5.1.0.a(PrelIOUtils.o) 
-    ld: symbol(s) not found for architecture x86_64
-
-I was able to solve and get git-annex to build buy providing the --extra-lib-dirs parameter
-
-    cabal install c2hs git-annex --bindir=$HOME/bin --extra-lib-dirs=/usr/lib
-
-Cheers, [Daniel Wozniak](http://woz.io)
-"""]]

close
diff --git a/doc/bugs/Truncated_file_transferred_via_S3.mdwn b/doc/bugs/Truncated_file_transferred_via_S3.mdwn
index 9261c8a..b489f60 100644
--- a/doc/bugs/Truncated_file_transferred_via_S3.mdwn
+++ b/doc/bugs/Truncated_file_transferred_via_S3.mdwn
@@ -612,3 +612,6 @@ BST] XMPPClient: NetMessager stored Pushing "e57" (ReceivePackDone ExitSuccess)
 
 # End of transcript or log.
 """]]
+
+> Pretty sure this must have been due to Char8 truncation. So,
+> [[fixed|done]].

git-annex-shell sendkey: Don't fail if a remote asks for a key to be sent that already has a transfer lock file indicating it's being sent to that remote. The remote may have moved between networks, or reconnected.
diff --git a/Annex/Transfer.hs b/Annex/Transfer.hs
index ebc8e8b..5e98a87 100644
--- a/Annex/Transfer.hs
+++ b/Annex/Transfer.hs
@@ -12,6 +12,7 @@ module Annex.Transfer (
 	upload,
 	download,
 	runTransfer,
+	alwaysRunTransfer,
 	noRetry,
 	forwardRetry,
 ) where
@@ -46,12 +47,23 @@ download u key f d a _witness = runTransfer (Transfer Download u key) f d a
  - no transfer information or lock file is used.
  -}
 runTransfer :: Transfer -> Maybe FilePath -> RetryDecider -> (MeterUpdate -> Annex Bool) -> Annex Bool
-runTransfer t file shouldretry a = do
+runTransfer = runTransfer' False
+
+{- Like runTransfer, but ignores any existing transfer lock file for the
+ - transfer, allowing re-running a transfer that is already in progress.
+ -
+ - Note that this may result in confusing progress meter display in the
+ - webapp, if multiple processes are writing to the transfer info file. -}
+alwaysRunTransfer :: Transfer -> Maybe FilePath -> RetryDecider -> (MeterUpdate -> Annex Bool) -> Annex Bool
+alwaysRunTransfer = runTransfer' True
+
+runTransfer' :: Bool -> Transfer -> Maybe FilePath -> RetryDecider -> (MeterUpdate -> Annex Bool) -> Annex Bool
+runTransfer' ignorelock t file shouldretry a = do
 	info <- liftIO $ startTransferInfo file
 	(meter, tfile, metervar) <- mkProgressUpdater t info
 	mode <- annexFileMode
 	(fd, inprogress) <- liftIO $ prep tfile mode info
-	if inprogress
+	if inprogress && not ignorelock
 		then do
 			showNote "transfer already in progress"
 			return False
diff --git a/Command/SendKey.hs b/Command/SendKey.hs
index a201d1b..6b5127a 100644
--- a/Command/SendKey.hs
+++ b/Command/SendKey.hs
@@ -47,3 +47,11 @@ fieldTransfer direction key a = do
 		(\u -> runTransfer (Transfer direction (toUUID u) key) afile noRetry a)
 		=<< Fields.getField Fields.remoteUUID
 	liftIO $ exitBool ok
+  where
+	{- Allow the key to be sent to the remote even if there seems to be
+	 - another transfer of that key going on to that remote.
+	 - That one may be stale, etc.
+	 -}
+	runner
+		| direction == Upload = alwaysRunTransfer
+		| otherwise = runTransfer
diff --git a/debian/changelog b/debian/changelog
index eaa36b3..c55fbab 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -36,6 +36,9 @@ git-annex (5.20140718) UNRELEASED; urgency=medium
   * S3, Glacier, WebDAV: Fix bug that prevented accessing the creds
     when the repository was configured with encryption=shared embedcreds=yes.
   * direct: Avoid leaving file content in misctemp if interrupted.
+  * git-annex-shell sendkey: Don't fail if a remote asks for a key to be sent
+    that already has a transfer lock file indicating it's being sent to that
+    remote. The remote may have moved between networks, or reconnected.
 
  -- Joey Hess <joeyh@debian.org>  Mon, 21 Jul 2014 14:41:26 -0400
 
diff --git a/doc/bugs/protocol_mismatch_after_interrupt.mdwn b/doc/bugs/protocol_mismatch_after_interrupt.mdwn
index 837690e..c2c1590 100644
--- a/doc/bugs/protocol_mismatch_after_interrupt.mdwn
+++ b/doc/bugs/protocol_mismatch_after_interrupt.mdwn
@@ -29,3 +29,5 @@ git-annex: copy: 1 failed
 workaround: `cd .git/annex/; mv transfer transfer.old` on the other side.
 
 -- [[anarcat]]
+
+> [[fixed|done]] --[[Joey]]

Added a comment
diff --git a/doc/bugs/protocol_mismatch_after_interrupt/comment_3_3ff700a3daf515fceb715514a7cbd82a._comment b/doc/bugs/protocol_mismatch_after_interrupt/comment_3_3ff700a3daf515fceb715514a7cbd82a._comment
new file mode 100644
index 0000000..742109c
--- /dev/null
+++ b/doc/bugs/protocol_mismatch_after_interrupt/comment_3_3ff700a3daf515fceb715514a7cbd82a._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.7"
+ subject="comment 3"
+ date="2014-08-15T18:02:12Z"
+ content="""
+Right .. Normally it makes sense to prevent redundant transfers, but this is not the case when git-annex-shell sendkey is sending a file to a remote. Especially since the rsync protocol does not transport stderr output over the link to display to the user.
+
+Should be an easy fix.
+"""]]

Added a comment
diff --git a/doc/bugs/Permission_problem_in_second_user_account_on_Android/comment_1_4ac4f94354b6c5c4370f792689107ddc._comment b/doc/bugs/Permission_problem_in_second_user_account_on_Android/comment_1_4ac4f94354b6c5c4370f792689107ddc._comment
new file mode 100644
index 0000000..a4f5655
--- /dev/null
+++ b/doc/bugs/Permission_problem_in_second_user_account_on_Android/comment_1_4ac4f94354b6c5c4370f792689107ddc._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.7"
+ subject="comment 1"
+ date="2014-08-15T17:52:57Z"
+ content="""
+I'm afraid all I can do to help with this is to say that the git-annex Android app does not do anything I know of to prevent running the programs, such as git, that are included in it. If your user cannot access them, it must be your OS configuration preventing it.
+"""]]

Added a comment
diff --git a/doc/bugs/git_annex_repair_fails_-___47__tmp__47__tmprepo.1__47__.git__47__gc.pid:_removeLink:_does_not_exist___40__No_such_file_or_directory__41__/comment_1_183c3740a108b5f09baf1c401dcfa7f9._comment b/doc/bugs/git_annex_repair_fails_-___47__tmp__47__tmprepo.1__47__.git__47__gc.pid:_removeLink:_does_not_exist___40__No_such_file_or_directory__41__/comment_1_183c3740a108b5f09baf1c401dcfa7f9._comment
new file mode 100644
index 0000000..cc9f7a9
--- /dev/null
+++ b/doc/bugs/git_annex_repair_fails_-___47__tmp__47__tmprepo.1__47__.git__47__gc.pid:_removeLink:_does_not_exist___40__No_such_file_or_directory__41__/comment_1_183c3740a108b5f09baf1c401dcfa7f9._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.7"
+ subject="comment 1"
+ date="2014-08-15T17:46:15Z"
+ content="""
+It seems that this has something to do with an auto `git gc` run being trigged somehow during the repair. Puzzlingly, I cannot find any code that would delete the .git/gc.pid file, unless it somehow shows up as a branch ref or something like that.
+
+Can you run the command with --debug so we can see which particular git command triggered the git gc?
+"""]]

Added a comment
diff --git a/doc/bugs/direct_command_leaves_repository_inconsistent_if_interrupted/comment_2_2f3fb399f976d96aa66310f11365207c._comment b/doc/bugs/direct_command_leaves_repository_inconsistent_if_interrupted/comment_2_2f3fb399f976d96aa66310f11365207c._comment
new file mode 100644
index 0000000..b55e3c2
--- /dev/null
+++ b/doc/bugs/direct_command_leaves_repository_inconsistent_if_interrupted/comment_2_2f3fb399f976d96aa66310f11365207c._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.7"
+ subject="comment 2"
+ date="2014-08-15T17:39:14Z"
+ content="""
+I still cannot see a way that more than one file's content could end up in misctemp, since `git annex direct` moves just one file there at a time, so max of one should be there if interrupted. However, there was really no reason to be moving files through misctemp at all, so `git annex direct` now moves them into place completely atomically.
+
+Bug report retitled appropriatly for the `git annex lock --force` suprise.
+"""]]

direct: Avoid leaving file content in misctemp if interrupted.
diff --git a/Annex/Direct.hs b/Annex/Direct.hs
index 3745993..7b91cc3 100644
--- a/Annex/Direct.hs
+++ b/Annex/Direct.hs
@@ -353,11 +353,8 @@ toDirectGen k f = do
 		void $ addAssociatedFile k f
 		modifyContent loc $ do
 			thawContent loc
-			replaceFileOr f
-				(liftIO . moveFile loc)
-				$ \tmp -> do -- rollback
-					liftIO (moveFile tmp loc)
-					freezeContent loc
+			liftIO (replaceFileFrom loc f)
+				`catchIO` (\_ -> freezeContent loc)
 	fromdirect loc = do
 		replaceFile f $
 			liftIO . void . copyFileExternal loc
diff --git a/Annex/ReplaceFile.hs b/Annex/ReplaceFile.hs
index 8cb0cc6..9700d4b 100644
--- a/Annex/ReplaceFile.hs
+++ b/Annex/ReplaceFile.hs
@@ -39,7 +39,12 @@ replaceFileOr file action rollback = do
 		return tmpfile
 	go tmpfile = do
 		action tmpfile
-		liftIO $ catchIO (rename tmpfile file) (fallback tmpfile)
-	fallback tmpfile _ = do
-		createDirectoryIfMissing True $ parentDir file
-		moveFile tmpfile file
+		liftIO $ replaceFileFrom tmpfile file
+
+replaceFileFrom :: FilePath -> FilePath -> IO ()
+replaceFileFrom src dest = go `catchIO` fallback
+  where
+	go = moveFile src dest
+	fallback _ = do
+		createDirectoryIfMissing True $ parentDir dest
+		go
diff --git a/debian/changelog b/debian/changelog
index b1d53a8..eaa36b3 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -35,6 +35,7 @@ git-annex (5.20140718) UNRELEASED; urgency=medium
     subdirectory in the key name.
   * S3, Glacier, WebDAV: Fix bug that prevented accessing the creds
     when the repository was configured with encryption=shared embedcreds=yes.
+  * direct: Avoid leaving file content in misctemp if interrupted.
 
  -- Joey Hess <joeyh@debian.org>  Mon, 21 Jul 2014 14:41:26 -0400
 
diff --git a/doc/bugs/direct_command_leaves_repository_inconsistent_if_interrupted.mdwn b/doc/bugs/direct_command_leaves_repository_inconsistent_if_interrupted.mdwn
index 0d81c67..c19db97 100644
--- a/doc/bugs/direct_command_leaves_repository_inconsistent_if_interrupted.mdwn
+++ b/doc/bugs/direct_command_leaves_repository_inconsistent_if_interrupted.mdwn
@@ -41,3 +41,5 @@ Similar issues and discussions:
 * [[forum/Cleaning_up_after_aborted_sync_in_direct_mode/]]
 * [[bugs/failure_to_return_to_indirect_mode_on_usb/]]
 * [[forum/git-status_typechange_in_direct_mode/]]
+
+[[!meta title="git annex lock --force deletes only copy of content after interrupted switch to direct mode"]

Added a comment
diff --git a/doc/bugs/Possible_data-loss_if_WORM_keys_do_not_encode_relative_paths/comment_1_b37615636e685b60fab8ae1c4276d032._comment b/doc/bugs/Possible_data-loss_if_WORM_keys_do_not_encode_relative_paths/comment_1_b37615636e685b60fab8ae1c4276d032._comment
new file mode 100644
index 0000000..71164b0
--- /dev/null
+++ b/doc/bugs/Possible_data-loss_if_WORM_keys_do_not_encode_relative_paths/comment_1_b37615636e685b60fab8ae1c4276d032._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.7"
+ subject="comment 1"
+ date="2014-08-15T17:32:15Z"
+ content="""
+I don't see much difference between (mtime, size, location) and (mtime, size) as far as entropy goes. Consider: A repository with all files in a single directory in the top level is going to have identical probabilities of collision either way. A less special case of a repository that typically has files added to it in a particular directory (\"inbox\", say), is again going to have identical probabilities of collision.
+
+If you're worried about such collisions, you should not be using WORM. I think that the documentation for it is pretty clear.
+
+If we really wanted to increase the entropy of worm, we could add a random number to the key, or perhaps the file's (original) inode number.
+"""]]

use more generic architecture names
diff --git a/doc/install/Linux_standalone.mdwn b/doc/install/Linux_standalone.mdwn
index 4e654fe..f7aca5b 100644
--- a/doc/install/Linux_standalone.mdwn
+++ b/doc/install/Linux_standalone.mdwn
@@ -5,9 +5,9 @@ prebuilt tarball of the most recent release.
 This tarball should work on most Linux systems. It has basically no
 dependencies and is self-contained.
 
-* i386: [download tarball](https://downloads.kitenet.net/git-annex/linux/current/git-annex-standalone-i386.tar.gz)
-* amd64: [download tarball](https://downloads.kitenet.net/git-annex/linux/current/git-annex-standalone-amd64.tar.gz)
-* armel: [download tarball](https://downloads.kitenet.net/git-annex/linux/current/git-annex-standalone-armel.tar.gz)
+* x86-32: [download tarball](https://downloads.kitenet.net/git-annex/linux/current/git-annex-standalone-i386.tar.gz)
+* x86-64: [download tarball](https://downloads.kitenet.net/git-annex/linux/current/git-annex-standalone-amd64.tar.gz)
+* arm: [download tarball](https://downloads.kitenet.net/git-annex/linux/current/git-annex-standalone-armel.tar.gz)
 
 To use, just unpack the tarball, `cd git-annex.linux` and run `./runshell`
 -- this sets up an environment where you can use `git annex`, as well
@@ -18,7 +18,7 @@ Alternatively, you can unpack the tarball, and add the directory to your
 PATH. This lets you use `git annex`, without overriding your system's
 own versions of git, etc.
 
-The armel version can be installed on NAS devices and other embedded ARM
+The arm version can be installed on NAS devices and other embedded ARM
 linux systems.
 
 * [[tips/Synology_NAS_and_git_annex]]
@@ -29,6 +29,6 @@ linux systems.
 A daily build is also available, thanks to Mesar Hameed and the University
 of Bath CS department.
 
-* i386: [download tarball](https://downloads.kitenet.net/git-annex/autobuild/i386/git-annex-standalone-i386.tar.gz) ([build logs](https://downloads.kitenet.net/git-annex/autobuild/i386/))
-* amd64: [download tarball](https://downloads.kitenet.net/git-annex/autobuild/amd64/git-annex-standalone-amd64.tar.gz) ([build logs](https://downloads.kitenet.net/git-annex/autobuild/amd64/))
-* armel: [download tarball](https://downloads.kitenet.net/git-annex/autobuild/armel/git-annex-standalone-armel.tar.gz) ([build logs](https://downloads.kitenet.net/git-annex/autobuild/armel/))
+* x86-32: [download tarball](https://downloads.kitenet.net/git-annex/autobuild/i386/git-annex-standalone-i386.tar.gz) ([build logs](https://downloads.kitenet.net/git-annex/autobuild/i386/))
+* x86-64: [download tarball](https://downloads.kitenet.net/git-annex/autobuild/amd64/git-annex-standalone-amd64.tar.gz) ([build logs](https://downloads.kitenet.net/git-annex/autobuild/amd64/))
+* arm: [download tarball](https://downloads.kitenet.net/git-annex/autobuild/armel/git-annex-standalone-armel.tar.gz) ([build logs](https://downloads.kitenet.net/git-annex/autobuild/armel/))

Added a comment
diff --git a/doc/forum/gcrypt_os_x_app_vs_brew/comment_2_8df8ba1ccea0f68110593ed90a9cad6d._comment b/doc/forum/gcrypt_os_x_app_vs_brew/comment_2_8df8ba1ccea0f68110593ed90a9cad6d._comment
new file mode 100644
index 0000000..fcdfba4
--- /dev/null
+++ b/doc/forum/gcrypt_os_x_app_vs_brew/comment_2_8df8ba1ccea0f68110593ed90a9cad6d._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.7"
+ subject="comment 2"
+ date="2014-08-15T16:04:08Z"
+ content="""
+Note that you can avoid the trying of multiple keys by doing `git config gcrypt.publish-participants true` -- this is done by default by the assistant when setting up new gcrypt remotes. It needs my branch of git-remote-gcrypt, which is included in the osx app, I don't know which one is being used in brew.
+"""]]

clarify config option name
diff --git a/doc/special_remotes/gcrypt.mdwn b/doc/special_remotes/gcrypt.mdwn
index c9a22b0..d5f3f7b 100644
--- a/doc/special_remotes/gcrypt.mdwn
+++ b/doc/special_remotes/gcrypt.mdwn
@@ -46,7 +46,7 @@ force it to re-push everything again, so that the encrypted repository can
 be decrypted by the added keys. Probably this can be done by setting
 `GCRYPT_FULL_REPACK` and doing a forced push of branches.
 
-Recent versions of git-annex configure gcrypt-publish-participants when
+Recent versions of git-annex configure `remote.<name>`gcrypt-publish-participants` when
 setting up a gcrypt repository. This is done to avoid unncessary gpg
 passphrase prompts, but it does publish the gpg keyids that can decrypt the
 repository. Unset it if you need to obscure that.

s/space/newline/
diff --git a/doc/devblog/day_216__various_minor_bugs.mdwn b/doc/devblog/day_216__various_minor_bugs.mdwn
index 329b329..0531ddb 100644
--- a/doc/devblog/day_216__various_minor_bugs.mdwn
+++ b/doc/devblog/day_216__various_minor_bugs.mdwn
@@ -1,8 +1,8 @@
 Working on getting caught up with backlog. 73 messages remain.
 
 Several minor bugs were fixed today. All edge cases. The most edge case one
-of all, I could not fix: git-annex cannot add a file that has a space in its
-filename, because `git cat-file --batch`'s interface does not support such
+of all, I could not fix: git-annex cannot add a file that has a space^Wnewline
+in its filename, because `git cat-file --batch`'s interface does not support such
 filenames.
 
 Added a page [[documenting how verify the signatures of git-annex releases|install/verifying_downloads]].

Added a comment
diff --git a/doc/forum/armhf_binary/comment_1_9ca7ff6cb1f5dfc1e5ce8527e7e0a45f._comment b/doc/forum/armhf_binary/comment_1_9ca7ff6cb1f5dfc1e5ce8527e7e0a45f._comment
new file mode 100644
index 0000000..9a1e3a4
--- /dev/null
+++ b/doc/forum/armhf_binary/comment_1_9ca7ff6cb1f5dfc1e5ce8527e7e0a45f._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.7"
+ subject="comment 1"
+ date="2014-08-15T15:58:02Z"
+ content="""
+The standalone armel build should work fine on armhf, assuming that the kernel supports EABI, which I'm pretty sure it does (or multiarch armel would not work).
+"""]]

Added a comment: Problem solved
diff --git a/doc/forum/gcrypt_os_x_app_vs_brew/comment_1_cce5e2c16720cc8e32a4a479f50ce6b3._comment b/doc/forum/gcrypt_os_x_app_vs_brew/comment_1_cce5e2c16720cc8e32a4a479f50ce6b3._comment
new file mode 100644
index 0000000..bcf0940
--- /dev/null
+++ b/doc/forum/gcrypt_os_x_app_vs_brew/comment_1_cce5e2c16720cc8e32a4a479f50ce6b3._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ganwell"
+ ip="178.174.3.221"
+ subject="Problem solved"
+ date="2014-08-14T23:53:05Z"
+ content="""
+It turns out gpgtools will save to wrong passphrase to the keychain without complaining. Thats why standard gpg worked and gpgtools didn't: There was a typo in the passphrase in the keychain.
+"""]]

removed
diff --git a/doc/forum/gcrypt_os_x_app_vs_brew/comment_1_b7e2cb5368b6eb5529300554f55259c6._comment b/doc/forum/gcrypt_os_x_app_vs_brew/comment_1_b7e2cb5368b6eb5529300554f55259c6._comment
deleted file mode 100644
index 8b031db..0000000
--- a/doc/forum/gcrypt_os_x_app_vs_brew/comment_1_b7e2cb5368b6eb5529300554f55259c6._comment
+++ /dev/null
@@ -1,8 +0,0 @@
-[[!comment format=mdwn
- username="Ganwell"
- ip="178.174.3.221"
- subject="Problem solved"
- date="2014-08-14T23:45:38Z"
- content="""
-It turns out gpgtools will save a wrong passphrase, so thats why standard gpg worked and gpgtools didn't.
-"""]]

Added a comment: Problem solved
diff --git a/doc/forum/gcrypt_os_x_app_vs_brew/comment_1_b7e2cb5368b6eb5529300554f55259c6._comment b/doc/forum/gcrypt_os_x_app_vs_brew/comment_1_b7e2cb5368b6eb5529300554f55259c6._comment
new file mode 100644
index 0000000..8b031db
--- /dev/null
+++ b/doc/forum/gcrypt_os_x_app_vs_brew/comment_1_b7e2cb5368b6eb5529300554f55259c6._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Ganwell"
+ ip="178.174.3.221"
+ subject="Problem solved"
+ date="2014-08-14T23:45:38Z"
+ content="""
+It turns out gpgtools will save a wrong passphrase, so thats why standard gpg worked and gpgtools didn't.
+"""]]

diff --git a/doc/forum/gcrypt_os_x_app_vs_brew.mdwn b/doc/forum/gcrypt_os_x_app_vs_brew.mdwn
index 83f3205..98a2d5f 100644
--- a/doc/forum/gcrypt_os_x_app_vs_brew.mdwn
+++ b/doc/forum/gcrypt_os_x_app_vs_brew.mdwn
@@ -14,3 +14,5 @@ In both cases (app/brew) it tries the same keys. The app version will use its ow
 I tried "echo i | gpg -e -R XX -R XX | gpg -d" with the same recipients as the repo. It works well. 
 
 Has anybody hints or ideas what to try next?
+
+Best, Jean-Louis

diff --git a/doc/forum/gcrypt_os_x_app_vs_brew.mdwn b/doc/forum/gcrypt_os_x_app_vs_brew.mdwn
new file mode 100644
index 0000000..83f3205
--- /dev/null
+++ b/doc/forum/gcrypt_os_x_app_vs_brew.mdwn
@@ -0,0 +1,16 @@
+Gcrypt remotes work when using the git-annex command bundled in the git-annex.app. But gcrypt doesn't work when git-annex is installed via home-brew (brew install git-annex).
+
+The initial push will work, any subsequent commands (push/pull) will fail with:
+
+    gpg: anonymous recipient; trying secret key...
+    gpg: anonymous recipient; trying secret key...
+    gpg: anonymous recipient; trying secret key...
+    gpg: anonymous recipient; trying secret key...
+    gpg: decryption failed: No secret key
+    gcrypt: Failed to decrypt manifest!
+
+In both cases (app/brew) it tries the same keys. The app version will use its own version of gpg, which will trigger password prompts. With the brew version gpgtools is used, so I won't get any prompts. (Keychain)
+
+I tried "echo i | gpg -e -R XX -R XX | gpg -d" with the same recipients as the repo. It works well. 
+
+Has anybody hints or ideas what to try next?

Added a comment: cannot connect via google apps domain
diff --git a/doc/bugs/can__39__t_connect_jabber_with_custom_google_apps_domain/comment_2_b639ad750a4635d95f6ad16a1aa39a3e._comment b/doc/bugs/can__39__t_connect_jabber_with_custom_google_apps_domain/comment_2_b639ad750a4635d95f6ad16a1aa39a3e._comment
new file mode 100644
index 0000000..a705f68
--- /dev/null
+++ b/doc/bugs/can__39__t_connect_jabber_with_custom_google_apps_domain/comment_2_b639ad750a4635d95f6ad16a1aa39a3e._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlU0H3uyacCnqWxjSI_chHBlHu8TDIkTt0"
+ nickname="Matt"
+ subject="cannot connect via google apps domain"
+ date="2014-08-14T15:55:07Z"
+ content="""
+Having the same issue with our domain: zebradog.com SRV records are correctly specified (as defined here: https://support.google.com/a/answer/34143?hl=en)
+"""]]

removed
diff --git a/doc/bugs/can__39__t_connect_jabber_with_custom_google_apps_domain/comment_2_c90cf34541e552540b76e40fffa06099._comment b/doc/bugs/can__39__t_connect_jabber_with_custom_google_apps_domain/comment_2_c90cf34541e552540b76e40fffa06099._comment
deleted file mode 100644
index c646e42..0000000
--- a/doc/bugs/can__39__t_connect_jabber_with_custom_google_apps_domain/comment_2_c90cf34541e552540b76e40fffa06099._comment
+++ /dev/null
@@ -1,8 +0,0 @@
-[[!comment format=mdwn
- username="https://www.google.com/accounts/o8/id?id=AItOawlU0H3uyacCnqWxjSI_chHBlHu8TDIkTt0"
- nickname="Matt"
- subject="same issue"
- date="2014-08-14T15:45:37Z"
- content="""
-Having the same issue with our domain: zebradog.com SRV records are correctly specified (as defined here: https://support.google.com/a/answer/34143?hl=en)
-"""]]

Added a comment: same issue
diff --git a/doc/bugs/can__39__t_connect_jabber_with_custom_google_apps_domain/comment_2_c90cf34541e552540b76e40fffa06099._comment b/doc/bugs/can__39__t_connect_jabber_with_custom_google_apps_domain/comment_2_c90cf34541e552540b76e40fffa06099._comment
new file mode 100644
index 0000000..c646e42
--- /dev/null
+++ b/doc/bugs/can__39__t_connect_jabber_with_custom_google_apps_domain/comment_2_c90cf34541e552540b76e40fffa06099._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlU0H3uyacCnqWxjSI_chHBlHu8TDIkTt0"
+ nickname="Matt"
+ subject="same issue"
+ date="2014-08-14T15:45:37Z"
+ content="""
+Having the same issue with our domain: zebradog.com SRV records are correctly specified (as defined here: https://support.google.com/a/answer/34143?hl=en)
+"""]]

diff --git a/doc/forum/armhf_binary.mdwn b/doc/forum/armhf_binary.mdwn
new file mode 100644
index 0000000..442fb12
--- /dev/null
+++ b/doc/forum/armhf_binary.mdwn
@@ -0,0 +1,3 @@
+Does a armhf binary tarball exist anywhere? I'm running Ubuntu trusty on a armhf platform (beagleboard), and the repository package is out of date. I might try to get the standalone armel binary working using multiarch, but that seems only slightly less painful than compiling from scratch.
+
+Or am I better off changing to a debian boot image, and be done with it?

Added a comment
diff --git a/doc/devblog/day_216__various_minor_bugs/comment_1_0d0a0e75b9446f8a1c4cc43f36569473._comment b/doc/devblog/day_216__various_minor_bugs/comment_1_0d0a0e75b9446f8a1c4cc43f36569473._comment
new file mode 100644
index 0000000..a1cc9c3
--- /dev/null
+++ b/doc/devblog/day_216__various_minor_bugs/comment_1_0d0a0e75b9446f8a1c4cc43f36569473._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="EskildHustvedt"
+ ip="80.202.103.55"
+ subject="comment 1"
+ date="2014-08-14T05:30:46Z"
+ content="""
+What exactly does «git-annex cannot add a file that has a space in its filename» mean? git-annex (/assistant) actually can't handle tracking any file that has a space in its filename?
+"""]]

windows is more or less beta, though with some known problems
diff --git a/doc/install.mdwn b/doc/install.mdwn
index f149b4f..0d8bb1d 100644
--- a/doc/install.mdwn
+++ b/doc/install.mdwn
@@ -16,7 +16,7 @@ detailed instructions             | quick install
 &nbsp;&nbsp;[[ScientificLinux5]]  |
 &nbsp;&nbsp;[[openSUSE]]          | 
 &nbsp;&nbsp;[[Docker]]            | 
-[[Windows]]                       | [download installer](http://downloads.kitenet.net/git-annex/windows/current/) **alpha**
+[[Windows]]                       | [download installer](http://downloads.kitenet.net/git-annex/windows/current/) **beta**
 """]]
 
 All the downloads above use https for security. For added security, see

forgot I signed the git-annex key
diff --git a/doc/install/verifying_downloads.mdwn b/doc/install/verifying_downloads.mdwn
index 87c80de..c3413d4 100644
--- a/doc/install/verifying_downloads.mdwn
+++ b/doc/install/verifying_downloads.mdwn
@@ -28,32 +28,4 @@ is the right key? The answer is the GPG web of trust.
 * Joey Hess generates these git-annex packages,
   and has a GPG key, [C910D9222512E3C Joey Hess <id@joeyh.name>](http://pgp.cs.uu.nl/stats/2512E3C7.html), which has
   been verified and signed by many people.
-* For policy reasons, Joey does not sign the git-annex distribution signing
-  key with his GPG key. However, he has generated a signed statement,
-  below, attesting to its valididy. You can import Joey's key into gpg,
-  and then run gpg copy and paste the message below into `gpg --verify`
-
-<pre>
------BEGIN PGP SIGNED MESSAGE-----
-Hash: SHA1
-
-As of 12 August 2014, the GPG key used to sign the git-annex builds
-that are distributed on downloads.kitenet.net is: 5EE1DBA789C809CB
------BEGIN PGP SIGNATURE-----
-Version: GnuPG v1
-
-iQIVAwUBU+p1dMkQ2SIlEuPHAQL0Sg//Uy/WY6tHZnI1nf5U5SrFOlOG21y4f8k1
-72ZiIfJVMUgckeyVBcC2DW56nNuqiZzCR1OmZcrrFeEQgcinFdlPrfRfAJnlYH5/
-PD4UlyoYpZa9uCvVLOI5oDKVJ1hm9zDtU7C7q3EqmTj7j+vg4k5xlLRwNr3FlXkJ
-F3SGyYryCOXfhKgSexFMI91CCV0+mDvt5SR1LWBFVXgSre3oBpcb3cPO1CsAzijQ
-FVdIAbuZC8NYK0+i8McaE8C7QUfJHbo9ibrE7VV90lFNoQb7YiBu2Yuq6+HdysAb
-c0M070LMOsNPJRkZpOu2yxX4nCFVLZhuWg+6kADqp8gYu33629+A0nYLcMzGXiYP
-RS8W4UbcqmvEbvvLYuMFF4UwcHMlMO/pGu14ITNMP6/Xd+rbiGs51rRLwDwCBq+7
-1pebaFpjGwunWzOW2MjummHtGQgNEAwXdob1b8EqxREhrULo1Kmr5uECebPL3iFi
-4W+A7yjs8Dci0dGI85pgIMgyqX2XSGy40VO+naDkAc4wPuy7NGcTTXJUTIfVTPsD
-gKrXx/GTxVQdIj9XrLbp8assE/HyM8H3H4KIMuCV8lBVxb5szWRkteU+d6CeLyYl
-FNc1OHnPRfhcwGbFr0fHQVMvgKMYDU2JxKBaIvZpsMHibftYhVyIX6uG98IXJ32w
-12l8WDf7RTU=
-=gqFI
------END PGP SIGNATURE-----
-</pre>
+* Joey's GPG key has signed the git-annex distribution signing key.

diff --git a/doc/bugs/Possible_data-loss_if_WORM_keys_do_not_encode_relative_paths.mdwn b/doc/bugs/Possible_data-loss_if_WORM_keys_do_not_encode_relative_paths.mdwn
new file mode 100644
index 0000000..2b3cf3f
--- /dev/null
+++ b/doc/bugs/Possible_data-loss_if_WORM_keys_do_not_encode_relative_paths.mdwn
@@ -0,0 +1,23 @@
+This is a follow-up to [this
+qbug](http://git-annex.branchable.com/bugs/WORM_keys_differ_depending_on_working_dir_during_add/).
+Thank you for your fix there! However, if I understood correctly, you
+indicated in your reply that the current fix completely removes the
+relative path component from WORM keys. I gave some thought to this
+and believe not having the relative path encoded inside WORM keys
+makes key collisions (and accordingly data-loss) a very dire problem,
+while they are not of practical concern if the relative path is
+encoded.
+
+When relative paths are encoded within the key, a collision can only
+occur when a file in the same directory is annexed twice within the
+resolution of the mtime component inside the key (i.e., one second).
+As such, unless one adds files automatically with a period of < 1s,
+one can very much be certain that no collisions come up.
+
+Without relative paths, however, one could never be certain that
+adding a file will not result in data-loss.
+
+Instead of just using the basename, WORM keys could be kept stable by
+using the relative path and anchoring it to the root of the
+repository.
+

Added a comment
diff --git a/doc/bugs/whereis_does_not_work_in_direct_mode/comment_4_f334a85d6dd6c4971f0609ae0831766a._comment b/doc/bugs/whereis_does_not_work_in_direct_mode/comment_4_f334a85d6dd6c4971f0609ae0831766a._comment
new file mode 100644
index 0000000..ffbbcc1
--- /dev/null
+++ b/doc/bugs/whereis_does_not_work_in_direct_mode/comment_4_f334a85d6dd6c4971f0609ae0831766a._comment
@@ -0,0 +1,23 @@
+[[!comment format=mdwn
+ username="http://svario.it/gioele"
+ nickname="gioele"
+ subject="comment 4"
+ date="2014-08-13T06:40:12Z"
+ content="""
+Talking about the three possible causes for this bug,
+
+> 1) pc1 has not pushed git-annex branch to origin (or pushed it after pc2 pulled)
+
+pc1 pushes using `git annex sync -c annex.alwayscommit=true origin`. This should be enough, isn't it?
+
+> 2) pc2 has not fetched git-annex branch from origin
+
+The pc2 repository is created with `git clone localhost:/tmp/annex/Docs.git`, so there branches should all be there. I tried adding a `git fetch --all` to the script but it makes no difference. This is the list of branches in pc2:
+
+    * master
+      remotes/origin/HEAD -> origin/master
+      remotes/origin/master
+      remotes/origin/synced/git-annex
+      remotes/origin/synced/master
+
+"""]]

Added a comment
diff --git a/doc/bugs/whereis_does_not_work_in_direct_mode/comment_3_44dd6e0c6e7a7abd6483a4367baa7f0f._comment b/doc/bugs/whereis_does_not_work_in_direct_mode/comment_3_44dd6e0c6e7a7abd6483a4367baa7f0f._comment
new file mode 100644
index 0000000..6fb3b80
--- /dev/null
+++ b/doc/bugs/whereis_does_not_work_in_direct_mode/comment_3_44dd6e0c6e7a7abd6483a4367baa7f0f._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://svario.it/gioele"
+ nickname="gioele"
+ subject="comment 3"
+ date="2014-08-13T06:36:52Z"
+ content="""
+This is strange: I can replicate the problem on three different Ubuntu machines (12.04.5 32 and 64 bit, 14.04 64 bit) using that script.
+
+I attached to the gist [the execution log in direct mode](https://gist.github.com/gioele/dde462df89edfe17c5e3#file-annex-direct-log) (where the bug is shown), the [log in indirect mode](https://gist.github.com/gioele/dde462df89edfe17c5e3#file-annex-indirect-log) (where the bug does not appear), and a [diff between the two](https://gist.github.com/gioele/dde462df89edfe17c5e3#file-log-diff). I hope this helps.
+"""]]

devblog
diff --git a/doc/devblog/day_216__various_minor_bugs.mdwn b/doc/devblog/day_216__various_minor_bugs.mdwn
new file mode 100644
index 0000000..329b329
--- /dev/null
+++ b/doc/devblog/day_216__various_minor_bugs.mdwn
@@ -0,0 +1,16 @@
+Working on getting caught up with backlog. 73 messages remain.
+
+Several minor bugs were fixed today. All edge cases. The most edge case one
+of all, I could not fix: git-annex cannot add a file that has a space in its
+filename, because `git cat-file --batch`'s interface does not support such
+filenames.
+
+Added a page [[documenting how verify the signatures of git-annex releases|install/verifying_downloads]].
+
+Over the past couple days, all the autobuilders have been updated to new
+dependencies needed by the recent work. Except for Windows, which needs to
+be updated to the new Haskell Platform first, so hopefully soon.
+
+Turns out that upgrading unix-compat means that inode(like) numbers are
+available even on Windows, which will make git-annex more robust there.
+Win win. ;)

link to correct key
diff --git a/doc/install/verifying_downloads.mdwn b/doc/install/verifying_downloads.mdwn
index 686aa83..87c80de 100644
--- a/doc/install/verifying_downloads.mdwn
+++ b/doc/install/verifying_downloads.mdwn
@@ -26,8 +26,8 @@ But, how do you know that the gpg-pubkey.asc you downloaded
 is the right key? The answer is the GPG web of trust. 
 
 * Joey Hess generates these git-annex packages,
-  and has a GPG key, [C910D9222512E3C Joey Hess <id@joeyh.name>](http://pgp.cs.uu.nl/stats/788A3F4C.html), which has
-  been verified and signed over a hundred people.
+  and has a GPG key, [C910D9222512E3C Joey Hess <id@joeyh.name>](http://pgp.cs.uu.nl/stats/2512E3C7.html), which has
+  been verified and signed by many people.
 * For policy reasons, Joey does not sign the git-annex distribution signing
   key with his GPG key. However, he has generated a signed statement,
   below, attesting to its valididy. You can import Joey's key into gpg,

typo
diff --git a/doc/install.mdwn b/doc/install.mdwn
index 877caf9..f149b4f 100644
--- a/doc/install.mdwn
+++ b/doc/install.mdwn
@@ -19,7 +19,7 @@ detailed instructions             | quick install
 [[Windows]]                       | [download installer](http://downloads.kitenet.net/git-annex/windows/current/) **alpha**
 """]]
 
-All the downloads above use http for security. For added security, see
+All the downloads above use https for security. For added security, see
 [[verifying_downloads]].
 
 ## Using cabal

special case edit page for web remote
The crash came from calling Git.repoLocation, but it made sense to fix this
higher up, because there is nothing to edit about the web, it just is what
it is.
diff --git a/Assistant/WebApp/Configurators/Edit.hs b/Assistant/WebApp/Configurators/Edit.hs
index c8113d1..9268038 100644
--- a/Assistant/WebApp/Configurators/Edit.hs
+++ b/Assistant/WebApp/Configurators/Edit.hs
@@ -42,6 +42,7 @@ import Utility.Gpg
 import Annex.UUID
 import Assistant.Ssh
 import Config
+import Logs.Web (webUUID)
 
 import qualified Data.Text as T
 import qualified Data.Map as M
@@ -191,26 +192,29 @@ postEditNewCloudRepositoryR :: UUID -> Handler Html
 postEditNewCloudRepositoryR uuid = connectionNeeded >> editForm True (RepoUUID uuid)
 
 editForm :: Bool -> RepoId -> Handler Html
-editForm new (RepoUUID uuid) = page "Edit repository" (Just Configuration) $ do
-	mremote <- liftAnnex $ Remote.remoteFromUUID uuid
-	when (mremote == Nothing) $
-		whenM ((/=) uuid <$> liftAnnex getUUID) $
-			error "unknown remote"
-	curr <- liftAnnex $ getRepoConfig uuid mremote
-	liftAnnex $ checkAssociatedDirectory curr mremote
-	((result, form), enctype) <- liftH $
-		runFormPostNoToken $ renderBootstrap3 bootstrapFormLayout $ editRepositoryAForm mremote curr
-	case result of
-		FormSuccess input -> liftH $ do
-			setRepoConfig uuid mremote curr input
-			liftAnnex $ checkAssociatedDirectory input mremote
-			redirect DashboardR
-		_ -> do
-			let istransfer = repoGroup curr == RepoGroupStandard TransferGroup
-			config <- liftAnnex $ M.lookup uuid <$> readRemoteLog
-			let repoInfo = getRepoInfo mremote config
-			let repoEncryption = getRepoEncryption mremote config
-			$(widgetFile "configurators/edit/repository")
+editForm new (RepoUUID uuid)
+	| uuid == webUUID = page "The web" (Just Configuration) $ do
+		$(widgetFile "configurators/edit/webrepository")
+	| otherwise = page "Edit repository" (Just Configuration) $ do
+		mremote <- liftAnnex $ Remote.remoteFromUUID uuid
+		when (mremote == Nothing) $
+			whenM ((/=) uuid <$> liftAnnex getUUID) $
+				error "unknown remote"
+		curr <- liftAnnex $ getRepoConfig uuid mremote
+		liftAnnex $ checkAssociatedDirectory curr mremote
+		((result, form), enctype) <- liftH $
+			runFormPostNoToken $ renderBootstrap3 bootstrapFormLayout $ editRepositoryAForm mremote curr
+		case result of
+			FormSuccess input -> liftH $ do
+				setRepoConfig uuid mremote curr input
+				liftAnnex $ checkAssociatedDirectory input mremote
+				redirect DashboardR
+			_ -> do
+				let istransfer = repoGroup curr == RepoGroupStandard TransferGroup
+				config <- liftAnnex $ M.lookup uuid <$> readRemoteLog
+				let repoInfo = getRepoInfo mremote config
+				let repoEncryption = getRepoEncryption mremote config
+				$(widgetFile "configurators/edit/repository")
 editForm _new r@(RepoName _) = page "Edit repository" (Just Configuration) $ do
 	mr <- liftAnnex (repoIdRemote r)
 	let repoInfo = getRepoInfo mr Nothing
diff --git a/doc/bugs/youtube_web_download_gives_Prelude.undefined_in_webapp.mdwn b/doc/bugs/youtube_web_download_gives_Prelude.undefined_in_webapp.mdwn
index 7112818..2b4a625 100644
--- a/doc/bugs/youtube_web_download_gives_Prelude.undefined_in_webapp.mdwn
+++ b/doc/bugs/youtube_web_download_gives_Prelude.undefined_in_webapp.mdwn
@@ -23,3 +23,5 @@ Not much in the logs, I see this:
 [2014-07-25 08:40:14 BST] TransferWatcher: transfer starting: Download UUID "00000000-0000-0000-0000-000000000001" Chase_Adam_at_Startup_School_NY_2014.mp4 Nothing
 
 """]]
+
+> [[fixed|done]] --[[Joey]]
diff --git a/templates/configurators/edit/webrepository.hamlet b/templates/configurators/edit/webrepository.hamlet
new file mode 100644
index 0000000..f7d1243
--- /dev/null
+++ b/templates/configurators/edit/webrepository.hamlet
@@ -0,0 +1,8 @@
+<div .col-sm-9>
+  <div .content-box>
+    <h2>
+      The world wide web
+    <p>
+      git-annex can download files from the web.
+    <p>
+      This is not a normal repository, and cannot be configured.

more complete gpg key verification process, including statement signed with my personal key
diff --git a/doc/install.mdwn b/doc/install.mdwn
index 493fdea..877caf9 100644
--- a/doc/install.mdwn
+++ b/doc/install.mdwn
@@ -19,11 +19,8 @@ detailed instructions             | quick install
 [[Windows]]                       | [download installer](http://downloads.kitenet.net/git-annex/windows/current/) **alpha**
 """]]
 
-The downloaded package's integrity can be verified by the public PGP key.  On Linux,
-
-	$ wget https://downloads.kitenet.net/git-annex/gpg-pubkey.asc
-	$ gpg --import gpg-pubey.asc
-	$ gpg --verify git-annex-standalone-*.tar.gz.sig
+All the downloads above use http for security. For added security, see
+[[verifying_downloads]].
 
 ## Using cabal
 
diff --git a/doc/install/verifying_downloads.mdwn b/doc/install/verifying_downloads.mdwn
new file mode 100644
index 0000000..686aa83
--- /dev/null
+++ b/doc/install/verifying_downloads.mdwn
@@ -0,0 +1,59 @@
+When you download a git-annex package from downloads.kitenet.net,
+as listed in [[install]], you should use a https connection. That provides
+some security, but here's some more.
+
+The downloaded package's integrity can be verified by checking that
+it was signed using the right GPG key, specifically the git-annex
+distribution signing key. To do this, you need to download the .sig
+file accompanying your package. Just append .sig to the url. 
+
+For example, on Linux:
+
+	$ wget http://downloads.kitenet.net/git-annex/linux/current/git-annex-standalone-amd64.tar.gz
+	$ wget http://downloads.kitenet.net/git-annex/linux/current/git-annex-standalone-amd64.tar.gz.sig
+
+You can then download the public key, and check that the package is signed
+with it.
+
+	$ wget https://downloads.kitenet.net/git-annex/gpg-pubkey.asc
+	$ gpg --import gpg-pubey.asc
+	$ gpg --verify git-annex-standalone-*.tar.gz.sig
+
+(The git-annex assistant can automatically upgrade git-annex, and when it
+does, it always checks the signature like that.)
+
+But, how do you know that the gpg-pubkey.asc you downloaded
+is the right key? The answer is the GPG web of trust. 
+
+* Joey Hess generates these git-annex packages,
+  and has a GPG key, [C910D9222512E3C Joey Hess <id@joeyh.name>](http://pgp.cs.uu.nl/stats/788A3F4C.html), which has
+  been verified and signed over a hundred people.
+* For policy reasons, Joey does not sign the git-annex distribution signing
+  key with his GPG key. However, he has generated a signed statement,
+  below, attesting to its valididy. You can import Joey's key into gpg,
+  and then run gpg copy and paste the message below into `gpg --verify`
+
+<pre>
+-----BEGIN PGP SIGNED MESSAGE-----
+Hash: SHA1
+
+As of 12 August 2014, the GPG key used to sign the git-annex builds
+that are distributed on downloads.kitenet.net is: 5EE1DBA789C809CB
+-----BEGIN PGP SIGNATURE-----
+Version: GnuPG v1
+
+iQIVAwUBU+p1dMkQ2SIlEuPHAQL0Sg//Uy/WY6tHZnI1nf5U5SrFOlOG21y4f8k1
+72ZiIfJVMUgckeyVBcC2DW56nNuqiZzCR1OmZcrrFeEQgcinFdlPrfRfAJnlYH5/
+PD4UlyoYpZa9uCvVLOI5oDKVJ1hm9zDtU7C7q3EqmTj7j+vg4k5xlLRwNr3FlXkJ
+F3SGyYryCOXfhKgSexFMI91CCV0+mDvt5SR1LWBFVXgSre3oBpcb3cPO1CsAzijQ
+FVdIAbuZC8NYK0+i8McaE8C7QUfJHbo9ibrE7VV90lFNoQb7YiBu2Yuq6+HdysAb
+c0M070LMOsNPJRkZpOu2yxX4nCFVLZhuWg+6kADqp8gYu33629+A0nYLcMzGXiYP
+RS8W4UbcqmvEbvvLYuMFF4UwcHMlMO/pGu14ITNMP6/Xd+rbiGs51rRLwDwCBq+7
+1pebaFpjGwunWzOW2MjummHtGQgNEAwXdob1b8EqxREhrULo1Kmr5uECebPL3iFi
+4W+A7yjs8Dci0dGI85pgIMgyqX2XSGy40VO+naDkAc4wPuy7NGcTTXJUTIfVTPsD
+gKrXx/GTxVQdIj9XrLbp8assE/HyM8H3H4KIMuCV8lBVxb5szWRkteU+d6CeLyYl
+FNc1OHnPRfhcwGbFr0fHQVMvgKMYDU2JxKBaIvZpsMHibftYhVyIX6uG98IXJ32w
+12l8WDf7RTU=
+=gqFI
+-----END PGP SIGNATURE-----
+</pre>

Added a comment
diff --git a/doc/forum/usability:_what_are_those_arrow_things__63__/comment_2_364ce8b369fd0ba7ddaec3127840ff39._comment b/doc/forum/usability:_what_are_those_arrow_things__63__/comment_2_364ce8b369fd0ba7ddaec3127840ff39._comment
new file mode 100644
index 0000000..32ecdf0
--- /dev/null
+++ b/doc/forum/usability:_what_are_those_arrow_things__63__/comment_2_364ce8b369fd0ba7ddaec3127840ff39._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="https://id.koumbit.net/anarcat"
+ ip="70.83.139.100"
+ subject="comment 2"
+ date="2014-08-12T19:56:58Z"
+ content="""
+the problem with this is that you end up having two copies of the same files (the direct and indirect repositories). also, the switch to direct mode exploded (because i screwed up, granted)....
+
+i have been thinking more and more than the webapp needs to have some sort of file manager as well, but that seems like a huge undertaking...
+
+a better file manager integration could certainly allow to improve this experience. for me the requirements would be:
+
+* \"clone this repo to\" - make a copy of this git annex repo to the specified target
+* \"annex-copy those files to\" - the above + a file-transfer-like dialog that would track the total file transfer (as opposed to \"begin/end\" of single files, see also [[todo/do_not_bug_me_about_intermediate_files/]])
+* probably some more stuff
+"""]]

Added a comment
diff --git a/doc/todo/Deduplicate_archive___40__i.e._zip__41___files/comment_1_619840f2337b018ff165565325cf1a61._comment b/doc/todo/Deduplicate_archive___40__i.e._zip__41___files/comment_1_619840f2337b018ff165565325cf1a61._comment
new file mode 100644
index 0000000..19548ed
--- /dev/null
+++ b/doc/todo/Deduplicate_archive___40__i.e._zip__41___files/comment_1_619840f2337b018ff165565325cf1a61._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.7"
+ subject="comment 1"
+ date="2014-08-12T19:51:38Z"
+ content="""
+All you need to do is unzip your zip file, and then `git annex add` or `git annex import` its contents. It will then automatically deduplicate.
+
+Due to the way compression works, two zip (or gz) files with identical contents but different checksums are unlikely to share many bytes in common. So git-annex cannot help with de-duplicating unless you unzip them.
+"""]]

close
diff --git a/doc/todo/Deduplicate_archive___40__i.e._zip__41___files.mdwn b/doc/todo/Deduplicate_archive___40__i.e._zip__41___files.mdwn
index 314c283..c551b08 100644
--- a/doc/todo/Deduplicate_archive___40__i.e._zip__41___files.mdwn
+++ b/doc/todo/Deduplicate_archive___40__i.e._zip__41___files.mdwn
@@ -5,3 +5,5 @@ In this scenario, an online service (Bandcamp), automatically creates the archiv
 Would it be possible for git-annex to be able to detect this scenario (in a manner similar to zipcmp) and redirect an add/import to the already existing copy?
 
 I've found this due to trying to decommission an old annex by `git annex import --clean-duplicates ~/annex_old/.git/annex/objects` and finding these files being left.
+
+[[done]] --[[Joey]]

Added a comment
diff --git a/doc/forum/usability:_what_are_those_arrow_things__63__/comment_1_bf34c169c725f9504e0f2114ba53be4b._comment b/doc/forum/usability:_what_are_those_arrow_things__63__/comment_1_bf34c169c725f9504e0f2114ba53be4b._comment
new file mode 100644
index 0000000..86099c0
--- /dev/null
+++ b/doc/forum/usability:_what_are_those_arrow_things__63__/comment_1_bf34c169c725f9504e0f2114ba53be4b._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.7"
+ subject="comment 1"
+ date="2014-08-12T19:49:35Z"
+ content="""
+If I wanted to share files with someone, I'd set them up with a direct mode repository and link it to my (probably indirect mode) repository.
+
+The question then becomes, how can this person decide which files to get if they don't want to or cannot get everything. I think that [[tips/File_manager_integration]] is a pretty good answer, although it does involve adding extensions to file managers. At least it involves adding something, rather than convincing a suprisingly large number of people that their ideas about symlinks are wrong. There are other possible answers, like building a file selection UI into the webapp..
+"""]]

move bug and close it
diff --git a/doc/bugs/shared_cipher_for_S3_attempting_to_decrypt_a_non-encrypted_file.mdwn b/doc/bugs/shared_cipher_for_S3_attempting_to_decrypt_a_non-encrypted_file.mdwn
new file mode 100644
index 0000000..16fa607
--- /dev/null
+++ b/doc/bugs/shared_cipher_for_S3_attempting_to_decrypt_a_non-encrypted_file.mdwn
@@ -0,0 +1,22 @@
+I am trying to S3 as a file store for git annex. I have set up the remote via the following command:
+
+    git annex initremote xxx-s3 type=S3 encryption=shared embedcreds=yes datacenter=EU bucket=xxx-git-annex fileprefix=test/
+
+The remote gets set up correctly and creates the directory I want, and adds a annex-uuid file.
+
+Now when I try to copy a file to the xxx-s3 remote, I get the following error:
+
+    $ git annex add ssl-success-and-failure-with-tl-logs.log 
+    add ssl-success-and-failure-with-tl-logs.log ok
+    (Recording state in git...)
+    $ git annex copy ssl-success-and-failure-with-tl-logs.log --to xxx-s3
+    copy ssl-success-and-failure-with-tl-logs.log (gpg) gpg: no valid OpenPGP data found.
+    gpg: decrypt_message failed: eof
+
+    git-annex: user error (gpg ["--batch","--no-tty","--use-agent","--quiet","--trust-model","always","--batch","--passphrase-fd","10","--decrypt"] exited 2)
+    failed
+    git-annex: copy: 1 failed
+
+Any ideas what might be wrong? Is shared cipher broken somehow?
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/bugs/shared_cipher_for_S3_attempting_to_decrypt_a_non-encrypted_file/comment_1_b42ff37be172ba841980c17ad6223e06._comment b/doc/bugs/shared_cipher_for_S3_attempting_to_decrypt_a_non-encrypted_file/comment_1_b42ff37be172ba841980c17ad6223e06._comment
new file mode 100644
index 0000000..1268d8c
--- /dev/null
+++ b/doc/bugs/shared_cipher_for_S3_attempting_to_decrypt_a_non-encrypted_file/comment_1_b42ff37be172ba841980c17ad6223e06._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmAINLSovhWM_4_KrbngOcxduIbBuKv8ZA"
+ nickname="Nuutti"
+ subject="comment 1"
+ date="2014-08-01T09:28:21Z"
+ content="""
+Sorry, this should probably be in bugs.
+"""]]
diff --git a/doc/bugs/shared_cipher_for_S3_attempting_to_decrypt_a_non-encrypted_file/comment_2_c0325903cdb8d24c72fd4e67e18fbdc8._comment b/doc/bugs/shared_cipher_for_S3_attempting_to_decrypt_a_non-encrypted_file/comment_2_c0325903cdb8d24c72fd4e67e18fbdc8._comment
new file mode 100644
index 0000000..57d5ee0
--- /dev/null
+++ b/doc/bugs/shared_cipher_for_S3_attempting_to_decrypt_a_non-encrypted_file/comment_2_c0325903cdb8d24c72fd4e67e18fbdc8._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.7"
+ subject="comment 2"
+ date="2014-08-12T19:37:56Z"
+ content="""
+This is not gpg trying to decrypt some file from the S3 remote. It is trying to decrypt the creds that embedcreds=yes caused to be stored in the git repo. 
+
+I was able to reproduce this using your command line, with the S3 env vars set while running initremote, and then unset for the copy, which causes git-annex to try to get the creds from the git repo, and decrypt them.
+
+However, since encryption=shared, the encryption key is stored in the git repo, so there is no point at all in encrypting the creds, also stored in the git repo with that key. So `initremote` doesn't. The creds are simply stored base-64 encoded.
+
+I have fixed this. I will now move this thread to bugs so I can close it.
+"""]]
diff --git a/doc/forum/shared_cipher_for_S3_attempting_to_decrypt_a_non-encrypted_file.mdwn b/doc/forum/shared_cipher_for_S3_attempting_to_decrypt_a_non-encrypted_file.mdwn
deleted file mode 100644
index bd172b5..0000000
--- a/doc/forum/shared_cipher_for_S3_attempting_to_decrypt_a_non-encrypted_file.mdwn
+++ /dev/null
@@ -1,20 +0,0 @@
-I am trying to S3 as a file store for git annex. I have set up the remote via the following command:
-
-    git annex initremote xxx-s3 type=S3 encryption=shared embedcreds=yes datacenter=EU bucket=xxx-git-annex fileprefix=test/
-
-The remote gets set up correctly and creates the directory I want, and adds a annex-uuid file.
-
-Now when I try to copy a file to the xxx-s3 remote, I get the following error:
-
-    $ git annex add ssl-success-and-failure-with-tl-logs.log 
-    add ssl-success-and-failure-with-tl-logs.log ok
-    (Recording state in git...)
-    $ git annex copy ssl-success-and-failure-with-tl-logs.log --to xxx-s3
-    copy ssl-success-and-failure-with-tl-logs.log (gpg) gpg: no valid OpenPGP data found.
-    gpg: decrypt_message failed: eof
-
-    git-annex: user error (gpg ["--batch","--no-tty","--use-agent","--quiet","--trust-model","always","--batch","--passphrase-fd","10","--decrypt"] exited 2)
-    failed
-    git-annex: copy: 1 failed
-
-Any ideas what might be wrong? Is shared cipher broken somehow?
diff --git a/doc/forum/shared_cipher_for_S3_attempting_to_decrypt_a_non-encrypted_file/comment_1_b42ff37be172ba841980c17ad6223e06._comment b/doc/forum/shared_cipher_for_S3_attempting_to_decrypt_a_non-encrypted_file/comment_1_b42ff37be172ba841980c17ad6223e06._comment
deleted file mode 100644
index 1268d8c..0000000
--- a/doc/forum/shared_cipher_for_S3_attempting_to_decrypt_a_non-encrypted_file/comment_1_b42ff37be172ba841980c17ad6223e06._comment
+++ /dev/null
@@ -1,8 +0,0 @@
-[[!comment format=mdwn
- username="https://www.google.com/accounts/o8/id?id=AItOawmAINLSovhWM_4_KrbngOcxduIbBuKv8ZA"
- nickname="Nuutti"
- subject="comment 1"
- date="2014-08-01T09:28:21Z"
- content="""
-Sorry, this should probably be in bugs.
-"""]]
diff --git a/doc/forum/shared_cipher_for_S3_attempting_to_decrypt_a_non-encrypted_file/comment_2_c0325903cdb8d24c72fd4e67e18fbdc8._comment b/doc/forum/shared_cipher_for_S3_attempting_to_decrypt_a_non-encrypted_file/comment_2_c0325903cdb8d24c72fd4e67e18fbdc8._comment
deleted file mode 100644
index 57d5ee0..0000000
--- a/doc/forum/shared_cipher_for_S3_attempting_to_decrypt_a_non-encrypted_file/comment_2_c0325903cdb8d24c72fd4e67e18fbdc8._comment
+++ /dev/null
@@ -1,14 +0,0 @@
-[[!comment format=mdwn
- username="http://joeyh.name/"
- ip="209.250.56.7"
- subject="comment 2"
- date="2014-08-12T19:37:56Z"
- content="""
-This is not gpg trying to decrypt some file from the S3 remote. It is trying to decrypt the creds that embedcreds=yes caused to be stored in the git repo. 
-
-I was able to reproduce this using your command line, with the S3 env vars set while running initremote, and then unset for the copy, which causes git-annex to try to get the creds from the git repo, and decrypt them.
-
-However, since encryption=shared, the encryption key is stored in the git repo, so there is no point at all in encrypting the creds, also stored in the git repo with that key. So `initremote` doesn't. The creds are simply stored base-64 encoded.
-
-I have fixed this. I will now move this thread to bugs so I can close it.
-"""]]

Added a comment
diff --git a/doc/forum/shared_cipher_for_S3_attempting_to_decrypt_a_non-encrypted_file/comment_2_c0325903cdb8d24c72fd4e67e18fbdc8._comment b/doc/forum/shared_cipher_for_S3_attempting_to_decrypt_a_non-encrypted_file/comment_2_c0325903cdb8d24c72fd4e67e18fbdc8._comment
new file mode 100644
index 0000000..57d5ee0
--- /dev/null
+++ b/doc/forum/shared_cipher_for_S3_attempting_to_decrypt_a_non-encrypted_file/comment_2_c0325903cdb8d24c72fd4e67e18fbdc8._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.7"
+ subject="comment 2"
+ date="2014-08-12T19:37:56Z"
+ content="""
+This is not gpg trying to decrypt some file from the S3 remote. It is trying to decrypt the creds that embedcreds=yes caused to be stored in the git repo. 
+
+I was able to reproduce this using your command line, with the S3 env vars set while running initremote, and then unset for the copy, which causes git-annex to try to get the creds from the git repo, and decrypt them.
+
+However, since encryption=shared, the encryption key is stored in the git repo, so there is no point at all in encrypting the creds, also stored in the git repo with that key. So `initremote` doesn't. The creds are simply stored base-64 encoded.
+
+I have fixed this. I will now move this thread to bugs so I can close it.
+"""]]

Added a comment
diff --git a/doc/todo/wishlist:_annex.largefiles_support_for_mimetypes/comment_3_b2774d265de303143523607053811d23._comment b/doc/todo/wishlist:_annex.largefiles_support_for_mimetypes/comment_3_b2774d265de303143523607053811d23._comment
new file mode 100644
index 0000000..b2bcd87
--- /dev/null
+++ b/doc/todo/wishlist:_annex.largefiles_support_for_mimetypes/comment_3_b2774d265de303143523607053811d23._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.7"
+ subject="comment 3"
+ date="2014-08-12T18:58:49Z"
+ content="""
+I think that to support this, the annex.largefiles preferred content expression would need to be supplimented with checks not available in the normal preferred content language. 
+
+In general, it's important that preferred content expressions be able to be evaluated without having the file content locally available, and it needs to be possible for a repository to evaluate the preferred content of a sibling repository and know if its sibling wants a file. These things would be defeated by any mime-based expressions. So such expressions should only be available in annex.largefiles and not in other preferred content expressions.
+
+Calling out to `file` or some other external program could work. Although speed can be important. If the assistant is seeing a file frequently change, it's not ideal for it to be repeatedly running `file` on it. There does not seem to be a pure haskell MIME type checking library available at present.
+"""]]

WORM backend: When adding a file in a subdirectory, avoid including the subdirectory in the key name.
diff --git a/Backend/WORM.hs b/Backend/WORM.hs
index c972602..6ba5139 100644
--- a/Backend/WORM.hs
+++ b/Backend/WORM.hs
@@ -36,7 +36,7 @@ backend = Backend
 keyValue :: KeySource -> Annex (Maybe Key)
 keyValue source = do
 	stat <- liftIO $ getFileStatus $ contentLocation source
-	n <- genKeyName $ keyFilename source
+	n <- genKeyName $ takeFileName $ keyFilename source
 	return $ Just $ stubKey
 		{ keyName = n
 		, keyBackendName = name backend
diff --git a/debian/changelog b/debian/changelog
index 48b6296..722e934 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -31,6 +31,8 @@ git-annex (5.20140718) UNRELEASED; urgency=medium
     repositories, for safer detection of eg, renaming of files with the same
     size and mtime.
   * direct: Fix ugly warning messages.
+  * WORM backend: When adding a file in a subdirectory, avoid including the
+    subdirectory in the key name.
 
  -- Joey Hess <joeyh@debian.org>  Mon, 21 Jul 2014 14:41:26 -0400
 
diff --git a/doc/bugs/WORM_keys_differ_depending_on_working_dir_during_add.mdwn b/doc/bugs/WORM_keys_differ_depending_on_working_dir_during_add.mdwn
index e412201..9787ad5 100644
--- a/doc/bugs/WORM_keys_differ_depending_on_working_dir_during_add.mdwn
+++ b/doc/bugs/WORM_keys_differ_depending_on_working_dir_during_add.mdwn
@@ -55,3 +55,14 @@ $ readlink quux
 Linux 3.15.8
 
 git-annex 5.20140716
+
+> This was a bug. I suspect it got broken a while ago and I didn't noticed
+> since I rarely use WORM and when I do it's almost always adding files
+> in the current directory. [[fixed|done]] to take the filename only.
+> 
+> I don't think it's a problem to have the subdirectory path in the
+> existing WORM keys, other than the problems you note with this meaning
+> a later add of the same file will generate a different key. So I have not
+> done anything to try to fix up existing keys. (If this became a problem,
+> I could add upgrade code to the WORM backend.)
+> --[[Joey]]

maybe better note for direct mode, although I dislike the walkthrough being complicated by direct mode at all
diff --git a/doc/walkthrough/renaming_files.mdwn b/doc/walkthrough/renaming_files.mdwn
index 7ae5f63..d18b7da 100644
--- a/doc/walkthrough/renaming_files.mdwn
+++ b/doc/walkthrough/renaming_files.mdwn
@@ -12,8 +12,7 @@ the symlink will break when the file is moved into a subdirectory.
 But, git-annex will fix this up for you when you commit --
 it has a pre-commit hook that watches for and corrects broken symlinks.
 
-## Direct mode
-
-Note that these git commands only work when git-annex is using indirect mode. Repositories created by the [[assistant]] are in [[direct_mode]]. Running 'git mv' in direct mode will give you an error:
-
-    fatal: This operation must be run in a work tree
+(Note that if a repository is in direct mode, you can't run normal git
+commands in it. Instead, just move the files using non-git commands, and
+`git annex add` and `git annex sync`. This walkthrough does not make a
+direct mode repository.)

Added a comment
diff --git a/doc/bugs/git_annex_import_fails_on_filenames_with_newlines_in_them/comment_1_249b198e1141e05fe39f49bd7ad8870e._comment b/doc/bugs/git_annex_import_fails_on_filenames_with_newlines_in_them/comment_1_249b198e1141e05fe39f49bd7ad8870e._comment
new file mode 100644
index 0000000..c4d78fa
--- /dev/null
+++ b/doc/bugs/git_annex_import_fails_on_filenames_with_newlines_in_them/comment_1_249b198e1141e05fe39f49bd7ad8870e._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.7"
+ subject="comment 1"
+ date="2014-08-12T18:24:57Z"
+ content="""
+Congrats on being the guy with newlines in his filenames.. someone had to do it!
+
+Similarly, `git annex add` on the file will fail with the same error and leave it where it is and not added.
+
+The problem here is that while git-annex is careful to use git commands with -z, so it gets \"foo\nbar\" with a literal newline from git ls-files, `git cat-file --batch` speaks a line-based protocol. And, it parses filenames like `git ref-parse` does -- and AFAICS, that does not provide a way to input something like \"foo\\nbar\" with an escaped newline. Normally this doesn't matter, since the whole line of input is taken to be a filename, so there's no need to escape anything, but of course it fails with newlines.
+
+IMHO, the solution to this is to make `git cat-file --batch` have a -z option that enables NUL-delimited input (and probably output). If you want to see this happen, take it to the git developers..
+
+(Should git annex import put files back if it fails to add them rather than leaving them sitting in the work tree?)
+"""]]

confirmed; really a git bug
diff --git a/doc/bugs/git_annex_import_fails_on_filenames_with_newlines_in_them.mdwn b/doc/bugs/git_annex_import_fails_on_filenames_with_newlines_in_them.mdwn
index 8727d3d..d435f8c 100644
--- a/doc/bugs/git_annex_import_fails_on_filenames_with_newlines_in_them.mdwn
+++ b/doc/bugs/git_annex_import_fails_on_filenames_with_newlines_in_them.mdwn
@@ -42,3 +42,5 @@ foo
     git-annex version: 5.20140717
     git version 2.0.1
     Linux durian 3.14-1-amd64 #1 SMP Debian 3.14.9-1 (2014-06-30) x86_64 GNU/Linux
+
+[[!tag confirmed git-bug]]

Added a comment
diff --git a/doc/backends/comment_8_c40d2c2c929ad3239ee5d529e307c746._comment b/doc/backends/comment_8_c40d2c2c929ad3239ee5d529e307c746._comment
new file mode 100644
index 0000000..17ac4c2
--- /dev/null
+++ b/doc/backends/comment_8_c40d2c2c929ad3239ee5d529e307c746._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.7"
+ subject="comment 8"
+ date="2014-08-12T18:00:46Z"
+ content="""
+Ævar, you can use `git annex add --backend=SHA256` to temporarily override the backend.
+"""]]

Added a comment
diff --git a/doc/forum/__34__Lost__34___data__63___Maybe_a_bug__63__/comment_2_4d80b96e788d233706fa8f3e363d2f76._comment b/doc/forum/__34__Lost__34___data__63___Maybe_a_bug__63__/comment_2_4d80b96e788d233706fa8f3e363d2f76._comment
new file mode 100644
index 0000000..e9122c0
--- /dev/null
+++ b/doc/forum/__34__Lost__34___data__63___Maybe_a_bug__63__/comment_2_4d80b96e788d233706fa8f3e363d2f76._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.7"
+ subject="comment 2"
+ date="2014-08-12T17:57:26Z"
+ content="""
+views are a somewhat new feature that still needs work, and you will find this question of what to do about a file added while in a view in the todo list [[here|design/metadata]].
+
+Since views are just git branches, you can check out the view branch where you added the file, and it'll still be there. You could merge the branch (probably not a good idea since the filenames are moved around in the view). 
+
+Using `fromkey` will also work, if you have the right key and the content is present in the annex -- I just tested it. 
+"""]]

Added a comment
diff --git a/doc/forum/Somehow_have_lots_of_directories_in_root:_000...ffff/comment_4_8c817d08ca9d94a1228fb21cd0b15744._comment b/doc/forum/Somehow_have_lots_of_directories_in_root:_000...ffff/comment_4_8c817d08ca9d94a1228fb21cd0b15744._comment
new file mode 100644
index 0000000..74a3a2a
--- /dev/null
+++ b/doc/forum/Somehow_have_lots_of_directories_in_root:_000...ffff/comment_4_8c817d08ca9d94a1228fb21cd0b15744._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.7"
+ subject="comment 4"
+ date="2014-08-12T17:50:15Z"
+ content="""
+Sure, it's fine to delete the files. The same info will be committed to git either way.
+"""]]

Added a comment
diff --git a/doc/forum/Using_git-annex_as_a_library/comment_6_45d9520ebc13d1b4fd88c25abc61f1b4._comment b/doc/forum/Using_git-annex_as_a_library/comment_6_45d9520ebc13d1b4fd88c25abc61f1b4._comment
new file mode 100644
index 0000000..8591e79
--- /dev/null
+++ b/doc/forum/Using_git-annex_as_a_library/comment_6_45d9520ebc13d1b4fd88c25abc61f1b4._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.7"
+ subject="comment 6"
+ date="2014-08-12T17:48:34Z"
+ content="""
+There are a couple of problems with using the haskell code as a library that would need to be addressed:
+
+* I can't guarantee much about providing every interface in a compatible way going forward. It might make sense to pick out some key interfaces and make those stable, but I don't know what the right choices would be.
+* If all of git-annex is a library, `cabal build` will build everything a second time. This is annoying when trying to do a fast edit/build/test cycle, but I don't know a way to make cabal not do it. AFAIK cabal build flags cannot be used to disable building a library.
+"""]]

Added a comment
diff --git a/doc/bugs/googlemail/comment_2_bdb2b08346673f850709041d2f41be5c._comment b/doc/bugs/googlemail/comment_2_bdb2b08346673f850709041d2f41be5c._comment
new file mode 100644
index 0000000..1303a20
--- /dev/null
+++ b/doc/bugs/googlemail/comment_2_bdb2b08346673f850709041d2f41be5c._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.7"
+ subject="comment 2"
+ date="2014-08-12T17:39:09Z"
+ content="""
+AFAICS, xmpp.l.google.com is the correct XMPP server; it's what the SRV record for googlemail.com says to use.
+
+Since it fails with an authentication error, I wonder if google's XMPP is rejecting a user@googlemail.com jid and expects the domain to be @gmail.com or something else. Would that be allowed by the XMPP spec? I don't know.
+
+
+"""]]

Added a comment
diff --git a/doc/bugs/whereis_does_not_work_in_direct_mode/comment_2_d1005e29c32bddad109dd426d4dd8803._comment b/doc/bugs/whereis_does_not_work_in_direct_mode/comment_2_d1005e29c32bddad109dd426d4dd8803._comment
new file mode 100644
index 0000000..d139aed
--- /dev/null
+++ b/doc/bugs/whereis_does_not_work_in_direct_mode/comment_2_d1005e29c32bddad109dd426d4dd8803._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.7"
+ subject="comment 2"
+ date="2014-08-12T17:33:25Z"
+ content="""
+It seems to me that there are only 3 ways that pc2 could not know that pc1 has the file, in decreasing order of probability:
+
+1. pc1 has not pushed git-annex branch to origin (or pushed it after pc2 pulled)
+2. pc2 has not fetched git-annex branch from origin
+3. an actual bug, such as bad info being written to the git-annex branch or the git-annex branch merge failing
+
+So, if you have 3 repositories that exhibit a problem like this, those are the things to check.
+"""]]

Added a comment
diff --git a/doc/bugs/whereis_does_not_work_in_direct_mode/comment_1_f119d2b322a7b33c08b8187deba690c2._comment b/doc/bugs/whereis_does_not_work_in_direct_mode/comment_1_f119d2b322a7b33c08b8187deba690c2._comment
new file mode 100644
index 0000000..5775add
--- /dev/null
+++ b/doc/bugs/whereis_does_not_work_in_direct_mode/comment_1_f119d2b322a7b33c08b8187deba690c2._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.7"
+ subject="comment 1"
+ date="2014-08-12T17:29:16Z"
+ content="""
+I don't seem to reproduce this bug when I run the script provided.
+
+<pre>
+whereis fileA (1 copy) 
+  	c311d5b9-2f59-4153-a0e5-61707edd28ef -- pc1
+ok
+whereis fileB (1 copy) 
+  	c311d5b9-2f59-4153-a0e5-61707edd28ef -- pc1
+ok
+</pre>
+"""]]

Added a comment
diff --git a/doc/bugs/direct_command_leaves_repository_inconsistent_if_interrupted/comment_1_770e6ed8556fa6b259f517d5c398271f._comment b/doc/bugs/direct_command_leaves_repository_inconsistent_if_interrupted/comment_1_770e6ed8556fa6b259f517d5c398271f._comment
new file mode 100644
index 0000000..4d7246e
--- /dev/null
+++ b/doc/bugs/direct_command_leaves_repository_inconsistent_if_interrupted/comment_1_770e6ed8556fa6b259f517d5c398271f._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.7"
+ subject="comment 1"
+ date="2014-08-12T17:26:46Z"
+ content="""
+The way it's supposed to work is that `git annex direct` does not set the repository into direct mode until it's entirely done moving files around. So, if it is interrupted at any point, you are left with an indirect mode repository, with some unlocked files. Which can be put back to indirect by `git annex add`, or the conversion restarted with `git annex direct`.
+
+That seems to work in my tests; I can interrupt `git annex direct` and resume with `git annex direct` with a good result; `git annex add` reverts back to indirect mode. Even `git commit -a` reverts back to indirect mode, thanks to the pre-commit hook. I have tested that all these recovery methods work as intended.
+
+That leaves `git annex lock --force` (it has to be forced) after an interrupted switch to direct mode. I have reproduced that in this situation, that will delete your file's contents (I cannot reproduce them ending up in misctmp, but [[!commit d8be828734704c78f91029263b59eed75174e665]] may have had something to do with that). In a sense, `git annex lock --force` is doing what you told it to -- git-annex lock throws unlocked file contents away, under the assumption that they might contain modified changes. Since normally, `git annex unlock` makes a copy of the file, there is not normally data loss, unless the unlocked files got modified. But that's why it requires the --force; it can result in data loss.
+
+I a having a hard time thinking of a modification to `git annex lock` that would make sense. The best I can come up with is, if the file's content is not present in the annex, it could switch to what `git annex add` does, and re-add the file content to the annex if it's unchanged. While, I guess, throwing away the content if it is changed. That seems a bit complicated.
+
+(BTW, if you do still have the files in misctmp, you can `git annex import` their content back into the repository.)
+"""]]

Added a comment
diff --git a/doc/forum/Somehow_have_lots_of_directories_in_root:_000...ffff/comment_3_d534da276b79a40fdb7d8d158f6eae26._comment b/doc/forum/Somehow_have_lots_of_directories_in_root:_000...ffff/comment_3_d534da276b79a40fdb7d8d158f6eae26._comment
new file mode 100644
index 0000000..214444c
--- /dev/null
+++ b/doc/forum/Somehow_have_lots_of_directories_in_root:_000...ffff/comment_3_d534da276b79a40fdb7d8d158f6eae26._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://launchpad.net/~rorymcc"
+ nickname="rorymcc"
+ subject="comment 3"
+ date="2014-08-11T18:41:05Z"
+ content="""
+Would just standard \"git rm ./000/\" etc. in master be OK? Instead of hunting down and reverting all the commits? 
+"""]]

Added a comment
diff --git a/doc/forum/Somehow_have_lots_of_directories_in_root:_000...ffff/comment_2_f6d977a534264b4368401e1b13628931._comment b/doc/forum/Somehow_have_lots_of_directories_in_root:_000...ffff/comment_2_f6d977a534264b4368401e1b13628931._comment
new file mode 100644
index 0000000..e902380
--- /dev/null
+++ b/doc/forum/Somehow_have_lots_of_directories_in_root:_000...ffff/comment_2_f6d977a534264b4368401e1b13628931._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://launchpad.net/~rorymcc"
+ nickname="rorymcc"
+ subject="comment 2"
+ date="2014-08-11T18:37:46Z"
+ content="""
+Thanks for your reply. I think I might have done a \"git merge git-annex\" at some point (or many times), because I thought that was what you were supposed to do... :( PEBKAC I'll try to fix up my repository. Thanks.
+"""]]

Added a comment
diff --git a/doc/forum/__34__Lost__34___data__63___Maybe_a_bug__63__/comment_1_52e4453432184524d84d88f6382cac9d._comment b/doc/forum/__34__Lost__34___data__63___Maybe_a_bug__63__/comment_1_52e4453432184524d84d88f6382cac9d._comment
new file mode 100644
index 0000000..2ecde63
--- /dev/null
+++ b/doc/forum/__34__Lost__34___data__63___Maybe_a_bug__63__/comment_1_52e4453432184524d84d88f6382cac9d._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="sts"
+ ip="134.147.240.107"
+ subject="comment 1"
+ date="2014-08-11T11:39:44Z"
+ content="""
+OK, I could find the commit where I have added the data. I can 'git show' the commit and see the keys. I can also checkout the commit and I can see my data. Now I tried to create symlinks based on the keys I found in the commit, so whats the right way?
+
+    git annex examinekey SHA256E-s1390161393--1dcba6e914ad6a9133d374e3c55fbf9a58f036e64298262692c7f8e7cdb65852.mkv
+    SHA256E-s1390161393--1dcba6e914ad6a9133d374e3c55fbf9a58f036e64298262692c7f8e7cdb65852.mkv
+
+    git annex fromkey SHA256E-s1390161393--1dcba6e914ad6a9133d374e3c55fbf9a58f036e64298262692c7f8e7cdb65852.mkv e01.mkv
+    git-annex: key (SHA256E-s1390161393--1dcba6e914ad6a9133d374e3c55fbf9a58f036e64298262692c7f8e7cdb65852.mkv) is not present in backend
+
+I am not sure what to do now :-/.
+"""]]

diff --git a/doc/forum/__34__Lost__34___data__63___Maybe_a_bug__63__.mdwn b/doc/forum/__34__Lost__34___data__63___Maybe_a_bug__63__.mdwn
new file mode 100644
index 0000000..20f6d69
--- /dev/null
+++ b/doc/forum/__34__Lost__34___data__63___Maybe_a_bug__63__.mdwn
@@ -0,0 +1,14 @@
+Hey,
+
+I lost some symlinks to my data and I do not know how to recover them. I was in view mode  with some tag folders already there. I added _new_ files from outside annex into some folder and 'git annex add' those files.
+
+What I expected: Git-Annex should add those files to the annex, move the symlinks to the root of the annex (because there is no other way to tell where to put them) and tag them with the specific tag. That is the way I would like to work, first tag, then organize in folder structure.
+
+Now that seems not to be a scenario which has been respected? Because I don't see my files... anywhere. Not in master branch nor in the view branch (I already did 'git annex vpop'). If that is not supported and never will be git-annex should not accept data from the outside world if it is currently in view mode.
+
+Now, how do I get my symlinks back? I guess the content is still there, but the links are missing and I don't find any reference or history log to revert that. 'git annex unused' does not show them either.
+
+I hope somebody can help me :)
+
+Cheers,
+Stephan

i believe i provided moreinto in the comments now
diff --git a/doc/bugs/protocol_mismatch_after_interrupt.mdwn b/doc/bugs/protocol_mismatch_after_interrupt.mdwn
index 799ccc0..837690e 100644
--- a/doc/bugs/protocol_mismatch_after_interrupt.mdwn
+++ b/doc/bugs/protocol_mismatch_after_interrupt.mdwn
@@ -29,5 +29,3 @@ git-annex: copy: 1 failed
 workaround: `cd .git/annex/; mv transfer transfer.old` on the other side.
 
 -- [[anarcat]]
-
-[[!taglink moreinfo]]

Added a comment: more info
diff --git a/doc/bugs/protocol_mismatch_after_interrupt/comment_2_e0894bd0d0037ee40050697748d4be47._comment b/doc/bugs/protocol_mismatch_after_interrupt/comment_2_e0894bd0d0037ee40050697748d4be47._comment
new file mode 100644
index 0000000..5a1566b
--- /dev/null
+++ b/doc/bugs/protocol_mismatch_after_interrupt/comment_2_e0894bd0d0037ee40050697748d4be47._comment
@@ -0,0 +1,47 @@
+[[!comment format=mdwn
+ username="https://id.koumbit.net/anarcat"
+ ip="72.0.72.144"
+ subject="more info"
+ date="2014-08-11T01:55:28Z"
+ content="""
+here's another occurence of that bug, with --debug this time:
+
+[[!format txt \"\"\"
+anarcat@angela:video$ git annex --debug get films/Example/
+[2014-08-10 21:49:23 EDT] read: git [\"--git-dir=/home/anarcat/video/.git\",\"--work-tree=/home/anarcat/video\",\"ls-files\",\"--cached\",\"-z\",\"--\",\"films/Example/\"]
+get films/Example/Example.mkv [2014-08-10 21:49:23 EDT] read: git [\"--git-dir=/home/anarcat/video/.git\",\"--work-tree=/home/anarcat/video\",\"show-ref\",\"git-annex\"]
+[2014-08-10 21:49:23 EDT] read: git [\"--git-dir=/home/anarcat/video/.git\",\"--work-tree=/home/anarcat/video\",\"show-ref\",\"--hash\",\"refs/heads/git-annex\"]
+[2014-08-10 21:49:23 EDT] read: git [\"--git-dir=/home/anarcat/video/.git\",\"--work-tree=/home/anarcat/video\",\"log\",\"refs/heads/git-annex..7357c09b70e87f35fdc253316520975c94308299\",\"-n1\",\"--pretty=%H\"]
+[2014-08-10 21:49:23 EDT] read: git [\"--git-dir=/home/anarcat/video/.git\",\"--work-tree=/home/anarcat/video\",\"log\",\"refs/heads/git-annex..30bd8b2d719734a73cbadba28dbc0c99107c201f\",\"-n1\",\"--pretty=%H\"]
+[2014-08-10 21:49:23 EDT] read: git [\"--git-dir=/home/anarcat/video/.git\",\"--work-tree=/home/anarcat/video\",\"log\",\"refs/heads/git-annex..bde2aae11f2dcb3fb648ea5e5019fbab56301855\",\"-n1\",\"--pretty=%H\"]
+[2014-08-10 21:49:23 EDT] chat: git [\"--git-dir=/home/anarcat/video/.git\",\"--work-tree=/home/anarcat/video\",\"cat-file\",\"--batch\"]
+[2014-08-10 21:49:23 EDT] read: git [\"config\",\"--null\",\"--list\"]
+(from origin...) [2014-08-10 21:49:23 EDT] read: ssh [\"-O\",\"stop\",\"-S\",\"anarc.at\",\"-o\",\"ControlMaster=auto\",\"-o\",\"ControlPersist=yes\",\"localhost\"]
+
+[2014-08-10 21:49:23 EDT] read: rsync [\"--progress\",\"--inplace\",\"--perms\",\"-e\",\"'ssh' '-S' '.git/annex/ssh/anarc.at' '-o' 'ControlMaster=auto' '-o' 'ControlPersist=yes' '-T' 'anarc.at' 'git-annex-shell ''sendkey'' ''/srv/video'' ''SHA256E-s815462420--a9a6eb45540fd7f3f2598453ef0fc948bec9abb764e85624d66c0707cbd93b22.mkv'' --uuid 5adbab10-0f7a-467b-b0d8-5d7af2223103 ''--'' ''remoteuuid=ae3d62e6-49be-4340-ba25-c8736a1637c4'' ''direct='' ''associatedfile=films/Example/Example.mkv'' ''--'''\",\"--\",\"dummy:\",\"/home/anarcat/video/.git/annex/tmp/SHA256E-s815462420--a9a6eb45540fd7f3f2598453ef0fc948bec9abb764e85624d66c0707cbd93b22.mkv\"]
+protocol version mismatch -- is your shell clean?
+(see the rsync man page for an explanation)
+rsync error: protocol incompatibility (code 2) at compat.c(174) [Receiver=3.0.9]
+
+  rsync failed -- run git annex again to resume file transfer
+
+  Unable to access these remotes: origin
+
+  Try making some of these repositories available:
+        31912b57-62a5-475c-87a7-582b5492a216 -- WD green 1.5TB backup drive
+        5adbab10-0f7a-467b-b0d8-5d7af2223103 -- main (anarcat@marcos:/srv/video) [origin]
+failed
+git-annex: get: 1 failed
+\"\"\"]]
+
+running rsync directly doesn't give me much more info, however, running the `-e` command does:
+
+[[!format txt \"\"\"
+anarcat@angela:video$ ssh '-S' '.git/annex/ssh/anarc.at' '-o' 'ControlMaster=auto' '-o' 'ControlPersist=yes' '-T' 'anarc.at' 'git-annex-shell ''sendkey'' ''/srv/video'' ''SHA256E-s815462420--a9a6eb45540fd7f3f2598453ef0fc948bec9abb764e85624d66c0707cbd93b22.mkv'' --uuid 5adbab10-0f7a-467b-b0d8-5d7af2223103 ''--'' ''remoteuuid=ae3d62e6-49be-4340-ba25-c8736a1637c4'' ''direct='' ''associatedfile=films/Example/Example.mkv'' ''--'''
+(transfer already in progress)
+\"\"\"]]
+
+so it seems that the remote thinks the transfer is still in progress.
+
+to reproduce this, switch between a wired and wireless connexion before interrupting the process.
+"""]]