Recent changes to this wiki:

Added a comment: direct mode: avoid broken symlinks; indirect mode: matching-options in views (not woring)
diff --git a/doc/forum/How_do_I_hide_files_not_present_in_the_local_annex__63__/comment_1_005e9254a1239164df34ab5fbf2115a8._comment b/doc/forum/How_do_I_hide_files_not_present_in_the_local_annex__63__/comment_1_005e9254a1239164df34ab5fbf2115a8._comment
new file mode 100644
index 0000000..b15296b
--- /dev/null
+++ b/doc/forum/How_do_I_hide_files_not_present_in_the_local_annex__63__/comment_1_005e9254a1239164df34ab5fbf2115a8._comment
@@ -0,0 +1,27 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlZ-6dtxJY4cP7shhvV8E6YyuV0Rak8it4"
+ nickname="Giovanni"
+ subject="direct mode: avoid broken symlinks; indirect mode: matching-options in views (not woring)"
+ date="2015-04-18T07:56:32Z"
+ content="""
+I would like to see only locally present files too, for some of my use case (e.g.: movies exported via NFS to a XBMS/Kodi media player)
+
+I'm using git annex (debian) version 5.20141024~bpo70+1
+
+# [direct mode](http://git-annex.branchable.com/direct_mode/)
+
+as far as I understand, in direct mode broken symlinks (or text files placeholders for filesystems not supporting symlinks) are there by [design](
+https://git-annex.branchable.com/design/assistant/desymlink/), in particular in [partial content](
+https://git-annex.branchable.com/design/assistant/partial_content/) use case where \"there needs to be a way for the user to browse files not on the gadget and request they be transferred to it\"
+
+if there are no other reasons to have broken symlinks (or placeholders) I think git-annex should avoid them (at least in direct mode): if a user needs a file not listed by regular filesystem tools she can simply `git-annex find` it and `git-annex get` it: or do I miss something here?
+
+please consider avoiding broken symlinks or placeholders
+
+# indirect mode
+
+in indirect mode we could live with broken symlinks using views; I tried `git annex view /=* --include=\"*\" --in=here` but the resulting tree was not filtered by matching-options
+
+are matching-options intended to work with the view command or not?
+
+"""]]

Added a comment
diff --git a/doc/forum/Git-annex_deleted_all_my_files__44___how_can_I_recover_them__63__/comment_1_65b41a6eb28261e04e4fe8732f97a1f1._comment b/doc/forum/Git-annex_deleted_all_my_files__44___how_can_I_recover_them__63__/comment_1_65b41a6eb28261e04e4fe8732f97a1f1._comment
new file mode 100644
index 0000000..c06b202
--- /dev/null
+++ b/doc/forum/Git-annex_deleted_all_my_files__44___how_can_I_recover_them__63__/comment_1_65b41a6eb28261e04e4fe8732f97a1f1._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="CandyAngel"
+ subject="comment 1"
+ date="2015-04-18T07:16:01Z"
+ content="""
+Are you sure the files are actually deleted? You don't mention using direct mode or anything, so you should be able to reset the git repository to the last commit you did (restoring the symlinks) and be back on track.
+
+Sounds like you missed something either in your description of the problem, or while following the tutorial.
+"""]]

Added a comment
diff --git a/doc/bugs/git-annex_happily_deleted_most_of_my_files___36____35____38____33__/comment_5_fe2ba9550fc9dc2dc877965b436fe823._comment b/doc/bugs/git-annex_happily_deleted_most_of_my_files___36____35____38____33__/comment_5_fe2ba9550fc9dc2dc877965b436fe823._comment
new file mode 100644
index 0000000..d5d2c35
--- /dev/null
+++ b/doc/bugs/git-annex_happily_deleted_most_of_my_files___36____35____38____33__/comment_5_fe2ba9550fc9dc2dc877965b436fe823._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkW9u-8uqR62QBZjeTNCXsL7Ds55dAMGbA"
+ nickname="Horea"
+ subject="comment 5"
+ date="2015-04-17T22:15:07Z"
+ content="""
+I am experiencing the same thing (and have experienced it 1.5 years ago as well, right before deciding to never again use git-annex). Enough info or not is it simply unacceptable for your software to do this and you should look into it as best you can. Try to repeat the steps which he described. I for one, am getting much the same results.
+"""]]

diff --git a/doc/forum/Git-annex_deleted_all_my_files__44___how_can_I_recover_them__63__.mdwn b/doc/forum/Git-annex_deleted_all_my_files__44___how_can_I_recover_them__63__.mdwn
index ed86cd8..c5a0d70 100644
--- a/doc/forum/Git-annex_deleted_all_my_files__44___how_can_I_recover_them__63__.mdwn
+++ b/doc/forum/Git-annex_deleted_all_my_files__44___how_can_I_recover_them__63__.mdwn
@@ -15,5 +15,5 @@ By the time I tied to actually get the content from repo one into repo two (via
 
 How can I get my stuff back?
 
-Also, why would any software which is meant for backup (or any sane software in general) delete stuff without me actually typing `rm` or `delete` into the terminal and without giving me a big warning message and a confirmation prompt? 
+Also, why would any software which is meant for backup or archiving (or any sane software in general) delete stuff without me actually typing `rm` or `delete` into the terminal and without giving me a big warning message and a confirmation prompt? 
  

git annex removed deleted recovery
diff --git a/doc/forum/Git-annex_deleted_all_my_files__44___how_can_I_recover_them__63__.mdwn b/doc/forum/Git-annex_deleted_all_my_files__44___how_can_I_recover_them__63__.mdwn
new file mode 100644
index 0000000..ed86cd8
--- /dev/null
+++ b/doc/forum/Git-annex_deleted_all_my_files__44___how_can_I_recover_them__63__.mdwn
@@ -0,0 +1,19 @@
+I am trying to follow this guide:
+
+https://git-annex.branchable.com/walkthrough/
+
+I:
+
+* created a repository
+* added a remote
+* added all the files via `git annex add .`
+* commited my changes
+* synced my repositories
+
+
+By the time I tied to actually get the content from repo one into repo two (via `git annex get folder`) I noticed that all of my stuff had been deleted from repo one (and not backed up by git annex anywhere else!).
+
+How can I get my stuff back?
+
+Also, why would any software which is meant for backup (or any sane software in general) delete stuff without me actually typing `rm` or `delete` into the terminal and without giving me a big warning message and a confirmation prompt? 
+ 

Typo fixes in doc/tips/*.mdwn
Gotta do at least something when I don't have the faintest clue about
Haskell. :) Learning Haskell is on my agenda, though.
diff --git a/doc/tips/Synology_NAS_and_git_annex.mdwn b/doc/tips/Synology_NAS_and_git_annex.mdwn
index 50c6044..8a6d282 100644
--- a/doc/tips/Synology_NAS_and_git_annex.mdwn
+++ b/doc/tips/Synology_NAS_and_git_annex.mdwn
@@ -19,7 +19,7 @@ This is known to work with DSM 4.3-3810 Update 1 and git-annex standalone versio
 
 (2) Setup ssh key based authentication with the Synology for each computer you want to sync with it. You want a specific key that is used only by git-annex, for each computer. Again, many good guides online.
 
-(3) In the Synology .ssh/authorized_keys file for your account, add (substituing your username)
+(3) In the Synology .ssh/authorized_keys file for your account, add (substituting your username)
 [[!format sh """
 command="/home/$yourusername/.ssh/git-annex-shell"
 """]]
diff --git a/doc/tips/file_manager_integration.mdwn b/doc/tips/file_manager_integration.mdwn
index 4429b90..cd4218f 100644
--- a/doc/tips/file_manager_integration.mdwn
+++ b/doc/tips/file_manager_integration.mdwn
@@ -24,9 +24,9 @@ Even more recent git-annex comes with built-in integration with Konqueror.
 This is set up by git-annex creating a 
 `~/.kde/share/kde4/services/ServiceMenus/git-annex.desktop file.
 
-## XFCE (Thunar)
+## Xfce (Thunar)
 
-XFCE uses the Thunar file manager, which can also be easily configured to
+Xfce uses the Thunar file manager, which can also be easily configured to
 allow for custom actions. Just go to the "Configure custom actions..." item
 in the "Edit" menu, and create a custom action for get, drop, and undo with the
 following commands:
@@ -72,12 +72,12 @@ This gives me the resulting config on disk, in `.config/Thunar/uca.xml`:
         <video-files/>
     </action>
 
-The complete instructions on how to setup actions is [in the XFCE documentation](http://docs.xfce.org/xfce/thunar/custom-actions).
+The complete instructions on how to setup actions is [in the Xfce documentation](http://docs.xfce.org/xfce/thunar/custom-actions).
 
 ## OS X (Finder)
 
 For OS X, it is possible to get context menus in Finder. Due to how OS X
-deals with sym links, one needs to operate on folders if using indirect
+deals with symlinks, one needs to operate on folders if using indirect
 mode. Direct mode operation has not been tested.
 
 1. Open Automator and create a new Service.
diff --git a/doc/tips/megaannex.mdwn b/doc/tips/megaannex.mdwn
index 46bab4a..b547aaa 100644
--- a/doc/tips/megaannex.mdwn
+++ b/doc/tips/megaannex.mdwn
@@ -1,7 +1,7 @@
 megaannex 0.2.0
 =========
 
-Hook program for gitannex to use mega.co.nz as backend
+Hook program for git-annex to use mega.co.nz as backend
 
 # Requirements:
 
diff --git a/doc/tips/using_gitolite_with_git-annex.mdwn b/doc/tips/using_gitolite_with_git-annex.mdwn
index 31f34c6..0d20c93 100644
--- a/doc/tips/using_gitolite_with_git-annex.mdwn
+++ b/doc/tips/using_gitolite_with_git-annex.mdwn
@@ -92,7 +92,7 @@ Make the ADC directory, and a "ua" subdirectory.
 mkdir -p /usr/local/lib/gitolite/adc/ua
 </pre>
 
-Install the git-annex-shell ADC into the "ua" subdirectory from the gitolie repository.
+Install the git-annex-shell ADC into the "ua" subdirectory from the gitolite repository.
 
 <pre>   
 cd /usr/local/lib/gitolite/adc/ua/
diff --git a/doc/tips/using_the_web_as_a_special_remote.mdwn b/doc/tips/using_the_web_as_a_special_remote.mdwn
index 087d2e2..2dc3419 100644
--- a/doc/tips/using_the_web_as_a_special_remote.mdwn
+++ b/doc/tips/using_the_web_as_a_special_remote.mdwn
@@ -81,7 +81,7 @@ it is a video and download the video content for offline viewing.
 Later, in another clone of the repository, you can run `git annex get` on
 the file and it will also be downloaded with the help of quvi. This works
 even if the video host has transcoded or otherwise changed the video
-in the meantime; the assumption is that these video files are equivilant.
+in the meantime; the assumption is that these video files are equivalent.
 
 There is an `annex.quvi-options` configuration setting that can be used
 to pass parameters to quvi. For example, you could set `git config

More typo fixes in doc/*.mdwn
diff --git a/doc/git-union-merge.mdwn b/doc/git-union-merge.mdwn
index d0ceb3a..ca06d2f 100644
--- a/doc/git-union-merge.mdwn
+++ b/doc/git-union-merge.mdwn
@@ -12,7 +12,7 @@ Does a union merge between two refs, storing the result in the
 specified newref.
 
 The union merge will always succeed, but assumes that files can be merged
-simply by concacenating together lines from all the oldrefs, in any order.
+simply by concatenating together lines from all the oldrefs, in any order.
 So, this is useful only for branches containing log-type data.
 
 Note that this does not touch the checked out working copy. It operates
diff --git a/doc/preferred_content.mdwn b/doc/preferred_content.mdwn
index 557305a..d3aa4fa 100644
--- a/doc/preferred_content.mdwn
+++ b/doc/preferred_content.mdwn
@@ -44,7 +44,7 @@ options in commands like this:
 
 	git annex get --include='*.mp3' --and -'(' --not --largerthan=100mb -')'
 
-The equivilant preferred content expression looks like this:
+The equivalent preferred content expression looks like this:
 
 	include=*.mp3 and (not largerthan=100mb)
 
@@ -63,7 +63,7 @@ to not retain those files, like this:
 
 ### difference: no "in="
 
-Preferred content expressions have no direct equivilant to `--in`.
+Preferred content expressions have no direct equivalent to `--in`.
 
 Often, it's best to add repositories to groups, and match against
 the groups in a preferred content expression. So rather than
@@ -146,7 +146,7 @@ expression tuned for your needs, and every repository you put in this
 group and make its preferred content be "groupwanted" will use it.
 
 For example, the archive group only wants to archive 1 copy of each file,
-spread amoung every repository in the group.
+spread among every repository in the group.
 Here's how to configure a group named redundantarchive, that instead
 wants to contain 3 copies of each file:
 
diff --git a/doc/related_software.mdwn b/doc/related_software.mdwn
index 4b6f42d..a0462f5 100644
--- a/doc/related_software.mdwn
+++ b/doc/related_software.mdwn
@@ -4,9 +4,9 @@ designed to interoperate with it.
 * The [[git-annex assistant|assistant]] is included in git-annex,
   and extends its use cases into new territory.
 * [gitlab-shell](https://gitlab.com/gitlab-org/gitlab-shell) supports
-  git-annex. So git-annex can be used with repositries served by Gitlab,
+  git-annex. So git-annex can be used with repositories served by GitLab,
   including gitlab.com, or deploy your own.
-  [See Gitlab's announcment](https://about.gitlab.com/2015/02/17/gitlab-annex-solves-the-problem-of-versioning-large-binaries-with-git/)
+  [See GitLab's announcement](https://about.gitlab.com/2015/02/17/gitlab-annex-solves-the-problem-of-versioning-large-binaries-with-git/)
 * Emacs Org mode can auto-commit attached files to git-annex.
 * [git annex darktable integration](https://github.com/xxv/darktable-git-annex)
 * [Magit](http://github.com/magit/magit), an Emacs mode for Git, has

Various typo fixes in doc/*.mdwn
One of my
for f in `ls *.mdwn | sort -R`; do aspell -c $f; sleep 2; done
sessions.
3647f704-e510-11e4-bf50-000df06acc56
diff --git a/doc/git-annex-lock.mdwn b/doc/git-annex-lock.mdwn
index aa03d4c..21be9f5 100644
--- a/doc/git-annex-lock.mdwn
+++ b/doc/git-annex-lock.mdwn
@@ -1,6 +1,6 @@
 # NAME
 
-git-annex lock - unco unlock command
+git-annex lock - undo unlock command
 
 # SYNOPSIS
 
diff --git a/doc/git-annex-preferred-content.mdwn b/doc/git-annex-preferred-content.mdwn
index 9ea19ce..95dae8c 100644
--- a/doc/git-annex-preferred-content.mdwn
+++ b/doc/git-annex-preferred-content.mdwn
@@ -18,7 +18,7 @@ For example:
 
 The main differences are that `exclude=` and `include=` always
 match relative to the top of the git repository, and that there is
-no equivilant to `--in`.
+no equivalent to `--in`.
 
 For more details about preferred content expressions, see
 See <https://git-annex.branchable.com/preferred_content/>
diff --git a/doc/git-annex-readpresentkey.mdwn b/doc/git-annex-readpresentkey.mdwn
index 3e552e0..6dcc2ca 100644
--- a/doc/git-annex-readpresentkey.mdwn
+++ b/doc/git-annex-readpresentkey.mdwn
@@ -9,7 +9,7 @@ git annex readpresentkey `key uuid`
 # DESCRIPTION
 
 This plumbing-level command reads git-annex's records about whether
-the specified key's content is present in the remote with the speficied
+the specified key's content is present in the remote with the specified
 uuid.
   
 It exits 0 if the key is recorded to be present and 1 if not.
diff --git a/doc/git-annex-shell.mdwn b/doc/git-annex-shell.mdwn
index e43d516..4185774 100644
--- a/doc/git-annex-shell.mdwn
+++ b/doc/git-annex-shell.mdwn
@@ -86,7 +86,7 @@ to git-annex-shell are:
 
 * -- fields=val fields=val.. --
 
-  Additional fields may be specified this way, to retain compatability with
+  Additional fields may be specified this way, to retain compatibility with
   past versions of git-annex-shell (that ignore these, but would choke
   on new dashed options).
 
diff --git a/doc/privacy.mdwn b/doc/privacy.mdwn
index 3ac4b1e..5be735d 100644
--- a/doc/privacy.mdwn
+++ b/doc/privacy.mdwn
@@ -41,7 +41,7 @@ output you post, and feel free to remove identifying information.
 Note that the git-annex assistant *does* sanitize XMPP protocol information
 logged when debugging is enabled.
 
-If you prefer not to post information publicaly, you can send a GPG
+If you prefer not to post information publically, you can send a GPG
 encrypted mail to Joey Hess <id@joeyh.name> (gpg key ID 2512E3C7).
 Or you can post a public bug report, and send a followup email with private
 details.
diff --git a/doc/transferring_data.mdwn b/doc/transferring_data.mdwn
index d1ec596..2aab3b0 100644
--- a/doc/transferring_data.mdwn
+++ b/doc/transferring_data.mdwn
@@ -9,7 +9,7 @@ If a data transfer is interrupted, git-annex retains the partial transfer
 to allow it to be automatically resumed later.
 
 It's equally easy to transfer a single file to or from a repository,
-or to launch a retrievel of a massive pile of files from whatever
+or to launch a retrieval of a massive pile of files from whatever
 repositories they are scattered amongst.
 
 git-annex automatically uses whatever remotes are currently accessible,
diff --git a/doc/trust.mdwn b/doc/trust.mdwn
index 1fd47fd..a33c6dd 100644
--- a/doc/trust.mdwn
+++ b/doc/trust.mdwn
@@ -45,7 +45,7 @@ archival drive, from which you rarely or never remove content. Deciding
 when it makes sense to trust the tracking info is up to you.
 
 One way to handle this is just to use `--force` when a command cannot
-access a remote you trust. Or to use `--trust` to specify a repisitory to
+access a remote you trust. Or to use `--trust` to specify a repository to
 trust temporarily.
 
 To configure a repository as fully and permanently trusted,
@@ -55,5 +55,5 @@ use the `git annex trust` command.
 
 This is used to indicate that you have no trust that the repository
 exists at all. It's appropriate to use when a drive has been lost,
-or a directory irretrevably deleted. It will make git-annex avoid
+or a directory irretrievably deleted. It will make git-annex avoid
 even showing the repository as a place where data might still reside.
diff --git a/doc/upgrades.mdwn b/doc/upgrades.mdwn
index 0b43a97..6cf2784 100644
--- a/doc/upgrades.mdwn
+++ b/doc/upgrades.mdwn
@@ -1,9 +1,9 @@
-Occasionally improvments are made to how git-annex stores its data,
+Occasionally improvements are made to how git-annex stores its data,
 that require an upgrade process to convert repositories made with an older
 version to be used by a newer version. It's annoying, it should happen
 rarely, but sometimes, it's worth it.
 
-There's a committment that git-annex will always support upgrades from all
+There's a commitment that git-annex will always support upgrades from all
 past versions. After all, you may have offline drives from an earlier
 git-annex, and might want to use them with a newer git-annex.
 

Added a comment
diff --git a/doc/forum/__34__git_annex_sync__34___synced_after_8_hours/comment_5_26de32ea240621e23717c55866ad9764._comment b/doc/forum/__34__git_annex_sync__34___synced_after_8_hours/comment_5_26de32ea240621e23717c55866ad9764._comment
new file mode 100644
index 0000000..907f32b
--- /dev/null
+++ b/doc/forum/__34__git_annex_sync__34___synced_after_8_hours/comment_5_26de32ea240621e23717c55866ad9764._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="CandyAngel"
+ subject="comment 5"
+ date="2015-04-16T21:08:32Z"
+ content="""
+My pleasure, glad it is working for you!
+
+Going forward, you should run *git repack* (without -ad) every now and again to pack new objects into pack files. You can use *git count-objects -v* to find out how many unpacked objects you have.
+"""]]

patch
diff --git a/doc/bugs/Proxy_support.mdwn b/doc/bugs/Proxy_support.mdwn
index ae6eaf6..05274de 100644
--- a/doc/bugs/Proxy_support.mdwn
+++ b/doc/bugs/Proxy_support.mdwn
@@ -17,3 +17,10 @@ Please provide any additional information below.
 
 I don't use networkmanager if proxy information is obtained from it. There should be a fallback to environment variables.
 [[!tag confirmed]]
+
+> Here's a patch that shows how to enable proxy support for the
+> parts of git-annex that use http-client and http-conduit:
+> <https://github.com/kiwiroy/git-annex/commit/18a3ceda1beb7c356541270f37ae4c0d56ada726>
+> 
+> Other parts of git-annex use wget/curl and should already support
+> the environment variables.

Added a comment
diff --git a/doc/forum/__34__git_annex_sync__34___synced_after_8_hours/comment_4_0051e83196945b97e2f3ed14a58daaea._comment b/doc/forum/__34__git_annex_sync__34___synced_after_8_hours/comment_4_0051e83196945b97e2f3ed14a58daaea._comment
new file mode 100644
index 0000000..2fc762f
--- /dev/null
+++ b/doc/forum/__34__git_annex_sync__34___synced_after_8_hours/comment_4_0051e83196945b97e2f3ed14a58daaea._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlXt6nnNs-3uw61EGYtxr_AVhJqXybwLR8"
+ nickname="Bruno"
+ subject="comment 4"
+ date="2015-04-16T11:47:50Z"
+ content="""
+Thanks @CandyAngle, 
+
+Effectively, your tips for reduce a time for some git-annex commands if works fine, i will see in the long term if that is work perfectly
+
+ex:, now **git annex sync** it work in **45s** ! :)
+
+Thanks
+"""]]

fix git-annex version formatting
diff --git a/doc/bugs/addurl_+_sync_vs_addurl_+_commit.mdwn b/doc/bugs/addurl_+_sync_vs_addurl_+_commit.mdwn
index ab5f00f..cb86405 100644
--- a/doc/bugs/addurl_+_sync_vs_addurl_+_commit.mdwn
+++ b/doc/bugs/addurl_+_sync_vs_addurl_+_commit.mdwn
@@ -14,12 +14,11 @@ git annex sync
 
 ### What version of git-annex are you using? On what operating system?
 
-git-annex version: 5.20150412-g2be4834
-build flags: Assistant Webapp Webapp-secure Pairing Testsuite S3 WebDAV Inotify DBus DesktopNotify XMPP DNS Feeds Quvi TDFA TorrentParser
-key/value backends: SHA256E SHA1E SHA512E SHA224E SHA384E SKEIN256E SKEIN512E MD5E SHA256 SHA1 SHA512 SHA224 SHA384 SKEIN256 SKEIN512 MD5 WORM URL
-remote types: git gcrypt S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external
-local repository version: 5
-supported repository version: 5
-upgrade supported from repository versions: 0 1 2 4
-
+    git-annex version: 5.20150412-g2be4834
+    build flags: Assistant Webapp Webapp-secure Pairing Testsuite S3 WebDAV Inotify DBus DesktopNotify XMPP DNS Feeds Quvi TDFA TorrentParser
+    key/value backends: SHA256E SHA1E SHA512E SHA224E SHA384E SKEIN256E SKEIN512E MD5E SHA256 SHA1 SHA512 SHA224 SHA384 SKEIN256 SKEIN512 MD5 WORM URL
+    remote types: git gcrypt S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external
+    local repository version: 5
+    supported repository version: 5
+    upgrade supported from repository versions: 0 1 2 4
 This is on Linux.

Added a comment
diff --git a/doc/forum/__34__git_annex_sync__34___synced_after_8_hours/comment_3_c50b62e5a84b861117a4405c2a2f5cfb._comment b/doc/forum/__34__git_annex_sync__34___synced_after_8_hours/comment_3_c50b62e5a84b861117a4405c2a2f5cfb._comment
new file mode 100644
index 0000000..20031b9
--- /dev/null
+++ b/doc/forum/__34__git_annex_sync__34___synced_after_8_hours/comment_3_c50b62e5a84b861117a4405c2a2f5cfb._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="CandyAngel"
+ subject="comment 3"
+ date="2015-04-16T07:41:07Z"
+ content="""
+*git annex info* has check every file (not sure if it traverses *.git/annex/objects* specifically or not) to get \"local annex\" information. You can improve its performance by improving directory traversal in general (different filesystem or [changing the hashing method so it isn't Xx/Yy/KEY/FILE](https://github.com/datalad/datalad/issues/32)).
+
+The repack/gc speeds up operations for the git side of things, like syncing (pull/push), cloning and committing.
+
+Here's what I used:
+
+    git repack -ad
+    git gc
+
+This took git actions down from 1 hour+ to ~10 minutes (for a repo with 5.6 million objects).
+"""]]

diff --git a/doc/forum/How_do_I_hide_files_not_present_in_the_local_annex__63__.mdwn b/doc/forum/How_do_I_hide_files_not_present_in_the_local_annex__63__.mdwn
new file mode 100644
index 0000000..72e39cc
--- /dev/null
+++ b/doc/forum/How_do_I_hide_files_not_present_in_the_local_annex__63__.mdwn
@@ -0,0 +1,2 @@
+Files only present in remotes show up as broken symlinks. That's great for knowing what files exist, but sometimes I just want to browse the files that are actually present. In this case, the many broken symlinks are just clutter.
+Is there a straightforward way to switch to a view that shows only locally present files?

formatting
diff --git a/doc/bugs/addurl_+_sync_vs_addurl_+_commit.mdwn b/doc/bugs/addurl_+_sync_vs_addurl_+_commit.mdwn
index 23490a4..ab5f00f 100644
--- a/doc/bugs/addurl_+_sync_vs_addurl_+_commit.mdwn
+++ b/doc/bugs/addurl_+_sync_vs_addurl_+_commit.mdwn
@@ -6,9 +6,11 @@ I've got a git repository, and I just ran git annex init. Then I ran git annex a
 
 ### What steps will reproduce the problem?
 
+[[!format sh """
 git annex init
-git annex addurl https://archive.org/download/emularity_engine_jsmess/messnapple2e.js.gz --file messnapple2e.js.gz
+git annex addurl "https://archive.org/download/emularity_engine_jsmess/messnapple2e.js.gz" --file "messnapple2e.js.gz"
 git annex sync
+"""]]
 
 ### What version of git-annex are you using? On what operating system?
 

diff --git a/doc/bugs/addurl_+_sync_vs_addurl_+_commit.mdwn b/doc/bugs/addurl_+_sync_vs_addurl_+_commit.mdwn
new file mode 100644
index 0000000..23490a4
--- /dev/null
+++ b/doc/bugs/addurl_+_sync_vs_addurl_+_commit.mdwn
@@ -0,0 +1,23 @@
+### Please describe the problem.
+
+I think this is what happened; I need to go back and check this again (maybe I was just misreading something) but I want to get it written down first.
+
+I've got a git repository, and I just ran git annex init. Then I ran git annex addurl a bunch of times, followed by git annex sync. The result was apparently a repository where the files downloaded by addurl were added using the SHA256 backend rather than the URL backend. I deleted the branches and tried again, but this time after calling git annex addurl a bunch of times I did a normal git commit. This time everything looked fine; the files were all listed in as present in the web remote.
+
+### What steps will reproduce the problem?
+
+git annex init
+git annex addurl https://archive.org/download/emularity_engine_jsmess/messnapple2e.js.gz --file messnapple2e.js.gz
+git annex sync
+
+### What version of git-annex are you using? On what operating system?
+
+git-annex version: 5.20150412-g2be4834
+build flags: Assistant Webapp Webapp-secure Pairing Testsuite S3 WebDAV Inotify DBus DesktopNotify XMPP DNS Feeds Quvi TDFA TorrentParser
+key/value backends: SHA256E SHA1E SHA512E SHA224E SHA384E SKEIN256E SKEIN512E MD5E SHA256 SHA1 SHA512 SHA224 SHA384 SKEIN256 SKEIN512 MD5 WORM URL
+remote types: git gcrypt S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external
+local repository version: 5
+supported repository version: 5
+upgrade supported from repository versions: 0 1 2 4
+
+This is on Linux.

Added a comment
diff --git a/doc/forum/__34__git_annex_sync__34___synced_after_8_hours/comment_2_d13a0af48b8831c81276a0b2c8e25303._comment b/doc/forum/__34__git_annex_sync__34___synced_after_8_hours/comment_2_d13a0af48b8831c81276a0b2c8e25303._comment
new file mode 100644
index 0000000..940922e
--- /dev/null
+++ b/doc/forum/__34__git_annex_sync__34___synced_after_8_hours/comment_2_d13a0af48b8831c81276a0b2c8e25303._comment
@@ -0,0 +1,37 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlXt6nnNs-3uw61EGYtxr_AVhJqXybwLR8"
+ nickname="Bruno"
+ subject="comment 2"
+ date="2015-04-15T17:51:18Z"
+ content="""
+@CandyAngel Thank you for your **git annex find** tips. But for git gc, it seem not working fine :)
+After i have executed the **git gc**, the **git annex info** return the result after **1h 45m**
+
+    % time git annex info
+    repository mode: indirect
+    trusted repositories: 0
+    semitrusted repositories: 5
+	00000000-0000-0000-0000-000000000001 -- web
+ 	00000000-0000-0000-0000-000000000002 -- bittorrent
+ 	181d4dae-2131-435e-9c00-b8c7f1bfc332 -- [sbackup]
+ 	2db1f8e7-0b29-4d61-8875-a4a4a42a79dd -- [dellcomputer]
+ 	703df355-73a6-4487-97fd-a3a5d6ae034e -- usbhomebackup [here]
+    untrusted repositories: 0
+    transfers in progress: none
+    available local disk space: 135.24 gigabytes (+1 megabyte reserved)
+    local annex keys: 275416
+    local annex size: 780.55 gigabytes
+    annexed files in working tree: 265888
+    size of annexed files in working tree: 751.49 gigabytes
+    bloom filter size: 16 mebibytes (55.1% full)
+    backend usage: 
+	SHA256E: 541304
+
+git annex info  83,95s user 50,68s system 2% **cpu 1:45:01,70 total**
+
+
+Can you explain exactly the git gc or git repack parameters that you use for optimizing git annex performance  ?
+
+Thanks
+
+"""]]

diff --git a/doc/forum/How_to_find_deleted_files_that_I_know_have_been_backed_up__63__.mdwn b/doc/forum/How_to_find_deleted_files_that_I_know_have_been_backed_up__63__.mdwn
new file mode 100644
index 0000000..998c608
--- /dev/null
+++ b/doc/forum/How_to_find_deleted_files_that_I_know_have_been_backed_up__63__.mdwn
@@ -0,0 +1,9 @@
+<video src=http://s.natalian.org/2015-04-15/git-annex-issues.mp4></video>
+
+I removed some archived directories perhaps foolishly with `rm -rf`. How do I find the files that I've had deleted?
+
+
+
+I also have an issue where by I want one command to sync between two hardrives and [github](https://github.com/kaihendry/uploadme). Or do I have to: `git-annex move --to {foo,bar}; git-annex drop; git-annex sync`? Basically I want copies everywhere except on my laptop (X1C3).
+
+I also expected my git dir to be much smaller than 1.4GB after dropping everything. Thanks!

update
diff --git a/doc/devblog/day_275-276__mostly_Windows.mdwn b/doc/devblog/day_275-276__mostly_Windows.mdwn
index 4b5a066..bcdc946 100644
--- a/doc/devblog/day_275-276__mostly_Windows.mdwn
+++ b/doc/devblog/day_275-276__mostly_Windows.mdwn
@@ -2,6 +2,9 @@ Mostly working on Windows recently. Fixed handling of git
 repos on different drive letters. Fixed crazy start menu loop. Worked around
 stange msysgit version problem.
 
+Also some more work on the `concurrentprogress` branch, making the progress
+display prettier.
+
 Added one nice new feature yesterday: `git annex info $dir` now includes a
 table of repositories that are storing files in the directory, with their
 sizes.

Added a comment
diff --git a/doc/todo/addurl___8211__force-torrent_option/comment_2_52c04c388b807993cecacc7f98b73cd3._comment b/doc/todo/addurl___8211__force-torrent_option/comment_2_52c04c388b807993cecacc7f98b73cd3._comment
new file mode 100644
index 0000000..f6d52be
--- /dev/null
+++ b/doc/todo/addurl___8211__force-torrent_option/comment_2_52c04c388b807993cecacc7f98b73cd3._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkutSE8_3fFAETmO_E598zja4gKwYXbb8E"
+ nickname="Сергей"
+ subject="comment 2"
+ date="2015-04-14T19:57:52Z"
+ content="""
+Sure, that's even better.
+"""]]

devblog
diff --git a/doc/devblog/day_275-276__mostly_Windows.mdwn b/doc/devblog/day_275-276__mostly_Windows.mdwn
new file mode 100644
index 0000000..4b5a066
--- /dev/null
+++ b/doc/devblog/day_275-276__mostly_Windows.mdwn
@@ -0,0 +1,17 @@
+Mostly working on Windows recently. Fixed handling of git
+repos on different drive letters. Fixed crazy start menu loop. Worked around
+stange msysgit version problem.
+
+Added one nice new feature yesterday: `git annex info $dir` now includes a
+table of repositories that are storing files in the directory, with their
+sizes.
+
+	repositories containing these files: 
+		288.98 MB: ca9c5d52-f03a-11df-ac14-6b772ffe59f9 -- archive-5
+		288.98 MB: f1c0ce8d-d848-4d21-988c-dd78eed172e8 -- archive-8
+		 10.48 MB: 587b9ccf-4548-4d6f-9765-27faecc4105f -- darkstar
+		 15.18 kB: 42d47daa-45fd-11e0-9827-9f142c1630b3 -- origin
+
+Nice thing about this feature is it's done for free, with no extra work other
+than a little bit of addition. All the heavy location lookup work was already
+being done to get the numcopies stats.

comment
diff --git a/doc/todo/git-annex-standalone_Debian_package/comment_4_0aecbfdc9048df2131d99ad316f5d6f7._comment b/doc/todo/git-annex-standalone_Debian_package/comment_4_0aecbfdc9048df2131d99ad316f5d6f7._comment
new file mode 100644
index 0000000..0f2393f
--- /dev/null
+++ b/doc/todo/git-annex-standalone_Debian_package/comment_4_0aecbfdc9048df2131d99ad316f5d6f7._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2015-04-14T19:14:16Z"
+ content="""
+The quilt series sounds reasonable if there's tooling to support building
+that way.
+"""]]

comment
diff --git a/doc/todo/addurl___8211__force-torrent_option/comment_1_15be1914c8d05cd1ad8220bcfea9d0bf._comment b/doc/todo/addurl___8211__force-torrent_option/comment_1_15be1914c8d05cd1ad8220bcfea9d0bf._comment
new file mode 100644
index 0000000..456fb1a
--- /dev/null
+++ b/doc/todo/addurl___8211__force-torrent_option/comment_1_15be1914c8d05cd1ad8220bcfea9d0bf._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-04-14T19:11:28Z"
+ content="""
+I'd prefer torrent:url; this is consistent with quvi:url for forcing quvi
+be used.
+"""]]

fix relPathDirToFileAbs on windows with different drive letters
Since we started using this for git repos, when a remote was on another
drive, it resulted in a bogus relative path to it being used by git-annex,
which didn't work.
diff --git a/Utility/Path.hs b/Utility/Path.hs
index 2675aa0..72d4378 100644
--- a/Utility/Path.hs
+++ b/Utility/Path.hs
@@ -138,9 +138,15 @@ relPathDirToFile from to = relPathDirToFileAbs <$> absPath from <*> absPath to
 
 {- This requires the first path to be absolute, and the
  - second path cannot contain ../ or ./
+ -
+ - On Windows, if the paths are on different drives,
+ - a relative path is not possible and the path is simply
+ - returned as-is.
  -}
 relPathDirToFileAbs :: FilePath -> FilePath -> FilePath
-relPathDirToFileAbs from to = join s $ dotdots ++ uncommon
+relPathDirToFileAbs from to
+	| takeDrive from /= takeDrive to = to
+	| otherwise = join s $ dotdots ++ uncommon
   where
 	s = [pathSeparator]
 	pfrom = split s from
diff --git a/debian/changelog b/debian/changelog
index 3ff3c9a..5f62dc6 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -10,6 +10,8 @@ git-annex (5.20150410) UNRELEASED; urgency=medium
   * Windows: Renamed start menu file to avoid loop in some versions
     of Windows where the menu file is treated as a git-annex program.
   * bittorrent: Fix handling of magnet links.
+  * Windows: Fixed support of remotes on other drives.
+    (A reversion introduced in version 5.20150113.)
 
  -- Joey Hess <id@joeyh.name>  Thu, 09 Apr 2015 20:59:43 -0400
 
diff --git a/doc/bugs/Windows:_Annex_can_not_get_files.mdwn b/doc/bugs/Windows:_Annex_can_not_get_files.mdwn
index 8f63613..f236240 100644
--- a/doc/bugs/Windows:_Annex_can_not_get_files.mdwn
+++ b/doc/bugs/Windows:_Annex_can_not_get_files.mdwn
@@ -158,3 +158,5 @@ ok
 C:\annex1>cd \annex2
 
 """]]
+
+> [[fixed|done]]; a simple path calculation bug. --[[Joey]]
diff --git a/doc/bugs/Windows:_repo_located_on_different_drive_letter_unavailable.mdwn b/doc/bugs/Windows:_repo_located_on_different_drive_letter_unavailable.mdwn
index 3116751..070191a 100644
--- a/doc/bugs/Windows:_repo_located_on_different_drive_letter_unavailable.mdwn
+++ b/doc/bugs/Windows:_repo_located_on_different_drive_letter_unavailable.mdwn
@@ -160,3 +160,5 @@ Latest sync command should inject annex-uuid to .config file, but it does not. F
     [remote "c"]
         url = C:\\Annex
         fetch = +refs/heads/*:refs/remotes/c/*
+
+> [[fixed|done]]; a simple path calculation bug. --[[Joey]]

moreinfo
diff --git a/doc/bugs/encryption__61__none_doesn__39__t_work_with_enableremote.mdwn b/doc/bugs/encryption__61__none_doesn__39__t_work_with_enableremote.mdwn
index 9eecdf5..991d054 100644
--- a/doc/bugs/encryption__61__none_doesn__39__t_work_with_enableremote.mdwn
+++ b/doc/bugs/encryption__61__none_doesn__39__t_work_with_enableremote.mdwn
@@ -40,3 +40,5 @@ upgrade supported from repository versions: 0 1 2 4
 
 # End of transcript or log.
 """]]
+
+[[!tag moreinfo]]

moreinfo
diff --git a/doc/bugs/false_positives_from_fsck_in_bare_repo.mdwn b/doc/bugs/false_positives_from_fsck_in_bare_repo.mdwn
index cb11639..215db11 100644
--- a/doc/bugs/false_positives_from_fsck_in_bare_repo.mdwn
+++ b/doc/bugs/false_positives_from_fsck_in_bare_repo.mdwn
@@ -43,3 +43,5 @@ $
 
 # End of transcript or log.
 """]]
+
+[[!tag moreinfo]]

comment
diff --git a/doc/bugs/Windows:_repo_located_on_different_drive_letter_unavailable/comment_3_418a94a7257c2c5eaa7e0febe93c33ab._comment b/doc/bugs/Windows:_repo_located_on_different_drive_letter_unavailable/comment_3_418a94a7257c2c5eaa7e0febe93c33ab._comment
new file mode 100644
index 0000000..6641bb7
--- /dev/null
+++ b/doc/bugs/Windows:_repo_located_on_different_drive_letter_unavailable/comment_3_418a94a7257c2c5eaa7e0febe93c33ab._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2015-04-14T17:32:29Z"
+ content="""
+This is partly a bug in uuid discovery; however even after I manually fill
+in the remote's annex-uuid, it cannot get the file.
+"""]]

comment
diff --git a/doc/bugs/Windows:_Annex_can_not_get_files/comment_3_5039702d7676b4712bb2bf586a83e591._comment b/doc/bugs/Windows:_Annex_can_not_get_files/comment_3_5039702d7676b4712bb2bf586a83e591._comment
new file mode 100644
index 0000000..f5878a2
--- /dev/null
+++ b/doc/bugs/Windows:_Annex_can_not_get_files/comment_3_5039702d7676b4712bb2bf586a83e591._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2015-04-14T17:28:11Z"
+ content="""
+There is quite a lot of unrelated noise in this bug report. For example,
+when you run "git annex init dir1", you're telling git-annex to refer to
+that repository as "dir1". It should thus be unsuprising when it does in
+whereis etc messages about that repository.
+
+This is a duplicate of
+<http://git-annex.branchable.com/bugs/Windows:_repo_located_on_different_drive_letter_unavailable/>
+"""]]

move a comment that I posted to the wrong bug report because the bug submitter intentionally chose a nearly identical title to their old, unrelated bug report. sheesh.
diff --git a/doc/bugs/commitBuffer:_invalid_argument___40__invalid_character__41__/comment_1_b56c847c5eda432a4330b4d853a25519._comment b/doc/bugs/commitBuffer:_invalid_argument___40__invalid_character__41__/comment_1_b56c847c5eda432a4330b4d853a25519._comment
deleted file mode 100644
index 43e6a39..0000000
--- a/doc/bugs/commitBuffer:_invalid_argument___40__invalid_character__41__/comment_1_b56c847c5eda432a4330b4d853a25519._comment
+++ /dev/null
@@ -1,27 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 1"""
- date="2015-04-09T17:49:57Z"
- content="""
-I cannot reproduce this, I get:
-
-	addurl _dev_radio/DR14__Verschwörungstheorien.ogg ok
-
-Does the _dev_radio/DR14__Verschwörungstheorien.ogg file get created?
-If so, how does it look?
-
-The jlog tells me it's trying to commit the git-annex branch journal.
-Does .git/annex/journal/ contain any files? Any files containing German
-characters?
-
-Do you have any git config settings for git-annex beyone the typical
-annex.uuid?
-
-I noticed one place in the journal commit code where it does seem to
-neglect to use filesystem encoding when dealing with writing filenames to
-the jlog tmpfile. Which could lead to this crash theoretically. I've fixed
-that, but since I couldn't reproduce the problem, I don't know if this will
-fix your problem. Nor do I understand how annex journal log files could
-have these characters in their names. You can try today's upcoming release
-of git-annex to test the fix though.
-"""]]
diff --git a/doc/bugs/commitBuffer:_invalid_argument___40__invalid_character__41__2/comment_1_b56c847c5eda432a4330b4d853a25519._comment b/doc/bugs/commitBuffer:_invalid_argument___40__invalid_character__41__2/comment_1_b56c847c5eda432a4330b4d853a25519._comment
new file mode 100644
index 0000000..43e6a39
--- /dev/null
+++ b/doc/bugs/commitBuffer:_invalid_argument___40__invalid_character__41__2/comment_1_b56c847c5eda432a4330b4d853a25519._comment
@@ -0,0 +1,27 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-04-09T17:49:57Z"
+ content="""
+I cannot reproduce this, I get:
+
+	addurl _dev_radio/DR14__Verschwörungstheorien.ogg ok
+
+Does the _dev_radio/DR14__Verschwörungstheorien.ogg file get created?
+If so, how does it look?
+
+The jlog tells me it's trying to commit the git-annex branch journal.
+Does .git/annex/journal/ contain any files? Any files containing German
+characters?
+
+Do you have any git config settings for git-annex beyone the typical
+annex.uuid?
+
+I noticed one place in the journal commit code where it does seem to
+neglect to use filesystem encoding when dealing with writing filenames to
+the jlog tmpfile. Which could lead to this crash theoretically. I've fixed
+that, but since I couldn't reproduce the problem, I don't know if this will
+fix your problem. Nor do I understand how annex journal log files could
+have these characters in their names. You can try today's upcoming release
+of git-annex to test the fix though.
+"""]]

close
diff --git a/doc/bugs/git-annex-shell_doesn__39__t_work_as_expected.mdwn b/doc/bugs/git-annex-shell_doesn__39__t_work_as_expected.mdwn
index 93d890d..f77f33a 100644
--- a/doc/bugs/git-annex-shell_doesn__39__t_work_as_expected.mdwn
+++ b/doc/bugs/git-annex-shell_doesn__39__t_work_as_expected.mdwn
@@ -117,3 +117,5 @@ git-annex: unknown command anarc.at
 </pre>
 
 Turning off `sshcaching` seems to work around the issue. Note that this happens even if the git repo is moved to a non-NFS filesystem, so I have the feeling it's not directly related to [this bugfix](http://source.git-annex.branchable.com/?p=source.git;a=commit;h=bd110516c09d318b298804efc4ee888270f3d601).
+
+> [[done]]

moreinfo
diff --git a/doc/bugs/git-annex_unused_--from_s3_doesn__39__t.mdwn b/doc/bugs/git-annex_unused_--from_s3_doesn__39__t.mdwn
index 07ae44e..db41d07 100644
--- a/doc/bugs/git-annex_unused_--from_s3_doesn__39__t.mdwn
+++ b/doc/bugs/git-annex_unused_--from_s3_doesn__39__t.mdwn
@@ -27,3 +27,5 @@ arch linux x86_64
 ### Please provide any additional information below.
 
 The S3 remote is encrypted with the default "hybrid" method
+
+[[!tag moreinfo]]

rename obnoxiosly named file
diff --git a/doc/bugs/--list-tests_runs_tests.mdwn b/doc/bugs/--list-tests_runs_tests.mdwn
deleted file mode 100644
index cea58db..0000000
--- a/doc/bugs/--list-tests_runs_tests.mdwn
+++ /dev/null
@@ -1,28 +0,0 @@
-### Please describe the problem.
-Running "git annex test --list-tests" seems to produce the same output as "git annex test" rather than list tests.
-
-### What steps will reproduce the problem?
-git annex test --list-tests
-
-### What version of git-annex are you using? On what operating system?
-5.20150317-g237d5b0 on Centos 6.6 and Ubuntu 12.04.5
-
-5.20141125 on Mac OS X 10.10.2
-
-### Please provide any additional information below.
-
-[[!format sh """
-# this is version 5.20150317-g237d5b0 on Ubuntu
-$ ./git-annex test --list-tests
-Tests
-  QuickCheck
-    prop_idempotent_deencode_git:                   OK (0.15s)
-      +++ OK, passed 1000 tests.
-    prop_idempotent_deencode:                       OK (0.12s)
-      +++ OK, passed 1000 tests.
-[snip all the passing tests]
-All 140 tests passed (305.69s)
-"""]]
-
-> [[fixed|done]] although I don't understand why tasty needs the
-> `listingTests` ingredient to come first for it to work. --[[Joey]]
diff --git a/doc/bugs/list-tests_runs_tests.mdwn b/doc/bugs/list-tests_runs_tests.mdwn
new file mode 100644
index 0000000..cea58db
--- /dev/null
+++ b/doc/bugs/list-tests_runs_tests.mdwn
@@ -0,0 +1,28 @@
+### Please describe the problem.
+Running "git annex test --list-tests" seems to produce the same output as "git annex test" rather than list tests.
+
+### What steps will reproduce the problem?
+git annex test --list-tests
+
+### What version of git-annex are you using? On what operating system?
+5.20150317-g237d5b0 on Centos 6.6 and Ubuntu 12.04.5
+
+5.20141125 on Mac OS X 10.10.2
+
+### Please provide any additional information below.
+
+[[!format sh """
+# this is version 5.20150317-g237d5b0 on Ubuntu
+$ ./git-annex test --list-tests
+Tests
+  QuickCheck
+    prop_idempotent_deencode_git:                   OK (0.15s)
+      +++ OK, passed 1000 tests.
+    prop_idempotent_deencode:                       OK (0.12s)
+      +++ OK, passed 1000 tests.
+[snip all the passing tests]
+All 140 tests passed (305.69s)
+"""]]
+
+> [[fixed|done]] although I don't understand why tasty needs the
+> `listingTests` ingredient to come first for it to work. --[[Joey]]

confirmed
diff --git a/doc/bugs/fsck_reports_unsolvable_problem.mdwn b/doc/bugs/fsck_reports_unsolvable_problem.mdwn
index 660bb19..d0164f8 100644
--- a/doc/bugs/fsck_reports_unsolvable_problem.mdwn
+++ b/doc/bugs/fsck_reports_unsolvable_problem.mdwn
@@ -16,3 +16,5 @@ According to IRC this "can happen if you annexed a file and then deleted it with
 ### What version of git-annex are you using? On what operating system?
 
 5.20140717 from Ubuntu utopic
+
+[[!tag confirmed]]

fixed
diff --git a/doc/bugs/windows_start_menu_shortcuts_are_missing___34__Start_in__34___parameter.mdwn b/doc/bugs/windows_start_menu_shortcuts_are_missing___34__Start_in__34___parameter.mdwn
index a28e35a..9c8f1b5 100644
--- a/doc/bugs/windows_start_menu_shortcuts_are_missing___34__Start_in__34___parameter.mdwn
+++ b/doc/bugs/windows_start_menu_shortcuts_are_missing___34__Start_in__34___parameter.mdwn
@@ -12,4 +12,4 @@ git version 1.9.5.msysgit.1. git-annex version: 5.20150317-g237d5b0. Windows 7 P
 This seems to be fixed by editing the shortcuts and setting the "Start in" parameter to the git installation directory. For me this is "C:\Program Files (x86)\Git".
 
 > I've renamed it. The old git-annex.lnk will be
-> deleted by the installer if it exists.
+> deleted by the installer if it exists. [[done]] --[[Joey]]

comment
diff --git a/doc/bugs/fsck_reports_unsolvable_problem/comment_1_2beb21b685cea7402ffbf84d247c30b2._comment b/doc/bugs/fsck_reports_unsolvable_problem/comment_1_2beb21b685cea7402ffbf84d247c30b2._comment
new file mode 100644
index 0000000..e43ed96
--- /dev/null
+++ b/doc/bugs/fsck_reports_unsolvable_problem/comment_1_2beb21b685cea7402ffbf84d247c30b2._comment
@@ -0,0 +1,51 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-04-14T16:57:15Z"
+ content="""
+case 1
+
+1. git annex add file
+2. git annex drop --force file
+3. git rm file
+4. git commit -m nochange
+
+case 2
+
+1. git annex add file
+2. git commit -m added
+3. git annex drop --force file
+4. git rm file
+5. git commit -m removed
+
+fsck --all, or fsck in a bare repo, will repport the same problem in either
+case; the only difference being that in the latter case you can see that
+the master branch's history (or some user branch) did once include the lost
+file. In the former case, only the git-annex branch ever had a commit made
+about the lost file.
+
+The only way to remove this message would be either remove the log file
+from the git-annex branch, or teach fsck to ignore it. 
+
+Due to union merge it's not as simple as deleting the log file. A `git
+annex forget` type transition is needed to avoid merging the log file back in
+from elsewhere. It's certianly doable using the transition infrastructure.
+
+Or, fsck could have its own blacklist of known problems to not warn about.
+in some ways that's more complex; in others it's perhaps simpler since it
+avoids the complexity needed to handle transitions. (forced pushing, branch
+rewriting on merge, etc)
+
+Either way, I think the question is what UI to use to identify these keys.
+Seems like the user would have to examine their repos's history and
+understand whether they've hit case 1, or case 2, vs when a file they
+really wanted to have available in the history has actually been lost.
+Fsck could give some guidance, but not a whole lot. Note that if the user
+goofs up, they coud end up in a situation that's rather more a mess than
+this one!
+
+(I've seen maybe half a dozen people reporting this problem before. I think
+most or all of them were using fsck in a bare repository. It might be that,
+if fsck in a bare repository didn't behave as fsck --all, nobody would
+care.)
+"""]]

bittorrent: Fix handling of magnet links.
diff --git a/Remote/BitTorrent.hs b/Remote/BitTorrent.hs
index 2770f30..baba2e2 100644
--- a/Remote/BitTorrent.hs
+++ b/Remote/BitTorrent.hs
@@ -212,7 +212,7 @@ downloadTorrentFile u = do
 downloadMagnetLink :: URLString -> FilePath -> FilePath -> Annex Bool
 downloadMagnetLink u metadir dest = ifM download
 	( liftIO $ do
-		ts <- filter (".torrent" `isPrefixOf`)
+		ts <- filter (".torrent" `isSuffixOf`)
 			<$> dirContents metadir
 		case ts of
 			(t:[]) -> do
diff --git a/debian/changelog b/debian/changelog
index f1be1fd..3ff3c9a 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -9,6 +9,7 @@ git-annex (5.20150410) UNRELEASED; urgency=medium
   * info: Added --bytes option.
   * Windows: Renamed start menu file to avoid loop in some versions
     of Windows where the menu file is treated as a git-annex program.
+  * bittorrent: Fix handling of magnet links.
 
  -- Joey Hess <id@joeyh.name>  Thu, 09 Apr 2015 20:59:43 -0400
 
diff --git a/doc/bugs/addurl_magnet_could_not_download_torrent_file.mdwn b/doc/bugs/addurl_magnet_could_not_download_torrent_file.mdwn
index 855f2cf..f00a63a 100644
--- a/doc/bugs/addurl_magnet_could_not_download_torrent_file.mdwn
+++ b/doc/bugs/addurl_magnet_could_not_download_torrent_file.mdwn
@@ -43,3 +43,7 @@ failed
 git-annex: addurl: 1 failed
 
 """]]
+
+> Looking at the code, it was looking for a file prefixed by ".torrent",
+> but of course that should be suffixed instead. So, [[fixed|done]]
+> --[[Joey]]

Added a comment
diff --git a/doc/forum/__34__git_annex_sync__34___synced_after_8_hours/comment_1_e815ac48a17cc4296473d61e712d95e0._comment b/doc/forum/__34__git_annex_sync__34___synced_after_8_hours/comment_1_e815ac48a17cc4296473d61e712d95e0._comment
new file mode 100644
index 0000000..4cc665e
--- /dev/null
+++ b/doc/forum/__34__git_annex_sync__34___synced_after_8_hours/comment_1_e815ac48a17cc4296473d61e712d95e0._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="CandyAngel"
+ subject="comment 1"
+ date="2015-04-14T08:40:33Z"
+ content="""
+If you want a file count:
+
+    git annex find | wc -l
+
+is probably the best measure.
+
+I have an annex with about several million files in it and it is slow, but not as slow as you are describing. Have you done a repack/gc cycle?
+"""]]

diff --git a/doc/forum/__34__git_annex_sync__34___synced_after_8_hours.mdwn b/doc/forum/__34__git_annex_sync__34___synced_after_8_hours.mdwn
new file mode 100644
index 0000000..2804828
--- /dev/null
+++ b/doc/forum/__34__git_annex_sync__34___synced_after_8_hours.mdwn
@@ -0,0 +1,40 @@
+Hi,
+
+The git annex seem has problem with many files.
+
+For synchronize, the operation lasts 8 hours. Here the sample for synchronizing to my local remote server (sbackup)
+
+start at **20:12** / end at **04:13** / total time = ~ **8 hours**
+
+    git annex sync sbackup
+    
+    [2015-04-13 20:12:26 CEST] call: git ["--git-dir=.git","--work-tree=.","push","sbackup","+git-annex:synced/git-annex","master:synced/master"]
+    Counting objects: 792155, done.
+    Delta compression using up to 4 threads.
+    Compressing objects: 100% (789727/789727), done.
+    Writing objects: 100% (792155/792155), 75.73 MiB | 2.35 MiB/s, done.
+    Total 792155 (delta 449604), reused 1 (delta 0)
+    To partage@192.168.253.53:/data/samba/git-annex/docshare
+      ae182f0..fad3aca  git-annex -> synced/git-annex
+      e0e67fe..5226a6f  master -> synced/master
+    [2015-04-14 04:13:05 CEST] read: git ["--git-dir=.git","--work-tree=.","push","sbackup","git-annex","master"]
+    ok
+
+Another problem, I do not know exactly how many files I own (i use **find . | wc -l** )
+
+.git = 1250633
+
+documents = 61124
+
+medias = 199504
+
+it seem i own ~250000 files, but in the .git **1.2 millions files**.
+
+The following command also very slow
+
+    git annex info
+
+
+What the best pratices for use git annex with many files > 500 000 or maintenance & reduction/cleaning method
+
+Thanks

Windows: Renamed start menu file to avoid loop in some versions of Windows where the menu file is treated as a git-annex program.
diff --git a/Build/NullSoftInstaller.hs b/Build/NullSoftInstaller.hs
index 846c8d6..42260bd 100644
--- a/Build/NullSoftInstaller.hs
+++ b/Build/NullSoftInstaller.hs
@@ -85,8 +85,14 @@ uninstaller = "git-annex-uninstall.exe"
 gitInstallDir :: Exp FilePath
 gitInstallDir = fromString "$PROGRAMFILES\\Git"
 
+-- This intentionall has a different name than git-annex or
+-- git-annex-webapp, since it is itself treated as an executable file.
+-- Also, on XP, the filename is displayed, not the description.
 startMenuItem :: Exp FilePath
-startMenuItem = "$SMPROGRAMS/git-annex.lnk"
+startMenuItem = "$SMPROGRAMS/Git Annex (Webapp).lnk"
+
+oldStartMenuItem :: Exp FilePath
+oldStartMenuItem = "$SMPROGRAMS/git-annex.lnk"
 
 autoStartItem :: Exp FilePath
 autoStartItem = "$SMSTARTUP/git-annex-autostart.lnk"
@@ -125,8 +131,9 @@ makeInstaller gitannex license htmlhelp extrabins launchers = nsis $ do
 		, StartOptions "SW_SHOWNORMAL"
 		, IconFile "$INSTDIR/cmd/git-annex.exe"
 		, IconIndex 2
-		, Description "git-annex webapp"
+		, Description "Git Annex (Webapp)"
 		]
+	delete [RebootOK] $ oldStartMenuItem
 	createShortcut autoStartItem
 		[ Target "wscript.exe"
 		, Parameters "\"$INSTDIR/git-annex-autostart.vbs\""
diff --git a/debian/changelog b/debian/changelog
index 79f3c47..f1be1fd 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -7,6 +7,8 @@ git-annex (5.20150410) UNRELEASED; urgency=medium
   * info dir: Added information about repositories that
     contain files in the specified directory.
   * info: Added --bytes option.
+  * Windows: Renamed start menu file to avoid loop in some versions
+    of Windows where the menu file is treated as a git-annex program.
 
  -- Joey Hess <id@joeyh.name>  Thu, 09 Apr 2015 20:59:43 -0400
 
diff --git a/doc/bugs/windows_start_menu_shortcuts_are_missing___34__Start_in__34___parameter.mdwn b/doc/bugs/windows_start_menu_shortcuts_are_missing___34__Start_in__34___parameter.mdwn
index 72f0794..a28e35a 100644
--- a/doc/bugs/windows_start_menu_shortcuts_are_missing___34__Start_in__34___parameter.mdwn
+++ b/doc/bugs/windows_start_menu_shortcuts_are_missing___34__Start_in__34___parameter.mdwn
@@ -10,3 +10,6 @@ git version 1.9.5.msysgit.1. git-annex version: 5.20150317-g237d5b0. Windows 7 P
 ### Please provide any additional information below.
 
 This seems to be fixed by editing the shortcuts and setting the "Start in" parameter to the git installation directory. For me this is "C:\Program Files (x86)\Git".
+
+> I've renamed it. The old git-annex.lnk will be
+> deleted by the installer if it exists.

Added a comment
diff --git a/doc/forum/Slow_transfer_speeds_on_copy_in_Windows/comment_3_c169ad6205c998f3d44f9c0859071b2d._comment b/doc/forum/Slow_transfer_speeds_on_copy_in_Windows/comment_3_c169ad6205c998f3d44f9c0859071b2d._comment
new file mode 100644
index 0000000..13a8541
--- /dev/null
+++ b/doc/forum/Slow_transfer_speeds_on_copy_in_Windows/comment_3_c169ad6205c998f3d44f9c0859071b2d._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlh1G1u_AMJEyADqlfuzV2cePniocDyK6A"
+ nickname="Adam"
+ subject="comment 3"
+ date="2015-04-13T17:23:15Z"
+ content="""
+Verified to be rsync 3.0.9 that is bundled with git annex which is causing the slowdown. Updated to cwRsync 3.1.1 and it was fast again.
+"""]]

removed
diff --git a/doc/forum/Slow_transfer_speeds_on_copy_in_Windows/comment_3_884863320328be9c7e26219e453337c8._comment b/doc/forum/Slow_transfer_speeds_on_copy_in_Windows/comment_3_884863320328be9c7e26219e453337c8._comment
deleted file mode 100644
index 7338fdc..0000000
--- a/doc/forum/Slow_transfer_speeds_on_copy_in_Windows/comment_3_884863320328be9c7e26219e453337c8._comment
+++ /dev/null
@@ -1,8 +0,0 @@
-[[!comment format=mdwn
- username="https://www.google.com/accounts/o8/id?id=AItOawlh1G1u_AMJEyADqlfuzV2cePniocDyK6A"
- nickname="Adam"
- subject="comment 3"
- date="2015-04-13T16:39:15Z"
- content="""
-Verified to be rsync 3.0.9 that is bundled with git annex which is causing the slowdown.  Updated to cwRsync 3.1.1 and it was fast again.  Problems with my environment, however, made this solution less than optimal.  The ssh that is bundled with cwRsync caused it to look at the wrong location for my home dir.  So, my ssh keys/authorized_keys no longer work.  It seems it doesn't honor $HOME.  There are also two ssh's now after git annex installation, one in the cmd folder and one in the bin folder.  It seems to prefer bin when using the git terminal.  
-"""]]

Added a comment
diff --git a/doc/forum/Slow_transfer_speeds_on_copy_in_Windows/comment_3_884863320328be9c7e26219e453337c8._comment b/doc/forum/Slow_transfer_speeds_on_copy_in_Windows/comment_3_884863320328be9c7e26219e453337c8._comment
new file mode 100644
index 0000000..7338fdc
--- /dev/null
+++ b/doc/forum/Slow_transfer_speeds_on_copy_in_Windows/comment_3_884863320328be9c7e26219e453337c8._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlh1G1u_AMJEyADqlfuzV2cePniocDyK6A"
+ nickname="Adam"
+ subject="comment 3"
+ date="2015-04-13T16:39:15Z"
+ content="""
+Verified to be rsync 3.0.9 that is bundled with git annex which is causing the slowdown.  Updated to cwRsync 3.1.1 and it was fast again.  Problems with my environment, however, made this solution less than optimal.  The ssh that is bundled with cwRsync caused it to look at the wrong location for my home dir.  So, my ssh keys/authorized_keys no longer work.  It seems it doesn't honor $HOME.  There are also two ssh's now after git annex installation, one in the cmd folder and one in the bin folder.  It seems to prefer bin when using the git terminal.  
+"""]]

diff --git a/doc/bugs/addurl_magnet_could_not_download_torrent_file.mdwn b/doc/bugs/addurl_magnet_could_not_download_torrent_file.mdwn
new file mode 100644
index 0000000..855f2cf
--- /dev/null
+++ b/doc/bugs/addurl_magnet_could_not_download_torrent_file.mdwn
@@ -0,0 +1,45 @@
+### Please describe the problem.
+
+Every time I try to `addurl` with `magnet:` I get this error message:
+
+	could not download torrent file
+
+### What steps will reproduce the problem?
+
+	git-annex addurl "magnet:?xt=urn:btih:b548b3b8efce813d71c9355832b4382680b8abf9"
+
+### What version of git-annex are you using? On what operating system?
+
+* git-annex 5.20150409
+* ubuntu 14.04 x64
+
+### Please provide any additional information below.
+
+[[!format sh """
+
+git-annex addurl magnet:?xt=urn:btih:b548b3b8efce813d71c9355832b4382680b8abf9
+(downloading torrent file...) 
+
+04/13 17:16:15 [NOTICE] IPv4 DHT: listening on UDP port 6930
+
+04/13 17:16:15 [NOTICE] IPv4 BitTorrent: listening on TCP port 6890
+
+04/13 17:16:15 [NOTICE] IPv6 BitTorrent: listening on TCP port 6890
+[#3e3bb9 74KiB/74KiB(100%) CN:13 SD:1]                                         
+04/13 17:16:33 [NOTICE] Download complete: [METADATA]b548b3b8efce813d71c9355832b4382680b8abf9
+
+04/13 17:16:33 [NOTICE] Saved metadata as ../.git/annex/misctmp/URL--magnet&c,63xt,61urn&cbtih&cb548b3b8efce813d71c9355832b4382680b8abf9/meta/b548b3b8efce813d71c9355832b4382680b8abf9.torrent.
+	                                                                       
+Download Results:
+gid   |stat|avg speed  |path/URI
+======+====+===========+=======================================================
+3e3bb9|OK  |       0B/s|[MEMORY][METADATA]b548b3b8efce813d71c9355832b4382680b8abf9
+
+Status Legend:
+(OK):download completed.
+addurl magnet:?xt=urn:btih:b548b3b8efce813d71c9355832b4382680b8abf9 
+  could not download torrent file
+failed
+git-annex: addurl: 1 failed
+
+"""]]

diff --git a/doc/todo/addurl___8211__force-torrent_option.mdwn b/doc/todo/addurl___8211__force-torrent_option.mdwn
new file mode 100644
index 0000000..acbb953
--- /dev/null
+++ b/doc/todo/addurl___8211__force-torrent_option.mdwn
@@ -0,0 +1 @@
+There are sites that don't provide direct links to `.torrent` files. Currently there is no way to download contents of such torrents with `git annex`, it simply uses web remote instead of bittorrent.  Something like `--force-torrent` option could help here.

Added a comment
diff --git a/doc/forum/Slow_transfer_speeds_on_copy_in_Windows/comment_2_9ebd40fe286f6c13f1021bf360e9c48e._comment b/doc/forum/Slow_transfer_speeds_on_copy_in_Windows/comment_2_9ebd40fe286f6c13f1021bf360e9c48e._comment
new file mode 100644
index 0000000..9ad9acb
--- /dev/null
+++ b/doc/forum/Slow_transfer_speeds_on_copy_in_Windows/comment_2_9ebd40fe286f6c13f1021bf360e9c48e._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlh1G1u_AMJEyADqlfuzV2cePniocDyK6A"
+ nickname="Adam"
+ subject="comment 2"
+ date="2015-04-13T14:21:12Z"
+ content="""
+rsync is indeed slow...  The version bundled with msysgit is being used, and I read it has performance issues.  Will try a different version of rsync, perhaps in cygwin.
+"""]]

diff --git a/doc/bugs/fsck_reports_unsolvable_problem.mdwn b/doc/bugs/fsck_reports_unsolvable_problem.mdwn
new file mode 100644
index 0000000..660bb19
--- /dev/null
+++ b/doc/bugs/fsck_reports_unsolvable_problem.mdwn
@@ -0,0 +1,18 @@
+### Please describe the problem.
+
+On my bare git-annex repo, `git annex fsck -q` reports:
+
+    ** No known copies exist of SHA256E-s1212237--d2edd369f6a9005e23f022c7d797b166c66b90defc561329dbafab9a0fc0c7fc.jpg
+
+`git log -SSA256E...` returns nothing. `git annex repair` and `git annex forget` do not fix the problem.
+
+This means that running `fsck` from cron or a script will now always fail. There should be a way to recover from this situation.
+
+### What steps will reproduce the problem?
+
+According to IRC this "can happen if you annexed a file and then deleted it without ever committing to git".
+
+
+### What version of git-annex are you using? On what operating system?
+
+5.20140717 from Ubuntu utopic

diff --git a/doc/todo/wishlist:_rsync_efficiency.mdwn b/doc/todo/wishlist:_rsync_efficiency.mdwn
new file mode 100644
index 0000000..fe1848f
--- /dev/null
+++ b/doc/todo/wishlist:_rsync_efficiency.mdwn
@@ -0,0 +1,8 @@
+If you look at the transfer rates during a copy job to remotes, you see it going down to zero for a short time between files.
+
+While that's understandable from rsync's PoV, it's not as efficient as git-annex could be.
+
+Would parallelization be an option? Are there alternate improvements?
+
+
+-- Richard

Added a comment
diff --git a/doc/forum/ga-ncdu/comment_3_c5ce3b663de76b50754de70b3fb23bf0._comment b/doc/forum/ga-ncdu/comment_3_c5ce3b663de76b50754de70b3fb23bf0._comment
new file mode 100644
index 0000000..318441e
--- /dev/null
+++ b/doc/forum/ga-ncdu/comment_3_c5ce3b663de76b50754de70b3fb23bf0._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="CandyAngel"
+ subject="comment 3"
+ date="2015-04-12T22:12:53Z"
+ content="""
+Whelp, didn't realise it had been over two weeks! Got caught up in other stuff (VR).
+
+[Here's the bitbucket repository!](https://bitbucket.org/CandyAngel/ga-ncdu)
+
+I've coded my own JSON output so it doesn't depend on any non-core Perl modules.
+
+Please let me know of any bugs, feature requests etc. Feedback would be appreciated, even just letting me know you are using it would be great!
+
+    ga-ncdu.pl ~/mah_annex | ncdu -f-
+"""]]

info: Added --bytes option.
diff --git a/Command/Info.hs b/Command/Info.hs
index cf28c85..b7cb323 100644
--- a/Command/Info.hs
+++ b/Command/Info.hs
@@ -77,7 +77,7 @@ emptyStatInfo = StatInfo Nothing Nothing M.empty Nothing
 type StatState = StateT StatInfo Annex
 
 cmd :: [Command]
-cmd = [noCommit $ dontCheck repoExists $ withOptions (jsonOption : annexedMatchingOptions) $
+cmd = [noCommit $ dontCheck repoExists $ withOptions (jsonOption : bytesOption : annexedMatchingOptions) $
 	command "info" (paramOptional $ paramRepeating paramItem) seek SectionQuery
 	"shows information about the specified item or the repository as a whole"]
 
@@ -291,7 +291,7 @@ local_annex_keys = stat "local annex keys" $ json show $
 
 local_annex_size :: Stat
 local_annex_size = simpleStat "local annex size" $
-	showSizeKeys <$> cachedPresentData
+	lift . showSizeKeys =<< cachedPresentData
 
 remote_annex_keys :: UUID -> Stat
 remote_annex_keys u = stat "remote annex keys" $ json show $
@@ -299,7 +299,7 @@ remote_annex_keys u = stat "remote annex keys" $ json show $
 
 remote_annex_size :: UUID -> Stat
 remote_annex_size u = simpleStat "remote annex size" $
-	showSizeKeys <$> cachedRemoteData u
+	lift . showSizeKeys =<< cachedRemoteData u
 
 known_annex_files :: Stat
 known_annex_files = stat "annexed files in working tree" $ json show $
@@ -307,7 +307,7 @@ known_annex_files = stat "annexed files in working tree" $ json show $
 
 known_annex_size :: Stat
 known_annex_size = simpleStat "size of annexed files in working tree" $
-	showSizeKeys <$> cachedReferencedData
+	lift . showSizeKeys =<< cachedReferencedData
 
 tmp_size :: Stat
 tmp_size = staleSize "temporary object directory size" gitAnnexTmpObjectDir
@@ -316,7 +316,7 @@ bad_data_size :: Stat
 bad_data_size = staleSize "bad keys size" gitAnnexBadDir
 
 key_size :: Key -> Stat
-key_size k = simpleStat "size" $ pure $ showSizeKeys $ foldKeys [k]
+key_size k = simpleStat "size" $ lift $ showSizeKeys $ foldKeys [k]
 
 key_name :: Key -> Stat
 key_name k = simpleStat "key" $ pure $ key2file k
@@ -332,7 +332,8 @@ bloom_info = simpleStat "bloom filter size" $ do
 
 	-- Two bloom filters are used at the same time, so double the size
 	-- of one.
-	size <- roughSize memoryUnits False . (* 2) . fromIntegral . fst <$>
+	sizer <- lift mkSizer
+	size <- sizer memoryUnits False . (* 2) . fromIntegral . fst <$>
 		lift Command.Unused.bloomBitsHashes
 
 	return $ size ++ note
@@ -359,13 +360,14 @@ disk_size = simpleStat "available local disk space" $ lift $
 	calcfree
 		<$> (annexDiskReserve <$> Annex.getGitConfig)
 		<*> inRepo (getDiskFree . gitAnnexDir)
+		<*> mkSizer
   where
-	calcfree reserve (Just have) = unwords
-		[ roughSize storageUnits False $ nonneg $ have - reserve
-		, "(+" ++ roughSize storageUnits False reserve
+	calcfree reserve (Just have) sizer = unwords
+		[ sizer storageUnits False $ nonneg $ have - reserve
+		, "(+" ++ sizer storageUnits False reserve
 		, "reserved)"
 		]			
-	calcfree _ _ = "unknown"
+	calcfree _ _ _ = "unknown"
 
 	nonneg x
 		| x >= 0 = x
@@ -392,15 +394,18 @@ numcopies_stats = stat "numcopies stats" $ nojson $
 
 reposizes_stats :: Stat
 reposizes_stats = stat "repositories containing these files" $ nojson $
-	calc <$> lift uuidDescriptions <*> cachedRepoData
+	calc
+		<$> lift uuidDescriptions
+		<*> lift mkSizer
+		<*> cachedRepoData
   where
-	calc descm = multiLine
+	calc descm sizer = multiLine
 		. format
-		. map (\(u, d) -> line descm u d)
+		. map (\(u, d) -> line descm sizer u d)
 		. sortBy (flip (comparing (sizeKeys . snd))) . M.toList
-	line descm u d = (sz, fromUUID u ++ " -- " ++ desc)
+	line descm sizer u d = (sz, fromUUID u ++ " -- " ++ desc)
 	  where
-		sz = roughSize storageUnits True (sizeKeys d)
+		sz = sizer storageUnits True (sizeKeys d)
 		desc = fromMaybe "" (M.lookup u descm)
 	format l = map (\(c1, c2) -> lpad maxc1 c1 ++ ": " ++ c2 ) l
 	  where
@@ -510,10 +515,12 @@ updateNumCopiesStats file (NumCopiesStats m) locs = do
 	let !ret = NumCopiesStats m'
 	return ret
 
-showSizeKeys :: KeyData -> String
-showSizeKeys d = total ++ missingnote
+showSizeKeys :: KeyData -> Annex String
+showSizeKeys d = do
+	sizer <- mkSizer
+	return $ total sizer ++ missingnote
   where
-	total = roughSize storageUnits False $ sizeKeys d
+	total sizer = sizer storageUnits False $ sizeKeys d
 	missingnote
 		| unknownSizeKeys d == 0 = ""
 		| otherwise = aside $
@@ -527,8 +534,9 @@ staleSize label dirspec = go =<< lift (dirKeys dirspec)
 	go keys = onsize =<< sum <$> keysizes keys
 	onsize 0 = nostat
 	onsize size = stat label $
-		json (++ aside "clean up with git-annex unused") $
-			return $ roughSize storageUnits False size
+		json (++ aside "clean up with git-annex unused") $ do
+			sizer <- lift mkSizer
+			return $ sizer storageUnits False size
 	keysizes keys = do
 		dir <- lift $ fromRepo dirspec
 		liftIO $ forM keys $ \k -> catchDefaultIO 0 $
@@ -539,3 +547,12 @@ aside s = " (" ++ s ++ ")"
 
 multiLine :: [String] -> String
 multiLine = concatMap (\l -> "\n\t" ++ l)
+
+mkSizer :: Annex ([Unit] -> Bool -> ByteSize -> String)
+mkSizer = ifM (getOptionFlag bytesOption)
+	( return (const $ const show)
+	, return roughSize
+	)
+
+bytesOption :: Option
+bytesOption = flagOption [] "bytes" "display file sizes in bytes"
diff --git a/Utility/DataUnits.hs b/Utility/DataUnits.hs
index 2ece143..6e40932 100644
--- a/Utility/DataUnits.hs
+++ b/Utility/DataUnits.hs
@@ -42,6 +42,7 @@ module Utility.DataUnits (
 	bandwidthUnits,
 	oldSchoolUnits,
 	Unit(..),
+	ByteSize,
 
 	roughSize,
 	compareSizes,
diff --git a/debian/changelog b/debian/changelog
index 8a8c7be..79f3c47 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -6,6 +6,7 @@ git-annex (5.20150410) UNRELEASED; urgency=medium
     with the same name as a git ref. Now fixed.
   * info dir: Added information about repositories that
     contain files in the specified directory.
+  * info: Added --bytes option.
 
  -- Joey Hess <id@joeyh.name>  Thu, 09 Apr 2015 20:59:43 -0400
 
diff --git a/doc/git-annex-info.mdwn b/doc/git-annex-info.mdwn
index 52b145c..31c4227 100644
--- a/doc/git-annex-info.mdwn
+++ b/doc/git-annex-info.mdwn
@@ -26,6 +26,10 @@ for the repository as a whole.
   Enable JSON output. This is intended to be parsed by programs that use
   git-annex. Each line of output is a JSON object.
 
+* `--bytes`
+
+  Show file sizes in bytes, disabling the default nicer units.
+
 * file matching options
 
   When a directory is specified, the [[git-annex-matching-options]](1)

Added a comment: missed the comment
diff --git a/doc/todo/git-annex-standalone_Debian_package/comment_3_22539df11d1a514987b9c257fd8b1998._comment b/doc/todo/git-annex-standalone_Debian_package/comment_3_22539df11d1a514987b9c257fd8b1998._comment
new file mode 100644
index 0000000..7f0d1d5
--- /dev/null
+++ b/doc/todo/git-annex-standalone_Debian_package/comment_3_22539df11d1a514987b9c257fd8b1998._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnx8kHW66N3BqmkVpgtXDlYMvr8TJ5VvfY"
+ nickname="Yaroslav"
+ subject="missed the comment"
+ date="2015-04-12T13:55:50Z"
+ content="""
+blind me managed to miss your comment, for which I am thankful.  A branch sounded like the best way to go so I don't need to mess with patching BUT now thinking about it, I might just indeed move it into a new debian/patch/series-standalone  which would be the quilt series to use to patch things for building standalone.   Then it could be shipped in the main repo and applied only when necessary. Sounds good?
+"""]]

Added a comment: now available
diff --git a/doc/todo/git-annex-standalone_Debian_package/comment_2_456413718e9faf3561a11000ee611611._comment b/doc/todo/git-annex-standalone_Debian_package/comment_2_456413718e9faf3561a11000ee611611._comment
new file mode 100644
index 0000000..50a2bf5
--- /dev/null
+++ b/doc/todo/git-annex-standalone_Debian_package/comment_2_456413718e9faf3561a11000ee611611._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnx8kHW66N3BqmkVpgtXDlYMvr8TJ5VvfY"
+ nickname="Yaroslav"
+ subject="now available"
+ date="2015-04-12T13:49:04Z"
+ content="""
+from stock NeuroDebian repository across all debian/ubuntu releases.  Packaging is within debian-standalone branch of http://github.com/yarikoptic/git-annex
+
+So far -- built manually (well -- debian/build-standalone) on my laptop. Later will be automated on the buildbot.
+"""]]

started thread
diff --git a/doc/forum/Cant_see_git-annex-shell_via_SSH_in_OSX.mdwn b/doc/forum/Cant_see_git-annex-shell_via_SSH_in_OSX.mdwn
new file mode 100644
index 0000000..76b1d5a
--- /dev/null
+++ b/doc/forum/Cant_see_git-annex-shell_via_SSH_in_OSX.mdwn
@@ -0,0 +1,119 @@
+### Sync Problems using SSH remote in OSX
+
+- Im trying to work out SSH remotes by trying to sync up repos on my home network, following the walkthrough. 
+- I have two machines (mini and mbp ) running OSX Mavericks, with RLogin enabled for all users to enable ssh.
+- I can SSH into the remote machine and see *git-annex-shell*, which seems to have ok permissions
+
+```
+
+    johns-mbp:annex johnmccallum$ ssh john@johns-mini-5.home 
+    
+    Last login: Sun Apr 12 07:31:07 2015 from johns-mbp.home
+
+    johns-mini-5:~ john$ which git-annex-shell
+
+    /usr/local/bin/git-annex-shell
+
+    johns-mini-5:~ john$ ls -l /usr/local/bin/git-annex-shell
+
+    -rwxr-xr-x@ 1 john  admin  668 12 Apr 07:03 /usr/local/bin/git-annex-shell
+
+```
+
+- Previously on mini I created and populated a repo
+
+``` 
+
+    494  mkdir annex
+
+    495  cd annex
+
+    496  git init
+
+    497  git annex init
+
+    498  cp ~/Pictures/*.png .
+
+    499  git annex add .
+
+    500  git commit -a -m 'added png'
+
+```
+
+- I can git clone this repo to MBP by SSH
+
+
+```
+	johns-mbp:~ johnmccallum$ git clone ssh://john@johns-mini-5.home/Users/john/annex ~/annex
+
+	Cloning into '/Users/johnmccallum/annex'...
+
+	remote: Counting objects: 24, done.
+
+	remote: Compressing objects: 100% (19/19), done.
+
+	remote: Total 24 (delta 3), reused 0 (delta 0)
+
+	Receiving objects: 100% (24/24), done.
+
+	Resolving deltas: 100% (3/3), done.
+
+	Checking connectivity... done
+
+	johns-mbp:~ johnmccallum$ cd annex
+
+	johns-mbp:annex johnmccallum$ git annex init 'MBP'
+
+	init MBP (merging origin/git-annex into git-annex...)
+
+	(recording state in git...)
+
+	ok
+
+	(recording state in git...)
+
+	johns-mbp:annex johnmccallum$ ls -l
+
+	total 16
+
+	lrwxr-xr-x  1 johnmccallum  staff  196 12 Apr 08:20 CoGe-Snapshot at 2013-03-22 - 11-27-20.png -> .git/annex/objects/gf/Xp/SHA256E-s367697--	fce3f47f218805cd9855ec3fd4203b52e83587148b34c8e706df512783eb7557.png/SHA256E-s367697--fce3f47f218805cd9855ec3fd4203b52e83587148b34c8e706df512783eb7557.png
+
+	lrwxr-xr-x  1 johnmccallum  staff  196 12 Apr 08:20 delicious.png -> .git/annex/objects/ZJ/vX/SHA256E-s112714--057d0faa464f8d588c053dae460838d68ea7803d7eaf7330798679e63f92cecb.png/SHA256E-s112714--057d0faa464f8d588c053dae460838d68ea7803d7eaf7330798679e63f92cecb.png
+
+
+```
+
+ **HOWEVER**   _git annex get_  fails as follows:
+
+```
+
+	johns-mbp:annex johnmccallum$ git annex get delicious.png 
+
+	get delicious.png bash: git-annex-shell: command not found
+
+ 	 Remote origin does not have git-annex installed; setting annex-ignore
+
+ 	 This could be a problem with the git-annex installation on the remote. Please make sure that git-annex-shell is available in PATH when you ssh into the remote. Once you have fixed the git-annex installation, run: git config remote.origin.annex-ignore false
+	(not available) 
+ 	 Try making some of these repositories available:
+  		129620b2-91b1-4541-b7b1-9e5a9d31d5d3 -- john@johns-mini-5.home:~/annex
+	failed
+	git-annex: get: 1 failed
+
+```
+
+This is not the case on the remote host when I SSH in as the same user
+
+```
+
+    johns-mini-5:~ john$ which git-annex-shell
+
+
+    /usr/local/bin/git-annex-shell
+
+```
+
+
+ The only thread on this seems to be https://git-annex.branchable.com/forum/not_finding_git-annex-shell_on_remote/ and Im at a loss to understand it.  
+
+Any suggestions would be welcome

response
diff --git a/doc/devblog/day_274__concurrent_annex_state/comment_2_4ca498ee4b4aaac8ee6dbc2c769dbad7._comment b/doc/devblog/day_274__concurrent_annex_state/comment_2_4ca498ee4b4aaac8ee6dbc2c769dbad7._comment
new file mode 100644
index 0000000..e8629e5
--- /dev/null
+++ b/doc/devblog/day_274__concurrent_annex_state/comment_2_4ca498ee4b4aaac8ee6dbc2c769dbad7._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2015-04-11T14:41:47Z"
+ content="""
+Josh Tripplet has some haskell bindings for libgit2 somewhere.
+My reasons for not using it so far include:
+
+* ABI stability; at least it used to have none. soname is 21 already..
+* Josh told me parts of it are much less optimised than git.
+  (This was several years ago, but I still imagine the git code base
+  has much more work on speed.)
+* It's not even been in a stable release of Debian yet.
+* Adding a C library dependency will make git-annex much harder for
+  users to get started building.
+* The couple of things that I could really use a git library for, like
+  index file access and catting object contents, could be implemented
+  just as well (and likely as fast) in pure haskell
+  code, and would not be particularly hard to do either. There may even
+  be suitable pure haskell libraries for them; haven't checked.
+"""]]

doc/git-annex-{expire,fromkey}.mdwn: Fix a couple of typos
diff --git a/doc/git-annex-expire.mdwn b/doc/git-annex-expire.mdwn
index ce07d79..8629036 100644
--- a/doc/git-annex-expire.mdwn
+++ b/doc/git-annex-expire.mdwn
@@ -32,7 +32,7 @@ expired.
 
 * `--no-act`
 
-  Print out what would be done, but not not actually expite or unexpire
+  Print out what would be done, but not not actually expire or unexpire
   any repositories.
 
 * `--activity=Name`
diff --git a/doc/git-annex-fromkey.mdwn b/doc/git-annex-fromkey.mdwn
index 9569c42..1126e82 100644
--- a/doc/git-annex-fromkey.mdwn
+++ b/doc/git-annex-fromkey.mdwn
@@ -13,7 +13,7 @@ in the git repository to link to a specified key.
 
 If the key and file are not specified on the command line, they are
 instead read from stdin. Any number of lines can be provided in this
-mode, each containing a key and filename, sepearated by a single space.
+mode, each containing a key and filename, separated by a single space.
 
 # OPTIONS
 

review
diff --git a/doc/todo/git-annex-standalone_Debian_package/comment_1_ef36b0265127611ffeea3a5ed8c29515._comment b/doc/todo/git-annex-standalone_Debian_package/comment_1_ef36b0265127611ffeea3a5ed8c29515._comment
new file mode 100644
index 0000000..ad3f8b9
--- /dev/null
+++ b/doc/todo/git-annex-standalone_Debian_package/comment_1_ef36b0265127611ffeea3a5ed8c29515._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-04-11T13:52:28Z"
+ content="""
+I think this will work. I don't see a way to do it other than as a patch
+to debian/ though.. Unless perhaps you could pass flags to stuff to make
+a different directory be used. If you could do that, it could be included
+in git-annex's master.
+
+The package needs to depend on git (any version) so that the user can run
+"git annex".
+
+The rest of the depends are not necessary though. The standalone tarball
+includes its own wget, rsync, gpg, curl, and ssh, so git-annex will be able
+to use those.
+
+If removing eg, the depends on wget though, you will want to add a
+recommends on ca-certificates..
+"""]]

diff --git a/doc/todo/git-annex-standalone_Debian_package.mdwn b/doc/todo/git-annex-standalone_Debian_package.mdwn
new file mode 100644
index 0000000..0172e1e
--- /dev/null
+++ b/doc/todo/git-annex-standalone_Debian_package.mdwn
@@ -0,0 +1 @@
+As proposed with a sketch in https://github.com/joeyh/git-annex/pull/39, for DataLad we would need to get recent annex on older Debian/Ubuntu releases to get our testing farm and perspective users equipped with bleeding edge annex

Added a comment
diff --git a/doc/devblog/day_274__concurrent_annex_state/comment_1_7414fc0dde7a1d1ee456f8eba0b0c2a9._comment b/doc/devblog/day_274__concurrent_annex_state/comment_1_7414fc0dde7a1d1ee456f8eba0b0c2a9._comment
new file mode 100644
index 0000000..b4e2eee
--- /dev/null
+++ b/doc/devblog/day_274__concurrent_annex_state/comment_1_7414fc0dde7a1d1ee456f8eba0b0c2a9._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="https://id.koumbit.net/anarcat"
+ subject="comment 1"
+ date="2015-04-10T21:33:02Z"
+ content="""
+great news!
+
+one thing i've been wondering after fooling around with the git-annex branch outside of git-annex is why git-annex talks with the commandline git client at all? libgit, for example, seem to access the .git objects directly without a dependency on the git commandline... there doesn't seem to be any haskell shims for libgit, but it seems to me it would reduce the overhead of a bunch of stuff in git-annex...
+
+as an aside, any thoughts of making the [git-annex-specific git library](http://source.git-annex.branchable.com/?p=source.git;a=tree;f=Git;hb=HEAD) portable and standalone? maybe in collaboration with the existing [hs-libgit](https://hackage.haskell.org/package/libgit)?
+"""]]

devblog
diff --git a/doc/devblog/day_274__concurrent_annex_state.mdwn b/doc/devblog/day_274__concurrent_annex_state.mdwn
new file mode 100644
index 0000000..3aa73c0
--- /dev/null
+++ b/doc/devblog/day_274__concurrent_annex_state.mdwn
@@ -0,0 +1,42 @@
+Back working on `git annex get --jobs=N` today. It was going very well,
+until I realized I had a hard problem on my hands.
+
+The hard problem is that the AnnexState structure at the core of git-annex
+is not able to be shared amoung multiple threads at all. There's too much
+complicated mutable state going on in there for that to be feasible at all.
+
+In the git-annex assistant, which uses many threads, I long ago worked
+around this problem, by having a single shared AnnexState and when a thread
+needs to run an Annex action, it blocks until no other thread is using it.
+This worked ok for the assistant, with a little bit of thought to avoid
+long-duration Annex actions that could stall the rest of it.
+
+That won't work for concurrent `get` etc. I spent a while investigating maybe
+making AnnexState thread safe, but it's just not built for it. Too many
+ways that can go wrong. For example, there's a CatFileHandle in the
+AnnexState. If two threads are running, they can both try to talk to the
+same `git cat-file --batch` command at once, with bad results. Worse, yet,
+some parts of the code do things like modifying the AnnexState's Git repo
+to add environment variables to use when running git commands.
+
+It's not all gloom and doom though. Only very isolated parts of the code
+change the working directory or set environment variables. And the
+assistant has surely smoked out other thread concurrency problems already.
+And, separate `git-annex` programs can be run concurrently with no problems
+at all; it uses file locking to avoid different processes getting in
+each-others' way. So AnnexState is the only remaining obstacle to concurrency.
+
+So, here's how I've worked around it: When `git annex get -J10` is run,
+it will start by allocating 10 job slots. A fresh AnnexState will be
+created, and copied into each slot. Each time a job runs, it uses its
+slot's own AnnexState. This means 10 `git cat-file` processes,
+and maybe some contention over lock files, but generally, a nice, easy,
+and hopefully trouble-free multithreaded mode.
+
+And indeed, I've gotten `git annex get -J10` working robustly!
+And from there it was trivial to enable -J for `move` and `copy` and `mirror`
+too!
+
+The only real blocker to merging the concurrentprogress branch is some bugs
+in the ascii-progress library that make it draw very scrambled progress
+bars the way git-annex uses it.

Added a comment
diff --git a/doc/bugs/windows_start_menu_shortcuts_are_missing___34__Start_in__34___parameter/comment_4_7bec797548ff4ea270b96f9c0aada62c._comment b/doc/bugs/windows_start_menu_shortcuts_are_missing___34__Start_in__34___parameter/comment_4_7bec797548ff4ea270b96f9c0aada62c._comment
new file mode 100644
index 0000000..1b9a4dc
--- /dev/null
+++ b/doc/bugs/windows_start_menu_shortcuts_are_missing___34__Start_in__34___parameter/comment_4_7bec797548ff4ea270b96f9c0aada62c._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://launchpad.net/~eliasson"
+ nickname="eliasson"
+ subject="comment 4"
+ date="2015-04-10T15:35:30Z"
+ content="""
+Perhaps both? Changing the VBscript for existing users, and renaming the link as a more long term solution for new installations.
+
+I would argue that testing with newer Windows versions than XP is somewhat important. If you need money for a Windows license you could always launch another crowdfunding campaign...
+"""]]

Added a comment
diff --git a/doc/forum/Adding_a_mounted_network/comment_3_559cfec9210f8c86de6ee13de0ec2175._comment b/doc/forum/Adding_a_mounted_network/comment_3_559cfec9210f8c86de6ee13de0ec2175._comment
new file mode 100644
index 0000000..b45f741
--- /dev/null
+++ b/doc/forum/Adding_a_mounted_network/comment_3_559cfec9210f8c86de6ee13de0ec2175._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="http://lhealy.livejournal.com/"
+ subject="comment 3"
+ date="2015-04-10T15:35:16Z"
+ content="""
+Thanks for both these answers. For the first, one does the repository have to be made first? I.e., do a `git init --bare` first? I discovered the second approach before reading the comment and it worked, but it did not make a bare repository as happens with the \"removable drive\" option in the assistant.
+"""]]

comment
diff --git a/doc/bugs/windows_start_menu_shortcuts_are_missing___34__Start_in__34___parameter/comment_3_6c3e6b1344c533857611c0f6033c0dce._comment b/doc/bugs/windows_start_menu_shortcuts_are_missing___34__Start_in__34___parameter/comment_3_6c3e6b1344c533857611c0f6033c0dce._comment
new file mode 100644
index 0000000..77472dc
--- /dev/null
+++ b/doc/bugs/windows_start_menu_shortcuts_are_missing___34__Start_in__34___parameter/comment_3_6c3e6b1344c533857611c0f6033c0dce._comment
@@ -0,0 +1,25 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2015-04-09T20:53:17Z"
+ content="""
+I'm guessing this doesn't affect XP, so I'm going to need to rely on you
+guys for help and testing for the newer Windows..
+
+Makes sense about git-annex.lnk trying to run itself, I suppose. Sort of.
+
+The DSL I'm using to generate the NSIS installer and thus this file
+doesn't currently seem to have a way to set the "Start in" parameter.
+I can get that added, but it would take a while.
+
+I don't see any reason not to use the "git annex webapp" approach.
+Should be the same as long as git's in path, and if git's not in path,
+well.
+
+Alternatively, though, I could rename the menu item to something else, like
+"git-annex-menu.lnk". Seems that would also avoid the problem, and somewhat
+more robustly. I don't like this business of conflicting command-names
+being in path. Renaming the menu item has the downside of needing a
+uninstall/reinstall cycle to avoid getting a duplicate menu item, but
+otherwise seems reasonable.
+"""]]

Added a comment
diff --git a/doc/bugs/windows_start_menu_shortcuts_are_missing___34__Start_in__34___parameter/comment_2_f68896dee17aa663749912e663f10a9f._comment b/doc/bugs/windows_start_menu_shortcuts_are_missing___34__Start_in__34___parameter/comment_2_f68896dee17aa663749912e663f10a9f._comment
new file mode 100644
index 0000000..070fbdb
--- /dev/null
+++ b/doc/bugs/windows_start_menu_shortcuts_are_missing___34__Start_in__34___parameter/comment_2_f68896dee17aa663749912e663f10a9f._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="https://launchpad.net/~eliasson"
+ nickname="eliasson"
+ subject="comment 2"
+ date="2015-04-09T20:43:08Z"
+ content="""
+Yes, Git is in my path. This is my full (system, not user) path, copied from System Properties->Advanced->Environment Variables:
+
+    C:\ProgramData\Oracle\Java\javapath;%SystemRoot%\system32;%SystemRoot%;%SystemRoot%\System32\Wbem;%SYSTEMROOT%\System32\WindowsPowerShell\v1.0\;C:\Program Files (x86)\QuickTime\QTSystem\;C:\Program Files (x86)\Git\cmd
+
+I've done some more experimentation now. I believe that in Windows the current working directory is always first in the path. I also think that \"Start in\" sets the CWD of a shortcut and if unset, its CWD is its location in the Start menu. The shortcut is named git-annex.lnk and executes a VBscript that runs \"git-annex webapp\". This is probably why the shortcut executes itself.
+
+Setting the Start in parameter to anything (doesn't have to be Git's installation directory) *or* renaming the shortcut to something other than git-annex makes it work. A third way of fixing it is to open git-annex-webapp.vbs and changing \"git-annex webapp\" to \"git annex webapp\". I don't know which option is the cleanest solution.
+
+I take it back that git-annex-autostart loops. I seem to remember that it did on another computer (running a version of git-annex downloaded today) but probably remember wrong. Now I can only reproduce this with the webapp shortcut.
+
+"""]]

add news item for git-annex 5.20150409
diff --git a/doc/news/version_5.20150219.mdwn b/doc/news/version_5.20150219.mdwn
deleted file mode 100644
index 0225e85..0000000
--- a/doc/news/version_5.20150219.mdwn
+++ /dev/null
@@ -1,34 +0,0 @@
-git-annex 5.20150219 released with [[!toggle text="these changes"]]
-[[!toggleable text="""
-   * glacier: Detect when the glacier command in PATH is the wrong one,
-     from boto, rather than from glacier-cli, and refuse to use it,
-     since the boto program fails to fail when passed
-     parameters it does not understand.
-   * groupwanted: New command to set the groupwanted preferred content
-     expression.
-   * import: Support file matching options such as --exclude, --include,
-     --smallerthan, --largerthan
-   * The file matching options are now only accepted by commands that
-     can actually use them, instead of by all commands.
-   * import: Avoid checksumming file twice when run in the default
-     or --duplicate mode.
-   * Windows: Fix bug in dropping an annexed file, which
-     caused a symlink to be staged that contained backslashes.
-   * webapp: Fix reversion in opening webapp when starting it manually
-     inside a repository.
-   * assistant: Improve sanity check for control characters when pairing.
-   * Improve race recovery code when committing to git-annex branch.
-   * addurl: Avoid crash if quvi is not installed, when git-annex was
-     built with process-1.2
-   * bittorrent: Fix mojibake introduced in parsing arai2c progress output.
-   * fsck --from: If a download from a remote fails, propagate the failure.
-   * metadata: When setting metadata, do not recurse into directories by
-     default, since that can be surprising behavior and difficult to recover
-     from. The old behavior is available by using --force.
-   * sync, assistant: Include repository name in head branch commit message.
-   * The ssh-options git config is now used by gcrypt, rsync, and ddar
-     special remotes that use ssh as a transport.
-   * sync, assistant: Use the ssh-options git config when doing git pull
-     and push.
-   * remotedaemon: Use the ssh-options git config.
-   * Linux standalone: Improved process names of linker shimmed programs."""]]
\ No newline at end of file
diff --git a/doc/news/version_5.20150409.mdwn b/doc/news/version_5.20150409.mdwn
new file mode 100644
index 0000000..49ddd8c
--- /dev/null
+++ b/doc/news/version_5.20150409.mdwn
@@ -0,0 +1,23 @@
+git-annex 5.20150409 released with [[!toggle text="these changes"]]
+[[!toggleable text="""
+   * This fixes a bug in the assistant introduced by the literal pathspec
+     changes in version 5.20150406.
+   * --quiet now suppresses progress displays from eg, rsync.
+     (Second time's the charm..)
+   * fromkey, registerurl: When reading from stdin, allow the
+     filename and url, respectively, to contain whitespace.
+   * add: If annex.largefiles is set and does not match a file that's being
+     added, the file will be checked into git rather than being added to the
+     annex. Previously, git annex add skipped over such files; this new
+     behavior is more useful in direct mode.
+   * proxy: Made it work when run in a new repository before initial
+     commit.
+   * info: Display repository mode: bare when in a bare (non-direct mode)
+     repo.
+   * importfeed: Fix feed download when curl is used.
+   * importfeed: Error out when passed a non-url.
+   * webapp: When adding another local repository, and combining it
+     with the current repository, the new repository's remote path
+     was set to "." rather than the path to the current repository.
+     This was a reversion caused by the relative path changes in 5.20150113.
+   * contentlocationn: New plumbing command."""]]
\ No newline at end of file

Added a comment
diff --git a/doc/forum/Windows_installation_notes/comment_2_c8c2744e30f2950d9830936d2bd51617._comment b/doc/forum/Windows_installation_notes/comment_2_c8c2744e30f2950d9830936d2bd51617._comment
new file mode 100644
index 0000000..cab6b1d
--- /dev/null
+++ b/doc/forum/Windows_installation_notes/comment_2_c8c2744e30f2950d9830936d2bd51617._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkQOUUx4LVAk6EnstSLvdv7gZc0NsRlHXw"
+ nickname="Dave"
+ subject="comment 2"
+ date="2015-04-09T20:37:51Z"
+ content="""
+Sorry, joey, I haven't played with git annex on windows since my original post.
+
+I only have one new piece of information: some git annex related auto-start entry was added to the user profile of the account I used to perform the installation.  I noticed this when I logged in interactively as that user...
+
+See what I'm saying?  I have DOMAIN\dave.loyall and WORKSTATION\local.admin.  I have to use the latter to carry out installation, via \"Run as...\", but I need stuff to be installed into DOMAIN\dave.loyall's profile or the AllUsers profile (or whatever it is called).
+
+Meanwhile, more and more of my daily work is carried out in my GNU/Linux virtual machines.  I don't personally want/need anyone to prioritize windows-only deficiencies.
+"""]]

devblog
diff --git a/doc/devblog/day_273__unexpected_release.mdwn b/doc/devblog/day_273__unexpected_release.mdwn
new file mode 100644
index 0000000..5b902c8
--- /dev/null
+++ b/doc/devblog/day_273__unexpected_release.mdwn
@@ -0,0 +1,15 @@
+I've had to release git-annex twice this week to fix reversions. On Monday,
+just after I made a planned release, I discovered a bug in it, and had to
+update it with a .1 release. Today's release fixes 2 other reversions
+introduced by recent changes, both only affecting the assistant.
+
+Before making today's release, I did a bunch of other minor bugfixes and
+improvements, including adding a new `contentlocationn` plumbing command.
+This release also changes `git annex add` when annex.largefiles is
+configured, so it will `git add` the non-large files. That is particularly
+useful in direct mode.
+
+I feel that the assistant needs some TLC, so I might devote a week to it in
+the latter part of this month. My current funding doesn't cover work
+on the assistant, but I should have some spare time toward the end of the
+month.

response
diff --git a/doc/forum/Slow_transfer_speeds_on_copy_in_Windows/comment_1_dd4ebb10ac87e3ee6158b7e7b1273a81._comment b/doc/forum/Slow_transfer_speeds_on_copy_in_Windows/comment_1_dd4ebb10ac87e3ee6158b7e7b1273a81._comment
new file mode 100644
index 0000000..e6bdd2c
--- /dev/null
+++ b/doc/forum/Slow_transfer_speeds_on_copy_in_Windows/comment_1_dd4ebb10ac87e3ee6158b7e7b1273a81._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-04-09T20:30:19Z"
+ content="""
+There's not a lot of places where git-annex could make this slower.
+git-annex copy is just running rsync to the ssh server.
+
+Have you tried benchmarking rsync of a large file to the server w/o
+git-annex? rsync does do considerably more client-side work than does
+scp, in order to support resuming, so that might be it.
+"""]]

diff --git a/doc/forum/Slow_transfer_speeds_on_copy_in_Windows.mdwn b/doc/forum/Slow_transfer_speeds_on_copy_in_Windows.mdwn
index 37d2c3d..3cbd7f4 100644
--- a/doc/forum/Slow_transfer_speeds_on_copy_in_Windows.mdwn
+++ b/doc/forum/Slow_transfer_speeds_on_copy_in_Windows.mdwn
@@ -1 +1,3 @@
 Copying a large file from windows (msysgit 1.9.5.msysgit.1, git-annex 20150406) to a bare repository on debian wheezy (git 1.9.1 git-annex 20141024)  I can only get around 2 MB/s transfer speed.  I tested using normal windows copy (smb) and got around 10 MB/s, while the git-annex copy was still going on.  I tried plain ssh and got 9 MB/s.  So, something to do with git-annex is being slow it seems.  Any ideas on how to remedy this, or is it a known issue?
+
+Note: Problem not seen going from linux to linux... waaaayyy faster (40 MB/s) to put it lightly (10 min vs all day)  The destination server is the same.

diff --git a/doc/bugs/pathspec_magic_not_supported_by_this_command:___39__literal__39__.mdwn b/doc/bugs/pathspec_magic_not_supported_by_this_command:___39__literal__39__.mdwn
index dbb8134..d0de521 100644
--- a/doc/bugs/pathspec_magic_not_supported_by_this_command:___39__literal__39__.mdwn
+++ b/doc/bugs/pathspec_magic_not_supported_by_this_command:___39__literal__39__.mdwn
@@ -98,7 +98,7 @@ fatal: Work/archive/Tidrapportering/Tid.md: pathspec magic not supported by this
 >> I tried an older version of git-annex on the same repository, and could not find any "commitBuffer:
 >> invalid argument" in the log.
 >>
->> I would like the take the chance to thank you for the incredible work you are doing with this software/tool! It's an amazing effort!
+>> I would like to take the chance to thank you for the incredible work you are doing with this software/tool! It's an amazing effort!
 >>
 >> -Daniel
 

diff --git a/doc/bugs/pathspec_magic_not_supported_by_this_command:___39__literal__39__.mdwn b/doc/bugs/pathspec_magic_not_supported_by_this_command:___39__literal__39__.mdwn
index 73b846a..dbb8134 100644
--- a/doc/bugs/pathspec_magic_not_supported_by_this_command:___39__literal__39__.mdwn
+++ b/doc/bugs/pathspec_magic_not_supported_by_this_command:___39__literal__39__.mdwn
@@ -94,3 +94,11 @@ fatal: Work/archive/Tidrapportering/Tid.md: pathspec magic not supported by this
 > looking problem, even when using swedish chars in filenames.
 > 
 > --[[Joey]]
+
+>> I tried an older version of git-annex on the same repository, and could not find any "commitBuffer:
+>> invalid argument" in the log.
+>>
+>> I would like the take the chance to thank you for the incredible work you are doing with this software/tool! It's an amazing effort!
+>>
+>> -Daniel
+

contentlocationn: New plumbing command.
diff --git a/Annex/Content.hs b/Annex/Content.hs
index 310c43d..1705022 100644
--- a/Annex/Content.hs
+++ b/Annex/Content.hs
@@ -9,6 +9,7 @@
 
 module Annex.Content (
 	inAnnex,
+	inAnnex',
 	inAnnexSafe,
 	inAnnexCheck,
 	lockContent,
diff --git a/CmdLine/GitAnnex.hs b/CmdLine/GitAnnex.hs
index 6aeefda..fde4e2d 100644
--- a/CmdLine/GitAnnex.hs
+++ b/CmdLine/GitAnnex.hs
@@ -22,6 +22,7 @@ import qualified Command.Move
 import qualified Command.Copy
 import qualified Command.Get
 import qualified Command.LookupKey
+import qualified Command.ContentLocation
 import qualified Command.ExamineKey
 import qualified Command.FromKey
 import qualified Command.RegisterUrl
@@ -152,6 +153,7 @@ cmds = concat
 	, Command.Ungroup.cmd
 	, Command.Vicfg.cmd
 	, Command.LookupKey.cmd
+	, Command.ContentLocation.cmd
 	, Command.ExamineKey.cmd
 	, Command.FromKey.cmd
 	, Command.RegisterUrl.cmd
diff --git a/Command/ContentLocation.hs b/Command/ContentLocation.hs
new file mode 100644
index 0000000..555f909
--- /dev/null
+++ b/Command/ContentLocation.hs
@@ -0,0 +1,32 @@
+{- git-annex command
+ -
+ - Copyright 2015 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU GPL version 3 or higher.
+ -}
+
+module Command.ContentLocation where
+
+import Common.Annex
+import Command
+import Annex.Content
+import Types.Key
+
+cmd :: [Command]
+cmd = [noCommit $ noMessages $
+	command "contentlocation" (paramRepeating paramKey) seek
+		SectionPlumbing "looks up content for a key"]
+
+seek :: CommandSeek
+seek = withKeys start
+
+start :: Key -> CommandStart
+start k = do
+	liftIO . maybe exitFailure putStrLn
+		=<< inAnnex' (pure True) Nothing check k
+	stop
+  where
+	check f = ifM (liftIO (doesFileExist f))
+		( return (Just f)
+		, return Nothing
+		)
diff --git a/debian/changelog b/debian/changelog
index b506241..0958e7d 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -20,6 +20,7 @@ git-annex (5.20150409) unstable; urgency=medium
     with the current repository, the new repository's remote path
     was set to "." rather than the path to the current repository.
     This was a reversion caused by the relative path changes in 5.20150113.
+  * contentlocationn: New plumbing command.
 
  -- Joey Hess <id@joeyh.name>  Thu, 09 Apr 2015 15:06:38 -0400
 
diff --git a/doc/bugs/for_custom_remotes_provide_enhanced_DIRHASH_which_outputs_full_DIRHASH_to_the_key_load.mdwn b/doc/bugs/for_custom_remotes_provide_enhanced_DIRHASH_which_outputs_full_DIRHASH_to_the_key_load.mdwn
index df42a49..7f9ca28 100644
--- a/doc/bugs/for_custom_remotes_provide_enhanced_DIRHASH_which_outputs_full_DIRHASH_to_the_key_load.mdwn
+++ b/doc/bugs/for_custom_remotes_provide_enhanced_DIRHASH_which_outputs_full_DIRHASH_to_the_key_load.mdwn
@@ -2,3 +2,4 @@
 
 Current layout is DIRHASH (of two levels) /KEY/KEY, so I would need to hardcode having that KEY directory.  It might be nice to either make DIRHASH to return full hash directory (but it might break existing special remotes), or supplement with e.g. DIRHASHFULL which would return all the levels necessary to reach the KEY file
 
+> [[done]] --[[Joey]]
diff --git a/doc/bugs/for_custom_remotes_provide_enhanced_DIRHASH_which_outputs_full_DIRHASH_to_the_key_load/comment_3_6430c915dd2969bda4070fa4ba01a935._comment b/doc/bugs/for_custom_remotes_provide_enhanced_DIRHASH_which_outputs_full_DIRHASH_to_the_key_load/comment_3_6430c915dd2969bda4070fa4ba01a935._comment
new file mode 100644
index 0000000..b6d2456
--- /dev/null
+++ b/doc/bugs/for_custom_remotes_provide_enhanced_DIRHASH_which_outputs_full_DIRHASH_to_the_key_load/comment_3_6430c915dd2969bda4070fa4ba01a935._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2015-04-09T19:08:40Z"
+ content="""
+I've added a contentlocation command
+
+I'd expect an external command to not be much slower than using the pipe
+for this. It does not need to spin up any git commands etc to get the
+content location. Also, you can pass it multiple keys to query at one time
+if necessary.
+
+I guess we'll see if this is too slow and can revisit it if so..
+"""]]
diff --git a/doc/git-annex-contentlocation.mdwn b/doc/git-annex-contentlocation.mdwn
new file mode 100644
index 0000000..128622b
--- /dev/null
+++ b/doc/git-annex-contentlocation.mdwn
@@ -0,0 +1,27 @@
+# NAME
+
+git-annex contentlocation - looks up content for a key
+
+# SYNOPSIS
+
+git annex contentlocation `[key ...]`
+
+# DESCRIPTION
+
+This plumbing-level command looks up filename used to store the content 
+of a key. The filename is output to stdout. If the key's content is not
+present in the local repository, nothing is output, and it exits nonzero.
+
+Note that in direct mode, the file will typically be in the git work
+tree, and while its content should correspond to the key, the file
+could become modified at any time after git-annex checks it.
+
+# SEE ALSO
+
+[[git-annex]](1)
+
+# AUTHOR
+
+Joey Hess <id@joeyh.name>
+
+Warning: Automatically converted into a man page by mdwn2man. Edit with care.
diff --git a/doc/git-annex.mdwn b/doc/git-annex.mdwn
index 11fbc6e..6fd10ae 100644
--- a/doc/git-annex.mdwn
+++ b/doc/git-annex.mdwn
@@ -513,6 +513,12 @@ subdirectories).
 
   See [[git-annex-lookupkey]](1) for details.
 
+* `contentlocation [key ..]`
+
+  Looks up location of annexed content for a key.
+
+  See [[git-annex-contentlocation]](1) for details.
+
 * `examinekey [key ...]`
 
   Print information that can be determined purely by looking at the key.

fix webapp reversion caused by relative path changes
webapp: When adding another local repository, and combining it with the
current repository, the new repository's remote path was set to "." rather
than the path to the current repository. This was a reversion caused by the
relative path changes in 5.20150113.
diff --git a/Assistant/WebApp/Configurators/Local.hs b/Assistant/WebApp/Configurators/Local.hs
index abfadc7..30fc0ca 100644
--- a/Assistant/WebApp/Configurators/Local.hs
+++ b/Assistant/WebApp/Configurators/Local.hs
@@ -347,8 +347,9 @@ getFinishAddDriveR drive = go
 combineRepos :: FilePath -> String -> Handler Remote
 combineRepos dir name = liftAnnex $ do
 	hostname <- fromMaybe "host" <$> liftIO getHostname
-	hostlocation <- fromRepo Git.repoLocation
-	liftIO $ inDir dir $ void $ makeGitRemote hostname hostlocation
+	mylocation <- fromRepo Git.repoLocation
+	mypath <- liftIO $ relPathDirToFile dir mylocation
+	liftIO $ inDir dir $ void $ makeGitRemote hostname mypath
 	addRemote $ makeGitRemote name dir
 
 getEnableDirectoryR :: UUID -> Handler Html
diff --git a/debian/changelog b/debian/changelog
index 8b228f1..b53d77a 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,4 +1,4 @@
-git-annex (5.20150406.2) UNRELEASED; urgency=medium
+git-annex (5.20150409) UNRELEASED; urgency=medium
 
   * This fixes a bug in the assistant introduced by the literal pathspec
     changes in version 5.20150406.
@@ -16,6 +16,10 @@ git-annex (5.20150406.2) UNRELEASED; urgency=medium
     repo.
   * importfeed: Fix feed download when curl is used.
   * importfeed: Error out when passed a non-url.
+  * webapp: When adding another local repository, and combining it
+    with the current repository, the new repository's remote path
+    was set to "." rather than the path to the current repository.
+    This was a reversion caused by the relative path changes in 5.20150113.
 
  -- Joey Hess <id@joeyh.name>  Mon, 06 Apr 2015 20:14:20 -0400
 
diff --git a/doc/forum/Adding_a_mounted_network/comment_2_ae3d4ac918ef002ead859ed0c962ae32._comment b/doc/forum/Adding_a_mounted_network/comment_2_ae3d4ac918ef002ead859ed0c962ae32._comment
new file mode 100644
index 0000000..eaf0665
--- /dev/null
+++ b/doc/forum/Adding_a_mounted_network/comment_2_ae3d4ac918ef002ead859ed0c962ae32._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2015-04-09T18:33:47Z"
+ content="""
+If you want to do with using the webapp, go to the "Repository"
+menu in the upper-left, and select "Add another local repository."
+
+You can then enter the path to your repository, whevever it is, 
+and click on "combine the repositories"
+
+But, like Justin said, this just sets up a git remote, so doing it at
+the command line will work just as well.
+"""]]

followup
diff --git a/doc/design/metadata/comment_11_402d7d3e8e7f2df57eb6685134226642._comment b/doc/design/metadata/comment_11_402d7d3e8e7f2df57eb6685134226642._comment
new file mode 100644
index 0000000..b7b8937
--- /dev/null
+++ b/doc/design/metadata/comment_11_402d7d3e8e7f2df57eb6685134226642._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 11"""
+ date="2015-04-09T18:31:34Z"
+ content="""
+@Sunke, the reason that views make up their own filenames is to
+avoid the problem of having 2 files in a view that have the same
+name.
+
+In your example, that could happen if you used --set title
+with the same title for 2 separate files.
+
+So, I don't think this can be supported reasonably.
+"""]]

followup
diff --git a/doc/bugs/windows_start_menu_shortcuts_are_missing___34__Start_in__34___parameter/comment_1_5af705ddb453588711f3e70b2e297f55._comment b/doc/bugs/windows_start_menu_shortcuts_are_missing___34__Start_in__34___parameter/comment_1_5af705ddb453588711f3e70b2e297f55._comment
new file mode 100644
index 0000000..2922515
--- /dev/null
+++ b/doc/bugs/windows_start_menu_shortcuts_are_missing___34__Start_in__34___parameter/comment_1_5af705ddb453588711f3e70b2e297f55._comment
@@ -0,0 +1,28 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-04-09T18:15:31Z"
+ content="""
+Thanks for reporting this.
+
+Is git in your path? (Ie, can you run git from command.exe?)
+
+I notice that the
+<http://git-annex.branchable.com/bugs/windows_start_menu_shortcuts_are_missing___34__Start_in__34___parameter/>
+page, which had this problem, was a user who neglected to have git add
+itself to path, contrary to what the installation instructiins say to do.
+
+So, it's not surprising that disregarding the instructions break, but this
+is a bad way for it to break. It would be better to at least avoid the
+loop, and perhaps Just Work.
+
+I don't understand why it loops.. the git-annex-webapp.vbs runs "git-annex
+webapp". If git-annex is not in path (because git is not in path and it
+piggybacks off git's path settings), that should fail to do anything. 
+Or is Windows really sufficiently DWIM that it will search for **different
+spellings** of program names?!
+
+I don't see how I can add a "Start in" parameter; git-annex has no way of
+knowing where the user intended to install git if they didn't add git to
+the path.
+"""]]
diff --git a/doc/forum/Windows_installation_notes/comment_1_54c253ab61fea4f5aaefa04bb078c7b0._comment b/doc/forum/Windows_installation_notes/comment_1_54c253ab61fea4f5aaefa04bb078c7b0._comment
new file mode 100644
index 0000000..7b26547
--- /dev/null
+++ b/doc/forum/Windows_installation_notes/comment_1_54c253ab61fea4f5aaefa04bb078c7b0._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-04-09T18:26:30Z"
+ content="""
+Not following the instructions to have git put itself into the path seems
+like a sure-fire way to shoot yourself in the foot.
+
+The loop problem is being discussed at
+<http://git-annex.branchable.com/bugs/windows_start_menu_shortcuts_are_missing___34__Start_in__34___parameter/>
+perhaps you'll be able to answer my questions about it there?
+"""]]

diff --git a/doc/forum/Slow_transfer_speeds_on_copy_in_Windows.mdwn b/doc/forum/Slow_transfer_speeds_on_copy_in_Windows.mdwn
new file mode 100644
index 0000000..37d2c3d
--- /dev/null
+++ b/doc/forum/Slow_transfer_speeds_on_copy_in_Windows.mdwn
@@ -0,0 +1 @@
+Copying a large file from windows (msysgit 1.9.5.msysgit.1, git-annex 20150406) to a bare repository on debian wheezy (git 1.9.1 git-annex 20141024)  I can only get around 2 MB/s transfer speed.  I tested using normal windows copy (smb) and got around 10 MB/s, while the git-annex copy was still going on.  I tried plain ssh and got 9 MB/s.  So, something to do with git-annex is being slow it seems.  Any ideas on how to remedy this, or is it a known issue?

cannot reproduce
diff --git a/doc/bugs/git-annex_unused_--from_s3_doesn__39__t/comment_1_f139f18762f3acf8bfb9ce8a245b79f5._comment b/doc/bugs/git-annex_unused_--from_s3_doesn__39__t/comment_1_f139f18762f3acf8bfb9ce8a245b79f5._comment
new file mode 100644
index 0000000..a949625
--- /dev/null
+++ b/doc/bugs/git-annex_unused_--from_s3_doesn__39__t/comment_1_f139f18762f3acf8bfb9ce8a245b79f5._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-04-09T18:06:34Z"
+ content="""
+I have tried to reproduce this, and I can't seem to.
+
+There's no network traffic involved in git-annex unused --from remote,
+so I don't see how this can involve the S3 backend at all. If there's a bug
+here, it should affect any kind of remote.
+
+Are you sure you didn't forget to `git annex sync` before `git annex unused --from remote`?
+If you have an old synced/master branch, that'll count as a user of the
+file and so unused won't show it.
+
+I think you'll need to provide a full transcript of how to make this problem
+happen for me to get any further.
+"""]]

followup to bug I cannot reproduce, and analysis based presumptive fix
diff --git a/Annex/Branch.hs b/Annex/Branch.hs
index 7411e70..4bd94bd 100644
--- a/Annex/Branch.hs
+++ b/Annex/Branch.hs
@@ -414,6 +414,7 @@ stageJournal jl = withIndex $ do
 	g <- gitRepo
 	let dir = gitAnnexJournalDir g
 	(jlogf, jlogh) <- openjlog
+	liftIO $ fileEncoding jlogh
 	withJournalHandle $ \jh -> do
 		h <- hashObjectStart g
 		Git.UpdateIndex.streamUpdateIndex g
diff --git a/doc/bugs/commitBuffer:_invalid_argument___40__invalid_character__41__/comment_1_b56c847c5eda432a4330b4d853a25519._comment b/doc/bugs/commitBuffer:_invalid_argument___40__invalid_character__41__/comment_1_b56c847c5eda432a4330b4d853a25519._comment
new file mode 100644
index 0000000..43e6a39
--- /dev/null
+++ b/doc/bugs/commitBuffer:_invalid_argument___40__invalid_character__41__/comment_1_b56c847c5eda432a4330b4d853a25519._comment
@@ -0,0 +1,27 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-04-09T17:49:57Z"
+ content="""
+I cannot reproduce this, I get:
+
+	addurl _dev_radio/DR14__Verschwörungstheorien.ogg ok
+
+Does the _dev_radio/DR14__Verschwörungstheorien.ogg file get created?
+If so, how does it look?
+
+The jlog tells me it's trying to commit the git-annex branch journal.
+Does .git/annex/journal/ contain any files? Any files containing German
+characters?
+
+Do you have any git config settings for git-annex beyone the typical
+annex.uuid?
+
+I noticed one place in the journal commit code where it does seem to
+neglect to use filesystem encoding when dealing with writing filenames to
+the jlog tmpfile. Which could lead to this crash theoretically. I've fixed
+that, but since I couldn't reproduce the problem, I don't know if this will
+fix your problem. Nor do I understand how annex journal log files could
+have these characters in their names. You can try today's upcoming release
+of git-annex to test the fix though.
+"""]]

followup
diff --git a/doc/bugs/git-annex-shell/comment_1_3d2c3827de34509c0a5595eda07dd18f._comment b/doc/bugs/git-annex-shell/comment_1_3d2c3827de34509c0a5595eda07dd18f._comment
new file mode 100644
index 0000000..6123471
--- /dev/null
+++ b/doc/bugs/git-annex-shell/comment_1_3d2c3827de34509c0a5595eda07dd18f._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-04-09T17:48:20Z"
+ content="""
+GIT_SSH is set to the full path of the binary, unless
+~/.config/git-annex/program overrides it.
+
+Finding the full path to the binary is not a trivial or error-free
+operation.
+
+Could you please follow up to this bug or close it?
+"""]]

comment
diff --git a/doc/forum/Why_is_git_annex_status_slow__63__/comment_3_8d9e5a1aef2648d7a844623e6237d551._comment b/doc/forum/Why_is_git_annex_status_slow__63__/comment_3_8d9e5a1aef2648d7a844623e6237d551._comment
new file mode 100644
index 0000000..54d2b24
--- /dev/null
+++ b/doc/forum/Why_is_git_annex_status_slow__63__/comment_3_8d9e5a1aef2648d7a844623e6237d551._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2015-04-09T17:44:01Z"
+ content="""
+The sizes of the files should not affect how fast git-annex status runs. 
+
+But, direct mode certianly does. git-annex has to do significantly more
+work in direct mode to figure out the status of a file. Including querying
+git. In indirect mode, it can just stat the symlink and see if its content
+is present, which is much faster.
+
+(There's probably also some other inneficiencies in Windows.)
+"""]]

moreinfo needed
diff --git a/doc/bugs/corrupt_backend_upon_sync__63__/comment_1_9f248d82f93040b739b56515d18458c7._comment b/doc/bugs/corrupt_backend_upon_sync__63__/comment_1_9f248d82f93040b739b56515d18458c7._comment
new file mode 100644
index 0000000..ddec07c
--- /dev/null
+++ b/doc/bugs/corrupt_backend_upon_sync__63__/comment_1_9f248d82f93040b739b56515d18458c7._comment
@@ -0,0 +1,24 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-04-09T17:39:28Z"
+ content="""
+The symink that you're showing is a file checked into git.
+
+So, you should be able to run `git log 'Pictures/2014/06/21/2014-06-21 13.52.34.png'`
+on the remote and find a commit that somehow changed the symlink to the
+broken one that the remote has.
+
+The only other possibilities are
+
+* Somehow the data in git in the remote got corrupted, and git didn't
+  notice. Seems very unlikely.
+* Somehow git decided to munge up the symlink when checking it out on the
+  remote. While there are some git features like smudge filters that could
+  perhaps be configured to do that, I don't see how git could do it on its
+  own.
+
+I've never seen git do anything like this.
+You're going to have to investigate this on your own and/or provide enough
+information to reproduce the problem.
+"""]]

This fixes a bug in the assistant introduced by the literal pathspec changes in version 5.20150406.
git-checkignore refuses to work if any pathspec options are set. Urgh.
I audited the rest of git, and no other commands used by git-annex have
such limitations. Indeed, AFAICS, *all* other commands support
--literal-pathspecs. So, worked around this where git-checkignore is
called.
diff --git a/Git/CheckIgnore.hs b/Git/CheckIgnore.hs
index 5fa3cb6..a03f454 100644
--- a/Git/CheckIgnore.hs
+++ b/Git/CheckIgnore.hs
@@ -31,10 +31,13 @@ type CheckIgnoreHandle = CoProcess.CoProcessHandle
  -
  - The first version of git to support what we need is 1.8.4.
  - Nothing is returned if an older git is installed.
+ -
+ - check-ignore does not support --literal-pathspecs, so remove that
+ - from the gitGlobalOpts if set.
  -}
 checkIgnoreStart :: Repo -> IO (Maybe CheckIgnoreHandle)
 checkIgnoreStart repo = ifM supportedGitVersion
-	( Just <$> (CoProcess.rawMode =<< gitCoProcessStart True params repo)
+	( Just <$> (CoProcess.rawMode =<< gitCoProcessStart True params repo')
 	, return Nothing
 	)
   where
@@ -42,6 +45,9 @@ checkIgnoreStart repo = ifM supportedGitVersion
 		[ Param "check-ignore" 
 		, Params "-z --stdin --verbose --non-matching"
 		]
+	repo' = repo { gitGlobalOpts = filter (not . pathspecs) (gitGlobalOpts repo) }
+	pathspecs (Param "--literal-pathspecs") = True
+	pathspecs _ = False
 
 supportedGitVersion :: IO Bool
 supportedGitVersion = do
diff --git a/debian/changelog b/debian/changelog
index 557d3eb..8b228f1 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,5 +1,7 @@
 git-annex (5.20150406.2) UNRELEASED; urgency=medium
 
+  * This fixes a bug in the assistant introduced by the literal pathspec
+    changes in version 5.20150406.
   * --quiet now suppresses progress displays from eg, rsync.
     (Second time's the charm..)
   * fromkey, registerurl: When reading from stdin, allow the
diff --git a/doc/bugs/pathspec_magic_not_supported_by_this_command:___39__literal__39__.mdwn b/doc/bugs/pathspec_magic_not_supported_by_this_command:___39__literal__39__.mdwn
index c670391..73b846a 100644
--- a/doc/bugs/pathspec_magic_not_supported_by_this_command:___39__literal__39__.mdwn
+++ b/doc/bugs/pathspec_magic_not_supported_by_this_command:___39__literal__39__.mdwn
@@ -78,3 +78,19 @@ fatal: Work/archive/Tidrapportering/Tid.md: pathspec magic not supported by this
 fatal: Work/archive/Tidrapportering/Tid.md: pathspec magic not supported by this command: 'literal'
 
 """]]
+
+> I've fixed the pathspec magic problem. [[done]]
+> 
+> Seems like you could possibly have a separate problem WRT the "commitBuffer:
+> invalid argument". When using the older version of git-annex, did you 
+> get that in the log at all?
+>
+> OTOH, the
+> "@Projects/archive/20140515_METOCC_Gr������nsytem������te" 
+> weirdness in the log could be where the problem chars are coming from
+> too, in which case it was somehow caused by the pathspec magic problem.
+> 
+> I was able to reproduce the pathspec magic problem, but not the encoding
+> looking problem, even when using swedish chars in filenames.
+> 
+> --[[Joey]]

importfeed: Error out when passed a non-url.
diff --git a/Command/ImportFeed.hs b/Command/ImportFeed.hs
index ed3c3bc..2a278de 100644
--- a/Command/ImportFeed.hs
+++ b/Command/ImportFeed.hs
@@ -146,15 +146,17 @@ findDownloads u = go =<< downloadFeed u
 
 {- Feeds change, so a feed download cannot be resumed. -}
 downloadFeed :: URLString -> Annex (Maybe Feed)
-downloadFeed url = do
-	showOutput
-	uo <- Url.getUrlOptions
-	liftIO $ withTmpFile "feed" $ \f h -> do
-		hClose h
-		ifM (Url.download url f uo)
-			( parseFeedString <$> readFileStrictAnyEncoding f
-			, return Nothing
-			)
+downloadFeed url
+	| Url.parseURIRelaxed url == Nothing = error "invalid feed url"
+	| otherwise = do
+		showOutput
+		uo <- Url.getUrlOptions
+		liftIO $ withTmpFile "feed" $ \f h -> do
+			hClose h
+			ifM (Url.download url f uo)
+				( parseFeedString <$> readFileStrictAnyEncoding f
+				, return Nothing
+				)
 
 performDownload :: Opts -> Cache -> ToDownload -> Annex Bool
 performDownload opts cache todownload = case location todownload of
diff --git a/debian/changelog b/debian/changelog
index 3c4f0d1..557d3eb 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -13,6 +13,7 @@ git-annex (5.20150406.2) UNRELEASED; urgency=medium
   * info: Display repository mode: bare when in a bare (non-direct mode)
     repo.
   * importfeed: Fix feed download when curl is used.
+  * importfeed: Error out when passed a non-url.
 
  -- Joey Hess <id@joeyh.name>  Mon, 06 Apr 2015 20:14:20 -0400
 
diff --git a/doc/bugs/importfeed_fails_with_local_file_urls.mdwn b/doc/bugs/importfeed_fails_with_local_file_urls.mdwn
index 5984458..932848d 100644
--- a/doc/bugs/importfeed_fails_with_local_file_urls.mdwn
+++ b/doc/bugs/importfeed_fails_with_local_file_urls.mdwn
@@ -26,3 +26,10 @@ Is it possible to use local files in rss format with items which reference local
 
 Cheers,
 Marco
+
+> I've fixed it with file:// urls. 
+>
+> Also made it error out on non-url feed inputs, which are not intended to be
+> supported.
+>
+> [[done]] --[[Joey]]

diff --git a/doc/bugs/windows_start_menu_shortcuts_are_missing___34__Start_in__34___parameter.mdwn b/doc/bugs/windows_start_menu_shortcuts_are_missing___34__Start_in__34___parameter.mdwn
new file mode 100644
index 0000000..72f0794
--- /dev/null
+++ b/doc/bugs/windows_start_menu_shortcuts_are_missing___34__Start_in__34___parameter.mdwn
@@ -0,0 +1,12 @@
+### Please describe the problem.
+When git-annex is started using one of its start menu shortcuts (git-annex or git-annex-autostart) wscript.exe calls itself in an infinite loop. This is also described under the [section ".vbs failure" in a forum post](https://git-annex.branchable.com/forum/Windows_installation_notes/).
+
+### What steps will reproduce the problem?
+Install git and git-annex according to the [installation guide](https://git-annex.branchable.com/install/Windows/). Click on one of the shortcuts in the start menu.
+
+### What version of git-annex are you using? On what operating system?
+git version 1.9.5.msysgit.1. git-annex version: 5.20150317-g237d5b0. Windows 7 Professional, 64-bit.
+
+### Please provide any additional information below.
+
+This seems to be fixed by editing the shortcuts and setting the "Start in" parameter to the git installation directory. For me this is "C:\Program Files (x86)\Git".

Added a comment
diff --git a/doc/forum/Adding_a_mounted_network/comment_1_9b4bab6177856569adfec26ada6b01cd._comment b/doc/forum/Adding_a_mounted_network/comment_1_9b4bab6177856569adfec26ada6b01cd._comment
new file mode 100644
index 0000000..cda6d5f
--- /dev/null
+++ b/doc/forum/Adding_a_mounted_network/comment_1_9b4bab6177856569adfec26ada6b01cd._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmBUR4O9mofxVbpb8JV9mEbVfIYv670uJo"
+ nickname="Justin"
+ subject="comment 1"
+ date="2015-04-09T13:17:41Z"
+ content="""
+It's just a git remote..
+
+    git remote add somerepo /path/to/repo
+    git annex sync
+
+should be all you need.
+"""]]

Added a comment
diff --git a/doc/forum/why_doesn__39__t___96__git_annex_fix__96___fix_a_link__63__/comment_3_be2816c47091842b829cd626e18c5fda._comment b/doc/forum/why_doesn__39__t___96__git_annex_fix__96___fix_a_link__63__/comment_3_be2816c47091842b829cd626e18c5fda._comment
new file mode 100644
index 0000000..731f4d2
--- /dev/null
+++ b/doc/forum/why_doesn__39__t___96__git_annex_fix__96___fix_a_link__63__/comment_3_be2816c47091842b829cd626e18c5fda._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnVnsqEy82M-MuS2gLri-az83wSQ6lXSrc"
+ nickname="Jean"
+ subject="comment 3"
+ date="2015-04-09T05:37:03Z"
+ content="""
+Hi CandyAngel, thanks for the pointer, I 
+[commented](http://git-annex.branchable.com/todo/__34__git-annex_fix__34___on_untracked__44___but_git-annexy_symlinks/#comment-5251d819e83c66dbdd9d7bcee4a87f9f) there.
+"""]]

Added a comment: I'm with Remy here
diff --git a/doc/todo/__34__git-annex_fix__34___on_untracked__44___but_git-annexy_symlinks/comment_4_1e10274827564902047c72a81affd92c._comment b/doc/todo/__34__git-annex_fix__34___on_untracked__44___but_git-annexy_symlinks/comment_4_1e10274827564902047c72a81affd92c._comment
new file mode 100644
index 0000000..34d9595
--- /dev/null
+++ b/doc/todo/__34__git-annex_fix__34___on_untracked__44___but_git-annexy_symlinks/comment_4_1e10274827564902047c72a81affd92c._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnVnsqEy82M-MuS2gLri-az83wSQ6lXSrc"
+ nickname="Jean"
+ subject="I'm with Remy here"
+ date="2015-04-09T05:02:50Z"
+ content="""
+I can't even comprehend how git-annex gets into this situation. From what angle does it make sense to ever have a symlink pointing at a `.git/annex/objects/...` and not be tracked?
+"""]]

explicitely mention --force in tip body
diff --git a/doc/tips/downloading_podcasts.mdwn b/doc/tips/downloading_podcasts.mdwn
index 7805f84..fb87518 100644
--- a/doc/tips/downloading_podcasts.mdwn
+++ b/doc/tips/downloading_podcasts.mdwn
@@ -48,6 +48,12 @@ Then you can run git-annex on all the feeds:
 
 `xargs git-annex importfeed < feeds`
 
+## recreating lost episodes
+
+If for some reason git-annex refuses to download files you are certain are in the podcast, it is quite possible it is because they have already been downloaded. In any case, you can use `--force` to redownload them:
+
+`git-annex importfeed --force http://example.com/feed`
+
 ## distributed podcatching
 
 A nice benefit of using git-annex as a podcatcher is that you can

took another look at this
diff --git a/doc/todo/smudge.mdwn b/doc/todo/smudge.mdwn
index 6103ffa..b11b1de 100644
--- a/doc/todo/smudge.mdwn
+++ b/doc/todo/smudge.mdwn
@@ -94,11 +94,20 @@ and it slows down *everything*, from `git status` to `git commit`.
 this. <http://marc.info/?l=git&m=131465033512157&w=2> (Update: apparently
 can't be fixed.)
 
+> Update: I tried this again (2015) and it seems that git status and git
+> add avoid re-sending the file content to the clean filter, as long as the
+> file stat has not changed. I'm not sure when git started doing that,
+> but it seems to avoid this problem.
+> --[[Joey]]
+
 #### smudge
 
 The smudge script can also be provided a filename with %f, but it
 cannot directly write to the file or git gets unhappy.
 
+> Still the case in 2015. Means an unnecesary read and pipe of the file
+> even if the content is already locally available on disk. --[[Joey]]
+
 ### dealing with partial content availability
 
 The smudge filter cannot be allowed to fail, that leaves the tree and

quick look at git-lfs
diff --git a/doc/not.mdwn b/doc/not.mdwn
index baf43c2..754da22 100644
--- a/doc/not.mdwn
+++ b/doc/not.mdwn
@@ -37,9 +37,13 @@
   partial checkouts of file contents, like git-annex does.
 
 * git-annex is similarly not [git-fat](https://github.com/jedbrown/git-fat),
-  which also uses git smudge filters, and also lacks git-annex' widely
+  which also uses git smudge filters, and also lacks git-annex's widely
   distributed storage and partial checkouts.
 
+* Similarly, git-annex is not [git-lfs](https://github.com/github/git-lfs),
+  which also uses git smudge filters, and appears to lack git-annex's
+  widely distributed storage.
+
 * git-annex is also not [boar](http://code.google.com/p/boar/),
   although it shares many of its goals and characteristics. Boar implements
   its own version control system, rather than simply embracing and

diff --git a/doc/forum/Adding_a_mounted_network.mdwn b/doc/forum/Adding_a_mounted_network.mdwn
new file mode 100644
index 0000000..5f62e79
--- /dev/null
+++ b/doc/forum/Adding_a_mounted_network.mdwn
@@ -0,0 +1 @@
+I would like to add (bare) repositories on network directories that are locally mounted. "Add more repositories" gives me many choices, which apparently does not include this specifically. It does have "Removable drive" which sees the CIFS directory (perhaps because it's under /media?) but not the AFS directory, and there doesn't seem to be a way to enter a path where it's not inclined to look ("rescan for removable drives" still misses /afs). I am comfortable using shell commands, but I don't know what commands to use.

add: If annex.largefiles is set and does not match a file that's being added, the file will be checked into git rather than being added to the annex. Previously, git annex add skipped over such files; this new behavior is more useful in direct mode.
diff --git a/Command/Add.hs b/Command/Add.hs
index 7faa7c8..eb0dc22 100644
--- a/Command/Add.hs
+++ b/Command/Add.hs
@@ -52,7 +52,7 @@ seek ps = do
 	matcher <- largeFilesMatcher
 	let go a = flip a ps $ \file -> ifM (checkFileMatcher matcher file <||> Annex.getState Annex.force)
 		( start file
-		, stop
+		, startSmall file
 		)
 	skipdotfiles <- not <$> Annex.getFlag (optionName includeDotFilesOption)
 	go $ withFilesNotInGit skipdotfiles
@@ -61,6 +61,16 @@ seek ps = do
 		, go withFilesUnlocked
 		)
 
+{- Pass file off to git-add. -}
+startSmall :: FilePath -> CommandStart
+startSmall file = do
+	showStart "add" file
+	showNote "non-large file; adding to git directly"
+	next $ do
+		params <- forceParams
+		Annex.Queue.addCommand "add" (params++[Param "--"]) [file]
+		next $ return True
+
 {- The add subcommand annexes a file, generating a key for it using a
  - backend, and then moving it into the annex directory and setting up
  - the symlink pointing to its content. -}
@@ -260,16 +270,19 @@ addLink :: FilePath -> Key -> Maybe InodeCache -> Annex ()
 addLink file key mcache = ifM (coreSymlinks <$> Annex.getGitConfig)
 	( do
 		_ <- link file key mcache
-		params <- ifM (Annex.getState Annex.force)
-			( return [Param "-f"]
-			, return []
-			)
+		params <- forceParams
 		Annex.Queue.addCommand "add" (params++[Param "--"]) [file]
 	, do
 		l <- link file key mcache
 		addAnnexLink l file
 	)
 
+forceParams :: Annex [CommandParam]
+forceParams = ifM (Annex.getState Annex.force)
+	( return [Param "-f"]
+	, return []
+	)
+
 cleanup :: FilePath -> Key -> Maybe InodeCache -> Bool -> CommandCleanup
 cleanup file key mcache hascontent = do
 	ifM (isDirect <&&> pure hascontent)
diff --git a/debian/changelog b/debian/changelog
index 624b8a4..519628d 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -4,6 +4,10 @@ git-annex (5.20150406.2) UNRELEASED; urgency=medium
     (Second time's the charm..)
   * fromkey, registerurl: When reading from stdin, allow the
     filename and url, respectively, to contain whitespace.
+  * add: If annex.largefiles is set and does not match a file that's being
+    added, the file will be checked into git rather than being added to the
+    annex. Previously, git annex add skipped over such files; this new
+    behavior is more useful in direct mode.
 
  -- Joey Hess <id@joeyh.name>  Mon, 06 Apr 2015 20:14:20 -0400
 
diff --git a/doc/git-annex-add.mdwn b/doc/git-annex-add.mdwn
index 4ae0d1c..2003341 100644
--- a/doc/git-annex-add.mdwn
+++ b/doc/git-annex-add.mdwn
@@ -14,6 +14,10 @@ files from the current directory and below.
 Normally, files that are already checked into git, or that git has been
 configured to ignore will be silently skipped.
 
+If annex.largefiles is configured, and does not match a file that is being
+added, `git annex add` will behave the same as `git add` and add the
+non-large file directly to the git repository, instead of to the annex.
+
 # OPTIONS
 
 * `--include-dotfiles`