Recent changes to this wiki:

Added a comment: bugfix?
diff --git a/doc/news/version_5.20150727/comment_1_c4458e41c8a7f843bd3802159099a858._comment b/doc/news/version_5.20150727/comment_1_c4458e41c8a7f843bd3802159099a858._comment
new file mode 100644
index 0000000..a845fdb
--- /dev/null
+++ b/doc/news/version_5.20150727/comment_1_c4458e41c8a7f843bd3802159099a858._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="anarcat"
+ subject="bugfix?"
+ date="2015-07-28T14:01:46Z"
+ content="""
+> Fix bug that prevented uploads to remotes using new-style chunking from resuming after the last successfully uploaded chunk.
+
+Is this related to [[bugs/s3_InternalIOException__63__/]] - should that bug be marked as fixed? Can't wait to test the new release, thanks! --[[anarcat]]
+"""]]

devblog
diff --git a/doc/devblog/day_306__release_day.mdwn b/doc/devblog/day_306__release_day.mdwn
new file mode 100644
index 0000000..dbc0f5e
--- /dev/null
+++ b/doc/devblog/day_306__release_day.mdwn
@@ -0,0 +1,8 @@
+Made a release today, with recent work, including the optparse-applicative
+transition and initial gitlab.com support in the webapp.
+
+I had time before the release to work out most of the wrinkles in the
+gitlab.com support, but was not able to get gcrypt encrypted repos to work
+with gitlab, for reasons that remain murky. Their git-annex-shell seems to
+be misbehaving somehow. Will need to get some debugging assistance from the
+gitlab.com developers to figure that out.

webapp: Support enabling known gitlab.com remotes.
diff --git a/Assistant/WebApp/Configurators/Ssh.hs b/Assistant/WebApp/Configurators/Ssh.hs
index 7d78704..96a99fa 100644
--- a/Assistant/WebApp/Configurators/Ssh.hs
+++ b/Assistant/WebApp/Configurators/Ssh.hs
@@ -212,23 +212,26 @@ postEnableSshGitRemoteR = enableSshRemote getsshinput enableRsyncNet enablesshgi
  - to prompt for its password.
  -}
 enableSshRemote :: (RemoteConfig -> Maybe SshData) -> (SshInput -> RemoteName -> Handler Html) -> (SshData -> UUID -> Handler Html) -> UUID -> Handler Html
-enableSshRemote getsshinput rsyncnetsetup genericsetup u = do
+enableSshRemote getsshdata rsyncnetsetup genericsetup u = do
 	m <- fromMaybe M.empty . M.lookup u <$> liftAnnex readRemoteLog
-	case (mkSshInput . unmangle <$> getsshinput m, M.lookup "name" m) of
-		(Just sshinput, Just reponame) -> sshConfigurator $ do
-			((result, form), enctype) <- liftH $
-				runFormPostNoToken $ renderBootstrap3 bootstrapFormLayout $ sshInputAForm textField sshinput
-			case result of
-				FormSuccess sshinput'
-					| isRsyncNet (inputHostname sshinput') ->
-						void $ liftH $ rsyncnetsetup sshinput' reponame
-					| otherwise -> do
-						s <- liftAssistant $ testServer sshinput'
-						case s of
-							Left status -> showform form enctype status
-							Right (sshdata, _u) -> void $ liftH $ genericsetup
-								( sshdata { sshRepoName = reponame } ) u
-				_ -> showform form enctype UntestedServer
+	case (unmangle <$> getsshdata m, M.lookup "name" m) of
+		(Just sshdata, Just reponame)
+			| isGitLab sshdata -> enableGitLab sshdata
+			| otherwise -> sshConfigurator $ do
+				((result, form), enctype) <- liftH $
+					runFormPostNoToken $ renderBootstrap3 bootstrapFormLayout $
+						sshInputAForm textField $ mkSshInput sshdata
+				case result of
+					FormSuccess sshinput
+						| isRsyncNet (inputHostname sshinput) ->
+							void $ liftH $ rsyncnetsetup sshinput reponame
+						| otherwise -> do
+							s <- liftAssistant $ testServer sshinput
+							case s of
+								Left status -> showform form enctype status
+								Right (sshdata', _u) -> void $ liftH $ genericsetup
+									( sshdata' { sshRepoName = reponame } ) u
+					_ -> showform form enctype UntestedServer
 		_ -> redirect AddSshR
   where
 	unmangle sshdata = sshdata
@@ -672,7 +675,7 @@ isRsyncNet :: Maybe Text -> Bool
 isRsyncNet Nothing = False
 isRsyncNet (Just host) = ".rsync.net" `T.isSuffixOf` T.toLower host
 
-data GitLabUrl = GitLabUrl Text
+data GitLabUrl = GitLabUrl { unGitLabUrl :: Text }
 
 badGitLabUrl :: Text
 badGitLabUrl = "Bad SSH clone url. Expected something like: git@gitlab.com:yourlogin/annex.git"
@@ -698,6 +701,18 @@ parseGitLabUrl (GitLabUrl t) =
 			, sshRepoUrl = Just (T.unpack t)
 			}
 
+isGitLab :: SshData -> Bool
+isGitLab d = T.pack "gitlab.com" `T.isSuffixOf` (T.toLower (sshHostName d))
+
+toGitLabUrl :: SshData -> GitLabUrl
+toGitLabUrl d = GitLabUrl $ T.concat
+	[ fromMaybe (T.pack "git") (sshUserName d)
+	, T.pack "@"
+	, sshHostName d
+	, T.pack ":"
+	, sshDirectory d
+	]
+
 {- Try to ssh into the gitlab server, verify we can access the repository,
  - and get the uuid of the repository, if it already has one.
  -
@@ -735,8 +750,8 @@ testGitLabUrl glu = case parseGitLabUrl glu of
 		, Param (fromRef Annex.Branch.name)
 		]
 
-gitLabUrlAForm :: AForm Handler GitLabUrl
-gitLabUrlAForm = GitLabUrl <$> areq check_input (bfs "SSH clone url") Nothing
+gitLabUrlAForm :: Maybe GitLabUrl -> AForm Handler GitLabUrl
+gitLabUrlAForm defval = GitLabUrl <$> areq check_input (bfs "SSH clone url") (unGitLabUrl <$> defval)
   where
 	check_input = checkBool (isJust . parseGitLabUrl . GitLabUrl)
 		badGitLabUrl textField
@@ -744,9 +759,13 @@ gitLabUrlAForm = GitLabUrl <$> areq check_input (bfs "SSH clone url") Nothing
 getAddGitLabR :: Handler Html
 getAddGitLabR = postAddGitLabR
 postAddGitLabR :: Handler Html
-postAddGitLabR = sshConfigurator $ do
+postAddGitLabR = promptGitLab Nothing
+
+promptGitLab :: Maybe GitLabUrl -> Handler Html
+promptGitLab defval = sshConfigurator $ do
 	((result, form), enctype) <- liftH $
-		runFormPostNoToken $ renderBootstrap3 bootstrapFormLayout gitLabUrlAForm
+		runFormPostNoToken $ renderBootstrap3 bootstrapFormLayout $
+			gitLabUrlAForm defval
 	case result of
 		FormSuccess gitlaburl -> do
 			(status, msshdata, u) <- liftAnnex $ testGitLabUrl gitlaburl
@@ -757,3 +776,6 @@ postAddGitLabR = sshConfigurator $ do
 		_ -> showform form enctype UntestedServer
   where
 	showform form enctype status = $(widgetFile "configurators/gitlab.com/add")
+
+enableGitLab :: SshData -> Handler Html
+enableGitLab = promptGitLab . Just . toGitLabUrl
diff --git a/debian/changelog b/debian/changelog
index 4541a68..7ca0944 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+git-annex (5.20150728) UNRELEASED; urgency=medium
+
+  * webapp: Support enabling known gitlab.com remotes.
+
+ -- Joey Hess <id@joeyh.name>  Mon, 27 Jul 2015 15:57:07 -0400
+
 git-annex (5.20150727) unstable; urgency=medium
 
   * Fix bug that prevented uploads to remotes using new-style chunking
diff --git a/doc/bugs/enabling_existing_gitlab_repo_in_webapp_broken.mdwn b/doc/bugs/enabling_existing_gitlab_repo_in_webapp_broken.mdwn
index e04a806..35ebc40 100644
--- a/doc/bugs/enabling_existing_gitlab_repo_in_webapp_broken.mdwn
+++ b/doc/bugs/enabling_existing_gitlab_repo_in_webapp_broken.mdwn
@@ -4,3 +4,5 @@ work.
 This is a SMOP; it needs to detect that the repo is on gitlab and use a
 custom enabling process and no the generic one, which doesn't work.
 --[[Joey]]
+
+> [[fixed|done]] --[[Joey]]

more info
diff --git a/doc/bugs/gitlab_repos_cannot_use_gcrypt.mdwn b/doc/bugs/gitlab_repos_cannot_use_gcrypt.mdwn
index 06ea255..732d1e3 100644
--- a/doc/bugs/gitlab_repos_cannot_use_gcrypt.mdwn
+++ b/doc/bugs/gitlab_repos_cannot_use_gcrypt.mdwn
@@ -10,3 +10,13 @@ gcryptsetup fails with "gcryptsetup refusing to run; this repository already has
 This does not happen when I try the same setup on a self-hosted repo.
 Unsure what is causing git-annex-shell to behave this way on gitlab.
 --[[Joey]]
+
+> Here's a minimal way to reproduce this problem:
+>
+> 1. Make a new, empty repository on gitlab.com.
+> 2. Run command: ssh git@gitlab.com git-annex-shell 'gcryptsetup' '/~/username/reponame.git' ':id:dummy'
+> 
+> Leads to the failure as described above. But, the repo is new and empty
+> and has not had any opportunity to get a git-annex uuid set..
+> 
+> I wonder what version of git-annex gitlab.com is running? --[[Joey]]

add news item for git-annex 5.20150727
diff --git a/doc/news/version_5.20150522.mdwn b/doc/news/version_5.20150522.mdwn
deleted file mode 100644
index a14c1a3..0000000
--- a/doc/news/version_5.20150522.mdwn
+++ /dev/null
@@ -1,30 +0,0 @@
-git-annex 5.20150522 released with [[!toggle text="these changes"]]
-[[!toggleable text="""
-   * import: Refuse to import files that are within the work tree, as that
-     does not make sense and could cause data loss.
-   * drop: Now supports --all, --unused, and --key.
-   * drop: Now defaults to --all when run in a bare repository.
-     (Previously, did nothing when run in a bare repository.)
-   * get, move, copy, mirror: Concurrent transfers are now supported!
-     For example: git-annex get -J10
-     However, progress bars are not yet displayed for concurrent transfers,
-     pending an updated version of the ascii-progress library.
-   * --quiet now makes progress output by rsync, wget, etc be quiet too.
-   * Take space that will be used by other running downloads into account when
-     checking annex.diskreserve.
-   * Avoid accumulating transfer failure log files unless the assistant is
-     being used.
-   * Fix an unlikely race that could result in two transfers of the same key
-     running at once.
-   * Stale transfer lock and info files will be cleaned up automatically
-     when get/unused/info commands are run.
-   * unused: Add --used-refspec option and annex.used-refspec, which can
-     specify a set of refs to consider used, rather than the default of
-     considering all refs used.
-   * webapp: Fix zombie xdg-open process left when opening file browser.
-     Closes: #[785498](http://bugs.debian.org/785498)
-   * Safer posix fctnl locking implementation, using lock pools and STM.
-   * Build documentation with TZ=UTC for reproducible builds. See #785736.
-   * OSX: Corrected the location of trustedkeys.gpg, so the built-in
-     upgrade code will find it. Fixes OSX upgrade going forward, but
-     older versions won't upgrade themselves due to this problem."""]]
\ No newline at end of file
diff --git a/doc/news/version_5.20150727.mdwn b/doc/news/version_5.20150727.mdwn
new file mode 100644
index 0000000..9bbe6c3
--- /dev/null
+++ b/doc/news/version_5.20150727.mdwn
@@ -0,0 +1,35 @@
+git-annex 5.20150727 released with [[!toggle text="these changes"]]
+[[!toggleable text="""
+   * Fix bug that prevented uploads to remotes using new-style chunking
+     from resuming after the last successfully uploaded chunk.
+   * Switched option parsing to use optparse-applicative. This was a very large
+     and invasive change, and may have caused some minor behavior changes to
+     edge cases of option parsing. (For example, the metadata command no
+     longer accepts the combination of --get and --set, which never actually
+     worked.)
+   * Bash completion file is now included in the git-annex source tree,
+     and installed into Debian package (and any other packages built using make
+     install). This bash completion is generated by the option parser, so it
+     covers all commands, all options, and will never go out of date!
+   * As well as tab completing "git-annex" commands, "git annex" will also tab
+     complete. However, git's bash completion script needs a patch,
+     which I've submitted, for this to work prefectly.
+   * version --raw now works when run outside a git repository.
+   * assistant --startdelay now works when run outside a git repository.
+   * dead now accepts multiple --key options.
+   * addurl now accepts --prefix and --suffix options to adjust the
+     filenames used.
+   * sync --content: Fix bug that caused files to be uploaded to eg,
+     more archive remotes than wanted copies, only to later be dropped
+     to satisfy the preferred content settings.
+   * importfeed: Improve detection of known items whose url has changed,
+     and avoid adding redundant files. Where before this only looked at
+     permalinks in rss feeds, it now also looks at guids.
+   * importfeed: Look at not only permalinks, but now also guids
+     to identify previously downloaded files.
+   * Webapp: Now features easy setup of git-annex repositories on gitlab.com.
+   * Adjust debian build deps: The webapp can now build on arm64, s390x
+     and hurd-i386. WebDAV support is also available on those architectures.
+   * Debian package now maintained by Richard Hartmann.
+   * Support building without persistent database on for systems that
+     lack TH. This removes support for incremental fsck."""]]
\ No newline at end of file

open and close gitlab issues
diff --git a/doc/bugs/enabling_existing_gitlab_repo_in_webapp_broken.mdwn b/doc/bugs/enabling_existing_gitlab_repo_in_webapp_broken.mdwn
new file mode 100644
index 0000000..e04a806
--- /dev/null
+++ b/doc/bugs/enabling_existing_gitlab_repo_in_webapp_broken.mdwn
@@ -0,0 +1,6 @@
+Enabling a gitlab repo that was set up elsewhere in the webapp doesn't
+work.
+
+This is a SMOP; it needs to detect that the repo is on gitlab and use a
+custom enabling process and no the generic one, which doesn't work.
+--[[Joey]]
diff --git a/doc/bugs/gitlab_repos_cannot_use_gcrypt.mdwn b/doc/bugs/gitlab_repos_cannot_use_gcrypt.mdwn
new file mode 100644
index 0000000..06ea255
--- /dev/null
+++ b/doc/bugs/gitlab_repos_cannot_use_gcrypt.mdwn
@@ -0,0 +1,12 @@
+It's not possible to use gcrypt with gitlab repos, despite the webapp
+currently offering this as an option. The resulting remote works as far as
+pushes go, but fails with an error "Failed to connect to remote to set it
+up."
+
+It seems that the gitlab repo is somehow in a state where git-annex-shell
+configlist reports it's not yet a git-annex repo, but git-annex-shell
+gcryptsetup fails with "gcryptsetup refusing to run; this repository already has a git-annex uuid!"
+
+This does not happen when I try the same setup on a self-hosted repo.
+Unsure what is causing git-annex-shell to behave this way on gitlab.
+--[[Joey]]
diff --git a/doc/todo/Add_gitlab.com_as_cloud_provider.mdwn b/doc/todo/Add_gitlab.com_as_cloud_provider.mdwn
index 33c5c71..65c14b7 100644
--- a/doc/todo/Add_gitlab.com_as_cloud_provider.mdwn
+++ b/doc/todo/Add_gitlab.com_as_cloud_provider.mdwn
@@ -5,3 +5,6 @@ Hi,
 Gitlab.com and Gitlab enterprise edition, but unfortunately not Gitlab community edition, now [provides git annex support](https://about.gitlab.com/2015/02/17/gitlab-annex-solves-the-problem-of-versioning-large-binaries-with-git/).  It works fairly based for the repos I have enabled it on.  At the moment it's free, but one may have to pay for repos larger than 5Gb [in the future](https://about.gitlab.com/2015/02/22/gitlab-7-8-released/#comment-1870271594).
 
 Perhaps gitlab.com should be added to preconfigured cloud providers?
+
+> [[done]] although there are a few known bugs in the webapp's
+> implementation. --[[Joey]]

Added a comment: Any more info needed
diff --git a/doc/bugs/metadata_view_does_not_vpop_to_original_view/comment_8_ef3e8e1c47984fc674e58646052205ef._comment b/doc/bugs/metadata_view_does_not_vpop_to_original_view/comment_8_ef3e8e1c47984fc674e58646052205ef._comment
new file mode 100644
index 0000000..df5515f
--- /dev/null
+++ b/doc/bugs/metadata_view_does_not_vpop_to_original_view/comment_8_ef3e8e1c47984fc674e58646052205ef._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="frederik@ffbea6a549cb3f460d110386c0f634c1ddc6a68a"
+ nickname="frederik"
+ subject="Any more info needed"
+ date="2015-07-27T13:47:11Z"
+ content="""
+Hi Joey, while I was able to recover from the issue mentioned above, I have yet to try using the metadata views again out of uncertainty about the root cause of the problem I encountered. Is there anything more I could provide to determine what caused this problem and how to avoid it next time I try?
+"""]]

Added a comment: Correct way to install git-annex directly through cabal.
diff --git a/doc/install/ArchLinux/comment_7_97d611f1ae6d4fbe91f84f9fe739f368._comment b/doc/install/ArchLinux/comment_7_97d611f1ae6d4fbe91f84f9fe739f368._comment
new file mode 100644
index 0000000..31f153b
--- /dev/null
+++ b/doc/install/ArchLinux/comment_7_97d611f1ae6d4fbe91f84f9fe739f368._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="dropped"
+ subject="Correct way to install git-annex directly through cabal."
+ date="2015-07-27T12:01:34Z"
+ content="""
+The effective way to install git-annex and resolve dependencies:
+
+    $ sudo pacman -S gsasl git rsync curl wget gnupg openssh cabal-install
+    $ cabal update
+    $ cabal install c2hs
+    $ cabal install git-annex --bindir=$HOME/bin
+    $ sudo cp ~/bin/git-annex /usr/lib/git-core
+"""]]

diff --git a/doc/forum/Full_restore_from_an_encrypted_special_remote.mdwn b/doc/forum/Full_restore_from_an_encrypted_special_remote.mdwn
new file mode 100644
index 0000000..d724929
--- /dev/null
+++ b/doc/forum/Full_restore_from_an_encrypted_special_remote.mdwn
@@ -0,0 +1,3 @@
+If I lose all my git-annex repositories is it possible to restore the content of a repo from a special remote in which encryption was enabled? I know git-annex isn't designed to be a backup solution but more for the archive and/or nomad use case. I do like the idea of being able to restore the files from an S3 special remote though. I imagine part of the answer to this question has to do with what type of encryption is used (hybrid and shared key rely on information stored in the repo but pubkey doesn't rely on the repo at all) and would probably be easier if there were an option to disable hashing the filenames of the files (less secure, but maybe ok in some cases).
+
+Thoughts?

Added a comment: small correction to the above
diff --git a/doc/bugs/Default_startup_command/comment_2_296de7f38161ebc21da954d46c924c98._comment b/doc/bugs/Default_startup_command/comment_2_296de7f38161ebc21da954d46c924c98._comment
new file mode 100644
index 0000000..af5cfc4
--- /dev/null
+++ b/doc/bugs/Default_startup_command/comment_2_296de7f38161ebc21da954d46c924c98._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="git-annex@53a027ebda399714df9272a135f22ac774f3c9f1"
+ nickname="git-annex"
+ subject="small correction to the above"
+ date="2015-07-26T10:33:28Z"
+ content="""
+i can not start the webapp via the menu (firefox opens but cant connect to the webapp) but if i do git annex webapp manually in the terminal it works as expected
+"""]]

Added a comment: i can second this
diff --git a/doc/bugs/Default_startup_command/comment_1_2d63fb301586c9a97ceff1d1b9fafbee._comment b/doc/bugs/Default_startup_command/comment_1_2d63fb301586c9a97ceff1d1b9fafbee._comment
new file mode 100644
index 0000000..47487f0
--- /dev/null
+++ b/doc/bugs/Default_startup_command/comment_1_2d63fb301586c9a97ceff1d1b9fafbee._comment
@@ -0,0 +1,29 @@
+[[!comment format=mdwn
+ username="git-annex@53a027ebda399714df9272a135f22ac774f3c9f1"
+ nickname="git-annex"
+ subject="i can second this"
+ date="2015-07-26T10:29:32Z"
+ content="""
+I have the same behaviour on CM11 4.4.4 on a Moto G as well.
+When i installed git annex i would be greeted by the same message, but then could start the webapp from the menu successfully.
+i then proceeded to setup my repo, which synced flawlessly, if i had started the webapp as stated above.
+however my files were never automatically synced when just starting the app (terminal window).
+
+Therefore i resorted to \"cd\" to my repo and \"git annex add *\" and \"git annex sync --content\" every time i wanted to sync.
+
+i tried changing the startup command to \"git annex assistant --autostart\", \"git annex assistant --autostart --foreground\", \"cd ../DCIM;git annex sync --content\", \"echo test\" but nothing seems to start (not quite sure how to check for that).
+
+for my shell i had the default/data/data/ga.androidterm/lib/lib.start.so and /data/data/ga.androidterm/runshell if that makes any difference?
+
+not sure if that's related
+when trying to manually invoke \"git annex --assistant [--foreground]\" i get:
+
+    git annex autostart in /sdcard/DCIM
+    usage: ionice <pid> [none|rt|be|idle] [prio]
+    failed
+
+and back to prompt. Not sure if this is CM(11) only?
+
+my git annex version is: 5.20150527-gfc92f13 for android 4.3 and 4.4. if you need more information i'll be happy to provide it, to get this out of the way :D
+
+"""]]

doc/*.mdwn: Minor fixes (typos, letter case)
diff --git a/doc/git-annex-importfeed.mdwn b/doc/git-annex-importfeed.mdwn
index 26401f4..241d369 100644
--- a/doc/git-annex-importfeed.mdwn
+++ b/doc/git-annex-importfeed.mdwn
@@ -15,7 +15,7 @@ them.
 
 When quvi is installed, links in the feed are tested to see if they
 are on a video hosting site, and the video is downloaded. This allows
-importing e.g., youtube playlists.
+importing e.g., YouTube playlists.
 
 To make the import process add metadata to the imported files from the feed,
 `git config annex.genmetadata true`
diff --git a/doc/git-annex.mdwn b/doc/git-annex.mdwn
index 73894c0..a780728 100644
--- a/doc/git-annex.mdwn
+++ b/doc/git-annex.mdwn
@@ -1059,7 +1059,7 @@ Here are all the supported configuration settings.
 * `remote.<name>.annex-rsync-options`
 
   Options to use when using rsync
-  to or from this remote. For example, to force ipv6, and limit
+  to or from this remote. For example, to force IPv6, and limit
   the bandwidth to 100Kbyte/s, set it to `-6 --bwlimit 100`
 
 * `remote.<name>.annex-rsync-upload-options`
@@ -1110,7 +1110,7 @@ Here are all the supported configuration settings.
 * `annex.web-options`
 
   Options to pass when running wget or curl.
-  For example, to force ipv4 only, set it to "-4"
+  For example, to force IPv4 only, set it to "-4"
 
 * `annex.quvi-options`
 
diff --git a/doc/preferred_content.mdwn b/doc/preferred_content.mdwn
index 33d327e..e6244bd 100644
--- a/doc/preferred_content.mdwn
+++ b/doc/preferred_content.mdwn
@@ -98,7 +98,7 @@ below to get the full story.
   copies, on remotes in the specified group. For example,
   `copies=archive:2`
 
-  Preferred content expressions have no equivilant to the `--in`
+  Preferred content expressions have no equivalent to the `--in`
   option, but groups can accomplish similar things. You can add
   repositories to groups, and match against the groups in a
   preferred content expression. So rather than `--in=usbdrive`,
diff --git a/doc/publicrepos.mdwn b/doc/publicrepos.mdwn
index 891c52f..e54e0b9 100644
--- a/doc/publicrepos.mdwn
+++ b/doc/publicrepos.mdwn
@@ -30,8 +30,8 @@ the public repositories that you can clone to try out git-annex.
 
 * [ccc-media-annex](https://github.com/ntnn/ccc-media-annex)  
   `git clone https://github.com/ntnn/ccc-media-annex`  
-  git-annex repository using [the CDN](http://media.ccc.de/) of the german [CCC](http://www.ccc.de/).  
-  Contains a lot of talks (mostly in german) held on events from the CCC as well as other stuff.
+  git-annex repository using [the CDN](http://media.ccc.de/) of the German [CCC](http://www.ccc.de/).  
+  Contains a lot of talks (mostly in German) held on events from the CCC as well as other stuff.
 
 This is a wiki -- add your own public repository to the list!
 See [[tips/centralized_git_repository_tutorial]].

diff --git a/doc/bugs/rsync_remote_with_-J2_fails.mdwn b/doc/bugs/rsync_remote_with_-J2_fails.mdwn
new file mode 100644
index 0000000..93b3176
--- /dev/null
+++ b/doc/bugs/rsync_remote_with_-J2_fails.mdwn
@@ -0,0 +1,55 @@
+### Please describe the problem.
+
+Trying to `git annex copy` to an rsync special remote with the -J flag fails with a lot of errors. (And is slow without it).
+
+### What steps will reproduce the problem?
+
+$ git annex copy --to rsync-remote -J2
+
+### What version of git-annex are you using? On what operating system?
+
+5.20150710-g8fd7052 on Ubuntu.
+
+### Please provide any additional information below.
+
+[[!format sh """
+$ git annex copy --to freenas-rsync -J2
+E: file has vanished: "/media/depot/annex/.git/annex/tmp/rsynctmp/29637/caa/2d1/SHA256E-s4244--4ec1ea09c7605a589a9bf6cd927e96737c512d17d8053cbfaf0dcd364702400c.txt/SHA256E-s4244--4ec1ea09c7605a589a9bf6cd927e96737c512d17d8053cbfaf0dcd364702400c.txt"
+E: rsync warning: some files vanished before they could be transferred (code 24) at main.c(1183) [sender=3.1.1]
+E: rsync: change_dir "/media/depot/annex//.git/annex/tmp/rsynctmp/29637" failed: No such file or directory (2)
+E: rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1183) [sender=3.1.1]
+  .git/annex/tmp/rsynctmp/29637/c17: removeDirectory: does not exist (No such file or directory)
+  .git/annex/tmp/rsynctmp/29637: getDirectoryContents: does not exist (No such file or directory)
+  .git/annex/tmp/rsynctmp/29637/67e: removeLink: does not exist (No such file or directory)
+  .git/annex/tmp/rsynctmp/29637: getDirectoryContents: does not exist (No such file or directory)
+  .git/annex/tmp/rsynctmp/29637: getDirectoryContents: does not exist (No such file or directory)
+  .git/annex/tmp/rsynctmp/29637/49e/833: removeLink: inappropriate type (Is a directory)
+^C
+
+J1 hangs a long time:
+$ git annex copy --to freenas-rsync -J1
+^C
+
+Works without J flag:
+$ git annex copy --to freenas-rsync 
+copy GarageBand/._.DS_Store (checking freenas-rsync...) ok
+copy GarageBand/._My Song.band (checking freenas-rsync...) ok
+copy GarageBand/._code monkey.band (checking freenas-rsync...) ok
+copy GarageBand/._first of may.band (checking freenas-rsync...) ok
+
+Version:
+$ git annex version
+git-annex version: 5.20150710-g8fd7052
+build flags: Assistant Webapp Webapp-secure Pairing Testsuite S3 WebDAV Inotify DBus DesktopNotify XMPP DNS Feeds Quvi TDFA
+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
+
+Repo config:
+[remote "freenas-rsync"]
+	annex-rsyncurl = freenas:/mnt/tank/home/jnewsome/annex-rsync-backend
+	annex-uuid = f05581cc-7236-41ed-9db8-49424f863307
+
+"""]]

Added a comment: How to debug?
diff --git a/doc/bugs/OSX:_Assistant_leaves_repo_in_inconsistent_state/comment_5_4343ee35e4091fc50268f9fc611f5148._comment b/doc/bugs/OSX:_Assistant_leaves_repo_in_inconsistent_state/comment_5_4343ee35e4091fc50268f9fc611f5148._comment
new file mode 100644
index 0000000..0ec1370
--- /dev/null
+++ b/doc/bugs/OSX:_Assistant_leaves_repo_in_inconsistent_state/comment_5_4343ee35e4091fc50268f9fc611f5148._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="Marco"
+ subject="How to debug?"
+ date="2015-07-25T18:10:08Z"
+ content="""
+I want to give the two assistants one more try with the newest version.
+
+But I want the assistant not to try a repair once a failure is detected. I want to check the state of the repository to get a clue what goes wrong.
+As I understood the code there is no configuration to prevent the repair. Am I wrong? If not I could try to introduce one if it makes sense.
+"""]]

Added a comment
diff --git a/doc/forum/Windows_-_You_don__39__t_have_access/comment_6_7656eb72bb9e39db59092557c57a2489._comment b/doc/forum/Windows_-_You_don__39__t_have_access/comment_6_7656eb72bb9e39db59092557c57a2489._comment
new file mode 100644
index 0000000..c78501a
--- /dev/null
+++ b/doc/forum/Windows_-_You_don__39__t_have_access/comment_6_7656eb72bb9e39db59092557c57a2489._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="fusionx86@2cab672ef75a8502e153ceb90177dde38985dba9"
+ nickname="fusionx86"
+ subject="comment 6"
+ date="2015-07-24T18:10:20Z"
+ content="""
+Any other ideas on this problem? I was planning to use annex for large/binary files, but we have a lot of developers that would need to run it on Windows as well and I'm not sure how to roll it out when I can't get it working myself on a Windows build server. I think I saw somewhere that you have tested it on WinXP. Any chance you could download an evaluation copy of a later version (Win7/8.1/2008R2/2012R2) and try again? Annex is a great tool and would like to incorporate it into our SCM and deployment workflow if possible. Thanks.
+"""]]

diff --git a/doc/forum/git-annex_does_not_protect_files_on_NTFS-Fuse.mdwn b/doc/forum/git-annex_does_not_protect_files_on_NTFS-Fuse.mdwn
new file mode 100644
index 0000000..e8084f6
--- /dev/null
+++ b/doc/forum/git-annex_does_not_protect_files_on_NTFS-Fuse.mdwn
@@ -0,0 +1,8 @@
+I've read that git-annex probes the host filesystem to determine whether it has the necessary features for an indirect annex. Indirect annexes are supposed to protect annexed files from accidental editing:
+
+    # echo oops > my_cool_big_file
+    bash: my_cool_big_file: Permission denied
+
+I have an NTFS drive to share files between my Windows and Linux systems (dual boot). On Linux fuse sets the file permissions to rwx for the user and nothing for the rest, and this cannot be changed. Files in the annex can be modified as in the above example.
+
+If git-annex detects whether a fs can handle indirect annexes or not, I suggest checking for this case if possible.

Added a comment
diff --git a/doc/bugs/s3_InternalIOException__63__/comment_5_134d1d0ad9f59a2b7498d1ed335cf91a._comment b/doc/bugs/s3_InternalIOException__63__/comment_5_134d1d0ad9f59a2b7498d1ed335cf91a._comment
new file mode 100644
index 0000000..59f6c1b
--- /dev/null
+++ b/doc/bugs/s3_InternalIOException__63__/comment_5_134d1d0ad9f59a2b7498d1ed335cf91a._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="anarcat"
+ subject="comment 5"
+ date="2015-07-23T19:44:10Z"
+ content="""
+any update of this?
+
+i still can't upload those files, while *other* files get uploaded to S3 fine. really strange. how can i reset the state of this?
+"""]]

Added a comment
diff --git a/doc/forum/Exclude_specific_files_from_a_special_remote/comment_2_671790686bd4724aadcadd8d8aad2c98._comment b/doc/forum/Exclude_specific_files_from_a_special_remote/comment_2_671790686bd4724aadcadd8d8aad2c98._comment
new file mode 100644
index 0000000..8ad63b9
--- /dev/null
+++ b/doc/forum/Exclude_specific_files_from_a_special_remote/comment_2_671790686bd4724aadcadd8d8aad2c98._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Oliv5@43a03b767570a41ba84b9e5c72f3c9816adb22e2"
+ nickname="Oliv5"
+ subject="comment 2"
+ date="2015-07-23T19:07:58Z"
+ content="""
+Yes, this is exactly what I need. It works well indeed. Thks. I didnt understand how this worked before.
+"""]]

caps
diff --git a/doc/tips/centralized_git_repository_tutorial.mdwn b/doc/tips/centralized_git_repository_tutorial.mdwn
index 945f95c..4019c11 100644
--- a/doc/tips/centralized_git_repository_tutorial.mdwn
+++ b/doc/tips/centralized_git_repository_tutorial.mdwn
@@ -4,12 +4,12 @@ git-annex can also be used with a centralized git repository.
 We have separate tutorials depending on where the centralized git
 repository is hosted.
 
-* [[centralized_git_repository_tutorial/on_GitHub]] --
+* [[centralized_git_repository_tutorial/On_GitHub]] --
   However, GitHub does not currently let git-annex
   store the contents of large files there. So, things get a little more
   complicated when using it.
 
-* [[centralized_git_repository_tutorial/on_GitLab]] -- 
+* [[centralized_git_repository_tutorial/On_GitLab]] -- 
   This service is similar to GitHub, but supports
   git-annex.
 

reword
diff --git a/doc/tips/centralized_git_repository_tutorial.mdwn b/doc/tips/centralized_git_repository_tutorial.mdwn
index d12593b..945f95c 100644
--- a/doc/tips/centralized_git_repository_tutorial.mdwn
+++ b/doc/tips/centralized_git_repository_tutorial.mdwn
@@ -4,14 +4,15 @@ git-annex can also be used with a centralized git repository.
 We have separate tutorials depending on where the centralized git
 repository is hosted.
 
-* You can use GitHub. However, GitHub does not currently let git-annex
+* [[centralized_git_repository_tutorial/on_GitHub]] --
+  However, GitHub does not currently let git-annex
   store the contents of large files there. So, things get a little more
-  complicated. See [[centralized_git_repository_tutorial/on_GitHub]]
-  for a tutorial for using git-annex with GitHub.
+  complicated when using it.
 
-* You can use GitLab. This service is similar to GitHub, but supports
-  git-annex. See [[centralized_git_repository_tutorial/on_GitLab]]
+* [[centralized_git_repository_tutorial/on_GitLab]] -- 
+  This service is similar to GitHub, but supports
+  git-annex.
 
-* You can use your own git server, which can be any unix system with
-  ssh and git and git-annex installed. A VPS, a home server, etc.
-  See [[[[centralized_git_repository_tutorial/on_your_own_server]].
+* [[centralized_git_repository_tutorial/On_your_own_server]] --
+  use any unix system with ssh and git and git-annex installed.
+  A VPS, a home server, etc.

devblog
diff --git a/doc/devblog/day_302-305__gitlab.mdwn b/doc/devblog/day_302-305__gitlab.mdwn
new file mode 100644
index 0000000..05048eb
--- /dev/null
+++ b/doc/devblog/day_302-305__gitlab.mdwn
@@ -0,0 +1,30 @@
+I've been working on adding GitLab support to the webapp for the past 3
+days.
+
+That's not the only thing I've been working on; I've continued to work on
+the older parts of the backlog, which is now shrunk to 91 messages, and
+made some minor improvements and bugfixes.
+
+But, GitLab support in the webapp has certianly taken longer than I'd have
+expected. Only had to write 82 lines of GitLab specific code so far, but it
+went slowly. The user will need to cut and paste repository url and
+ssh public key back and forth between the webapp and GitLab for now. And
+the way GitLab repositories use git-annex makes it a bit tricky to set up;
+in one case the webapp has to do a forced push dry run to check if the
+repository on GitLab can be accessed by ssh.
+
+I found a way to adapt the existing code for setting up a ssh server to
+also support GitLab, so beyond the repo url prompt and ssh key setup,
+everything will be reused. I have something that works now, but there are
+lots of cases to test (encrypted repositories, enabling existing
+repositories, etc), so will need to work on it a bit more before merging
+this feature.
+
+Also took some time to split the [centralized git repository tutorial](http://git-annex.branchable.com/tips/centralized_git_repository_tutorial/)
+into three parts, one for each of GitHub, GitLab, and self-administered servers.
+
+----
+
+The git-annex package in Debian unstable hasn't been updated for 8 months.
+This is about to change; Richard Hartmann has stepped up and is preparing
+an upload of a recent version. Yay!

split centralized_git_repository_tutorial into 3
diff --git a/doc/tips/centralized_git_repository_tutorial.mdwn b/doc/tips/centralized_git_repository_tutorial.mdwn
index e646ed0..d12593b 100644
--- a/doc/tips/centralized_git_repository_tutorial.mdwn
+++ b/doc/tips/centralized_git_repository_tutorial.mdwn
@@ -1,142 +1,17 @@
 The [[walkthrough]] builds up a decentralized git repository setup, but
-git-annex can also be used with a centralized bare repository, just like
-git can. This tutorial shows how to set up a centralized repository hosted on
-GitHub on GitLab or your own git server.
+git-annex can also be used with a centralized git repository. 
 
-## set up the repository, and make a checkout
+We have separate tutorials depending on where the centralized git
+repository is hosted.
 
-I've created a repository for technical talk videos, which you can
-[fork on Github](https://github.com/joeyh/techtalks).
-Or make your own repository on GitHub (or GitLab elsewhere) now.
+* You can use GitHub. However, GitHub does not currently let git-annex
+  store the contents of large files there. So, things get a little more
+  complicated. See [[centralized_git_repository_tutorial/on_GitHub]]
+  for a tutorial for using git-annex with GitHub.
 
-On your laptop, [[install]] git-annex, and clone the repository:
+* You can use GitLab. This service is similar to GitHub, but supports
+  git-annex. See [[centralized_git_repository_tutorial/on_GitLab]]
 
-	# git clone git@github.com:joeyh/techtalks.git
-	# cd techtalks
-
-Tell git-annex to use the repository, and describe where this clone is
-located:
-
-	# git annex init 'my laptop'
-	init my laptop ok
-
-Let's tell git-annex that GitHub doesn't support running git-annex-shell there.
-
-	# git config remote.origin.annex-ignore true
-
-This means you can't store annexed file *contents* on GitHub; it would
-really be better to host the bare repository on your own server, which
-would not have this limitation. (If you want to do that, check out
-[[using_gitolite_with_git-annex]].) Or, you could use GitLab, which
-*does* [support git-annex on their servers](https://about.gitlab.com/2015/02/17/gitlab-annex-solves-the-problem-of-versioning-large-binaries-with-git/).
-
-## add files to the repository
-
-Add some files, obtained however.
-
-	# youtube-dl -t 'http://www.youtube.com/watch?v=b9FagOVqxmI'
-	# git annex add *.mp4
-	add Haskell_Amuse_Bouche-b9FagOVqxmI.mp4 (checksum) ok
-	(Recording state in git...)
-	# git commit -m "added a video. I have not watched it yet but it sounds interesting"
-
-This file is available directly from the web; so git-annex can download it:
-
-	# git annex addurl http://kitenet.net/~joey/screencasts/git-annex_coding_in_haskell.ogg
-	addurl kitenet.net_~joey_screencasts_git-annex_coding_in_haskell.ogg
-	(downloading http://kitenet.net/~joey/screencasts/git-annex_coding_in_haskell.ogg ...)
-	(checksum...) ok
-	(Recording state in git...)
-	# git commit -a -m 'added a screencast I made'
-
-Feel free to rename the files, etc, using normal git commands:
-
-	# git mv Haskell_Amuse_Bouche-b9FagOVqxmI.mp4 Haskell_Amuse_Bouche.mp4
-	# git mv kitenet.net_~joey_screencasts_git-annex_coding_in_haskell.ogg git-annex_coding_in_haskell.ogg
-	# git commit -m 'better filenames'
-
-Now push your changes back to the central repository. As well as pushing
-the master branch, remember to push the git-annex branch, which is used to
-track the file contents.
-
-	# git push origin master git-annex
-	To git@github.com:joeyh/techtalks.git
-	 * [new branch]      master -> master
-	 * [new branch]      git-annex -> git-annex
-
-That push went fast, because it didn't upload large videos to GitHub.
-To check this, you can ask git-annex where the contents of the videos are:
-
-	# git annex whereis
-	whereis Haskell_Amuse_Bouche.mp4 (1 copy) 
-	  	767e8558-0955-11e1-be83-cbbeaab7fff8 -- here
-	ok
-	whereis git-annex_coding_in_haskell.ogg (2 copies) 
-	  	00000000-0000-0000-0000-000000000001 -- web
-	   	767e8558-0955-11e1-be83-cbbeaab7fff8 -- here
-	ok
-
-## make more checkouts
-
-So far you have a central repository, and a checkout on a laptop.
-Let's make another checkout that's used as a backup. You can put it anywhere
-you like, just make it be somewhere your laptop can access. A few options:
-
-* Put it on a USB drive that you can plug into the laptop.
-* Put it on a desktop.
-* Put it on some server in the local network.
-* Put it on a remote VPS.
-
-I'll use the VPS option, but these instructions should work for
-any of the above.
-
-	# ssh server
-	server# sudo apt-get install git-annex
-
-Clone the central repository as before. (If the clone fails, you need
-to add your server's ssh public key to github -- see
-[this page](http://help.github.com/ssh-issues/).)
-
-	server# git clone git@github.com:joeyh/techtalks.git
-	server# cd techtalks
-	server# git config remote.origin.annex-ignore true
-	server# git annex init 'backup'
-	init backup (merging origin/git-annex into git-annex...) ok
-
-Notice that the server does not have the contents of any of the files yet.
-If you run `ls`, you'll see broken symlinks. We want to populate this
-backup with the file contents, by copying them from your laptop.
-
-Back on your laptop, you need to configure a git remote for the backup.
-Adjust the ssh url as needed to point to wherever the backup is. (If it
-was on a local USB drive, you'd use the path to the repository instead.)
-
-	# git remote add backup ssh://server/~/techtalks
-
-Now git-annex on your laptop knows how to reach the backup repository,
-and can do things like copy files to it:
-
-	# git annex copy --to backup git-annex_coding_in_haskell.ogg
-	copy git-annex_coding_in_haskell.ogg (checking backup...)
-	12877824   2%  255.11kB/s    00:00
-	ok
-
-You can also `git annex move` files to it, to free up space on your laptop.
-And then you can `git annex get` files back to your laptop later on, as
-desired.
-
-After you use git-annex to move files around, remember to push, 
-which will broadcast its updated location information.
-
-	# git push origin master git-annex
-
-## take it farther
-
-Of course you can create as many checkouts as you desire. If you have a
-desktop machine too, you can make a checkout there, and use `git remote
-add` to also let your desktop access the backup repository. 
-
-You can add remotes for each direct connection between machines you find you
-need -- so make the laptop have the desktop as a remote, and the desktop
-have the laptop as a remote, and then on either machine git-annex can
-access files stored on the other.
+* You can use your own git server, which can be any unix system with
+  ssh and git and git-annex installed. A VPS, a home server, etc.
+  See [[[[centralized_git_repository_tutorial/on_your_own_server]].
diff --git a/doc/tips/centralized_git_repository_tutorial/on_GitHub.mdwn b/doc/tips/centralized_git_repository_tutorial/on_GitHub.mdwn
new file mode 100644
index 0000000..4522319
--- /dev/null
+++ b/doc/tips/centralized_git_repository_tutorial/on_GitHub.mdwn
@@ -0,0 +1,129 @@
+This tutorial shows how to set up a centralized repository hosted on
+GitHub.
+
+GitHub does not currently let git-annex store the contents of large files
+there. This doesn't prevent using git-annex with GitHub, it just means you
+have to set up some other centralized location for the large files.
+
+## set up the repository, and make a checkout
+
+I've created a repository for technical talk videos, which you can
+[fork on Github](https://github.com/joeyh/techtalks).
+Or make your own repository on GitHub now.
+
+On your laptop, [[install]] git-annex, and clone the repository:
+
+	# git clone git@github.com:joeyh/techtalks.git
+	# cd techtalks
+
+Tell git-annex to use the repository, and describe where this clone is
+located:
+
+	# git annex init 'my laptop'
+	init my laptop ok
+
+## add files to the repository
+
+Add some files, obtained however.
+
+	# git annex add *.mp4
+	add Haskell_Amuse_Bouche-b9OVqxmI.mp4 (checksum) ok
+	(Recording state in git...)
+	# git commit -m "added a video. I have not watched it yet but it sounds interesting"
+
+This file is available on the web; so git-annex can download it:
+

(Diff truncated)
weird sync bug
diff --git a/doc/bugs/sync__47__git-annex_branch_not_syncing_in_the_assistant.mdwn b/doc/bugs/sync__47__git-annex_branch_not_syncing_in_the_assistant.mdwn
new file mode 100644
index 0000000..d7c679e
--- /dev/null
+++ b/doc/bugs/sync__47__git-annex_branch_not_syncing_in_the_assistant.mdwn
@@ -0,0 +1,49 @@
+### Please describe the problem.
+
+It seems that the `synced/git-annex` branch (which I am a little confused about in the first place), doesn't get synced automatically by the assistant.
+
+I was expecting the assistant to regularly do the equivalent of `git annex sync`. However, after a client pushed changes to the `git-annex` branch, I had to manually do a `git annex sync` for the changes of the `synced/git-annex` branch to be merged down into the local `git-annex`.
+
+### What steps will reproduce the problem?
+
+I have 3 machines in this setup (to simplify: there are more, but those are sufficient). Let's call them foo, bar and quux. foo and quuex are connected to bar through password-less SSH connexions.
+
+foo commits a file to git-annex. the assistant syncs that to bar in the `synced/git-annex` branch.
+
+quux syncs with bar, and seems to ignore the `synced/git-annex` branch.
+
+git-annex sync on quux syncs the `synced/git-annex` branch into the local `git-annex`, working around the issue.
+
+### What version of git-annex are you using? On what operating system?
+
+foo is 5.20150610+gitg608172f-1~ndall+1 on Debian 7.8 (wheezy).
+
+bar and quux are 5.20150409+git126-ga29f683-1~ndall+1 and 5.20150610+gitg608172f-1~ndall+1 (respectively) on Ubuntu 12.04 (precise) .
+
+### Please provide any additional information below.
+
+I guess a more general question is how and how often do those branches get merged by the assistant... it's still unclear to me how this works.
+
+[[!format sh """
+$ sudo -u www-data -H git annex sync
+(merging origin/synced/git-annex into git-annex...)
+(recording state in git...)
+commit  ok
+pull origin
+Auto packing the repository in background for optimum performance.
+See "git help gc" for manual housekeeping.
+
+Already up-to-date.
+ok
+push origin
+Counting objects: 373637, done.
+# End of transcript or log.
+"""]]
+
+This was started at 20:23 UTC. Note that the sync had run previously under the assistant:
+
+<pre>
+[2015-07-22 20:09:06 UTC] RemoteControl: Syncing with origin
+</pre>
+
+Available, as usual, for further debugging. :) -- [[anarcat]]

Added a comment
diff --git a/doc/todo/Add___39__dir__39___option_to_addurl/comment_3_62601714648631a31dee366a5a2e8f44._comment b/doc/todo/Add___39__dir__39___option_to_addurl/comment_3_62601714648631a31dee366a5a2e8f44._comment
new file mode 100644
index 0000000..d521008
--- /dev/null
+++ b/doc/todo/Add___39__dir__39___option_to_addurl/comment_3_62601714648631a31dee366a5a2e8f44._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="CandyAngel"
+ subject="comment 3"
+ date="2015-07-22T07:41:53Z"
+ content="""
+Yay! Awesome, thank you :)
+"""]]

comment
diff --git a/doc/bugs/OOM_while_configuring_git-annex/comment_1_247c4d778766c9079024c78582a69ed4._comment b/doc/bugs/OOM_while_configuring_git-annex/comment_1_247c4d778766c9079024c78582a69ed4._comment
new file mode 100644
index 0000000..19a52be
--- /dev/null
+++ b/doc/bugs/OOM_while_configuring_git-annex/comment_1_247c4d778766c9079024c78582a69ed4._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-07-22T03:36:11Z"
+ content="""
+This is due to cabal's dependency resolver not finding a solution and
+recursing too much. Passing -v3 will show what the dependency problem is.
+
+(Using stackage is a good way to avoid these kinds of dependency problems.)
+"""]]

diff --git a/doc/bugs/OOM_while_configuring_git-annex.mdwn b/doc/bugs/OOM_while_configuring_git-annex.mdwn
new file mode 100644
index 0000000..cd5d878
--- /dev/null
+++ b/doc/bugs/OOM_while_configuring_git-annex.mdwn
@@ -0,0 +1,46 @@
+### Please describe the problem.
+When running configure, the system runs out of memory:
+
+[[https://kojipkgs.fedoraproject.org//work/tasks/1587/10431587/build.log]]
+
+built with versions from:
+
+[[https://kojipkgs.fedoraproject.org//work/tasks/1587/10431587/root.log]]
+
+### What steps will reproduce the problem?
+Rebuilding on koji. Also occurs in mock. Haven't tried a naked build (yet).
+
+### What version of git-annex are you using? On what operating system?
+Currently, 5.20141203. Newest snapshot requires deps not yet packaged in Fedora.
+
+### Please provide any additional information below.
+
+[[!format sh """
++ ./Setup configure --prefix=/usr --libdir=/usr/lib --docdir=/usr/share/doc/git-annex '--libsubdir=$compiler/$pkgid' '--datasubdir=$pkgid' --ghc --enable-executable-dynamic '--ghc-options= -optc-O2 -optc-g -optc-pipe -optc-Wall -optc-Werror=format-security -optc-Wp,-D_FORTIFY_SOURCE=2 -optc-fexceptions -optc-fstack-protector-strong -optc--param=ssp-buffer-size=4 -optc-grecord-gcc-switches -optc-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -optc-m32 -optc-march=i686 -optc-mtune=atom -optc-fasynchronous-unwind-tables  -optl-Wl,-z,relro'
+  checking version...fatal: Not a git repository (or any of the parent directories): .git
+ 5.20141203
+  checking UPGRADE_LOCATION... not available
+  checking git... yes
+  checking git version... 2.4.6
+  checking cp -a... yes
+  checking cp -p... yes
+  checking cp --preserve=timestamps... yes
+  checking cp --reflink=auto... yes
+  checking xargs -0... yes
+  checking rsync... yes
+  checking curl... yes
+  checking wget... no
+  checking bup... no
+  checking nice... yes
+  checking ionice... yes
+  checking nocache... no
+  checking gpg... gpg2
+  checking lsof... not available
+  checking git-remote-gcrypt... not available
+  checking ssh connection caching... yes
+  checking sha1... sha1sum
+  checking sha256... sha256sum
+  checking sha512... sha512sum
+  checking sha224... sha224sum
+  checking sha384...Setup: out of memory (requested 1048576 bytes)
+"""]]

reorder cabal configure after install of dependencies
can't configure w/o all deps installed
diff --git a/doc/install/fromsource.mdwn b/doc/install/fromsource.mdwn
index fdb7823..1c0bc06 100644
--- a/doc/install/fromsource.mdwn
+++ b/doc/install/fromsource.mdwn
@@ -48,8 +48,8 @@ which is a more stable and consistent version of the Hackage repository.
 
 Inside the source tree, run:
 
-	cabal configure -f"-assistant -webapp -webdav -pairing -xmpp -dns"
 	cabal install -j -f"-assistant -webapp -webdav -pairing -xmpp -dns" --only-dependencies
+	cabal configure -f"-assistant -webapp -webdav -pairing -xmpp -dns"
 	cabal build -j
 	PATH=$HOME/bin:$PATH
 	cabal install --bindir=$HOME/bin
@@ -65,8 +65,8 @@ Using [Stackage](http://www.stackage.org/) is again a good idea here!
 
 Once the C libraries are installed, run inside the source tree:
 
-	cabal configure
 	cabal install -j --only-dependencies
+	cabal configure
 	cabal build -j
 	PATH=$HOME/bin:$PATH
 	cabal install --bindir=$HOME/bin

a few cleanups, and point to the main cabal instructions
diff --git a/doc/install/ScientificLinux5.mdwn b/doc/install/ScientificLinux5.mdwn
index 52d83f0..442fcb3 100644
--- a/doc/install/ScientificLinux5.mdwn
+++ b/doc/install/ScientificLinux5.mdwn
@@ -31,32 +31,7 @@ don't want things to be system wide)
 
     $ export PATH=/usr/hs/bin:$PATH
 
-Once the packages are installed and are in your execution path, using
-cabal to configure and build git-annex just makes life easier, it
-should install all the needed dependancies.
-
-    $ cabal update
-    $ git clone git://git.kitenet.net/git-annex
-    $ cd git-annex
-    $ make git-annex.1
-    $ cabal configure
-    $ cabal build
-    $ cabal install
-
-Or if you want to install it globallly for everyone (otherwise it will
-get installed into $HOME/.cabal/bin)
-
-    $ cabal install --global
-
-The above will take a while to compile and install the needed
-dependancies. I would suggest any user who does should run the tests
-that comes with git-annex to make sure everything is functioning as
-expected.
-
-I haven't had a chance or need to install git-annex on a SL6 based
-system yet, but I would assume something similar to the above steps
-would be required to do so.
-
-The above is almost a cut and paste of <http://jcftang.github.com/2012/06/15/installing-git-annex-on-sl5/>, the above could probably be refined, it was what worked for me on SL5. Please feel free to re-edit and chop out or add useless bits of text in the above!
-
-Note: from the minor testing, it appears the compiled binaries from SL5 will work on SL6.
+Once the GHC packages are installed and are in your execution path, using
+cabal to build git-annex just makes life easier, it
+should install all the needed dependancies. See "minimal build with cabal
+and stackage" in [[fromsource]] for instructions.

Added a comment: same problem
diff --git a/doc/bugs/git-annex_sync_under_windows_fails_by_using_itself_as_the_ssh_command/comment_5_f82ac380383f5116ca1c3b49cdec0648._comment b/doc/bugs/git-annex_sync_under_windows_fails_by_using_itself_as_the_ssh_command/comment_5_f82ac380383f5116ca1c3b49cdec0648._comment
new file mode 100644
index 0000000..d0a0236
--- /dev/null
+++ b/doc/bugs/git-annex_sync_under_windows_fails_by_using_itself_as_the_ssh_command/comment_5_f82ac380383f5116ca1c3b49cdec0648._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="threadshuffle"
+ subject="same problem"
+ date="2015-07-21T19:01:52Z"
+ content="""
+Hi, i have the same problem. I can't compile from source but ive looked at the process and it seems that GIT_SSH/GIT_ANNEX_SSHOPTION are set ok. Ive also looked through the source even though my haskell is quite limited and eventually managed to get something working by bypassing the
+<pre><code>g' <- addGitEnv g sshOptionsEnv val
+addGitEnv g' \"GIT_SSH\" command</code></pre>
+lines but i can't remember right now how i did it, though i remember it was by setting something similar to GIT_SSH (probably just it to 'c:\program...\git\bin\git.exe' or ssh.exe with a combination of GIT_ANNEX_SSHOPTION='').
+It didn't show the 'git annex unknown command' stuff but it did mess up the repo (said it synced the annex/direct/master synced/* branches but the changed didn't appear on the remote/origin).
+If there's anything i can try without actually compiling, im all up for it.
+"""]]

addurl now accepts --prefix and --suffix options to adjust the filenames used
diff --git a/Command/AddUrl.hs b/Command/AddUrl.hs
index 4ae80d9..adc0d3a 100644
--- a/Command/AddUrl.hs
+++ b/Command/AddUrl.hs
@@ -46,6 +46,8 @@ data AddUrlOptions = AddUrlOptions
 	{ addUrls :: CmdParams
 	, fileOption :: Maybe FilePath
 	, pathdepthOption :: Maybe Int
+	, prefixOption :: Maybe String
+	, suffixOption :: Maybe String
 	, relaxedOption :: Bool
 	, rawOption :: Bool
 	}
@@ -59,7 +61,15 @@ optParser desc = AddUrlOptions
 		))
 	<*> optional (option auto
 		( long "pathdepth" <> metavar paramNumber
-		<> help "path components to use in filename"
+		<> help "number of url path components to use in filename"
+		))
+	<*> optional (strOption
+		( long "prefix" <> metavar paramValue
+		<> help "add a prefix to the filename"
+		))
+	<*> optional (strOption
+		( long "suffix" <> metavar paramValue
+		<> help "add a suffix to the filename"
 		))
 	<*> parseRelaxedOption
 	<*> parseRawOption
@@ -80,13 +90,13 @@ seek :: AddUrlOptions -> CommandSeek
 seek o = forM_ (addUrls o) $ \u -> do
 	r <- Remote.claimingUrl u
 	if Remote.uuid r == webUUID || rawOption o
-		then void $ commandAction $ startWeb (relaxedOption o) (fileOption o) (pathdepthOption o) u
-		else checkUrl r u (fileOption o) (relaxedOption o) (pathdepthOption o)
+		then void $ commandAction $ startWeb o u
+		else checkUrl r o u
 
-checkUrl :: Remote -> URLString -> Maybe FilePath -> Bool -> Maybe Int -> Annex ()
-checkUrl r u optfile relaxed pathdepth = do
+checkUrl :: Remote -> AddUrlOptions -> URLString -> Annex ()
+checkUrl r o u = do
 	pathmax <- liftIO $ fileNameLengthLimit "."
-	let deffile = fromMaybe (urlString2file u pathdepth pathmax) optfile
+	let deffile = fromMaybe (urlString2file u (pathdepthOption o) pathmax) (fileOption o)
 	go deffile =<< maybe
 		(error $ "unable to checkUrl of " ++ Remote.name r)
 		(tryNonAsync . flip id u)
@@ -98,14 +108,15 @@ checkUrl r u optfile relaxed pathdepth = do
 		warning (show e)
 		next $ next $ return False
 	go deffile (Right (UrlContents sz mf)) = do
-		let f = fromMaybe (maybe deffile fromSafeFilePath mf) optfile
+		let f = adjustFile o (fromMaybe (maybe deffile fromSafeFilePath mf) (fileOption o))
 		void $ commandAction $
-			startRemote r relaxed f u sz
+			startRemote r (relaxedOption o) f u sz
 	go deffile (Right (UrlMulti l))
-		| isNothing optfile =
-			forM_ l $ \(u', sz, f) ->
+		| isNothing (fileOption o) =
+			forM_ l $ \(u', sz, f) -> do
+				let f' = adjustFile o (deffile </> fromSafeFilePath f)
 				void $ commandAction $
-					startRemote r relaxed (deffile </> fromSafeFilePath f) u' sz
+					startRemote r (relaxedOption o) f' u' sz
 		| otherwise = error $ unwords
 			[ "That url contains multiple files according to the"
 			, Remote.name r
@@ -151,8 +162,8 @@ downloadRemoteFile r relaxed uri file sz = do
   where
 	loguri = setDownloader uri OtherDownloader
 
-startWeb :: Bool -> Maybe FilePath -> Maybe Int -> String -> CommandStart
-startWeb relaxed optfile pathdepth s = go $ fromMaybe bad $ parseURI urlstring
+startWeb :: AddUrlOptions -> String -> CommandStart
+startWeb o s = go $ fromMaybe bad $ parseURI urlstring
   where
 	(urlstring, downloader) = getDownloader s
 	bad = fromMaybe (error $ "bad url " ++ urlstring) $
@@ -170,22 +181,22 @@ startWeb relaxed optfile pathdepth s = go $ fromMaybe bad $ parseURI urlstring
 #endif
 	regulardownload url = do
 		pathmax <- liftIO $ fileNameLengthLimit "."
-		urlinfo <- if relaxed
+		urlinfo <- if relaxedOption o
 			then pure $ Url.UrlInfo True Nothing Nothing
 			else Url.withUrlOptions (Url.getUrlInfo urlstring)
-		file <- case optfile of
+		file <- adjustFile o <$> case fileOption o of
 			Just f -> pure f
 			Nothing -> case Url.urlSuggestedFile urlinfo of
-				Nothing -> pure $ url2file url pathdepth pathmax
+				Nothing -> pure $ url2file url (pathdepthOption o) pathmax
 				Just sf -> do
 					let f = truncateFilePath pathmax $
 						sanitizeFilePath sf
 					ifM (liftIO $ doesFileExist f <||> doesDirectoryExist f)
-						( pure $ url2file url pathdepth pathmax
+						( pure $ url2file url (pathdepthOption o) pathmax
 						, pure f
 						)
 		showStart "addurl" file
-		next $ performWeb relaxed urlstring file urlinfo
+		next $ performWeb (relaxedOption o) urlstring file urlinfo
 #ifdef WITH_QUVI
 	badquvi = error $ "quvi does not know how to download url " ++ urlstring
 	usequvi = do
@@ -193,11 +204,11 @@ startWeb relaxed optfile pathdepth s = go $ fromMaybe bad $ parseURI urlstring
 			<$> withQuviOptions Quvi.forceQuery [Quvi.quiet, Quvi.httponly] urlstring
 		let link = fromMaybe badquvi $ headMaybe $ Quvi.pageLinks page
 		pathmax <- liftIO $ fileNameLengthLimit "."
-		let file = flip fromMaybe optfile $
+		let file = adjustFile o $ flip fromMaybe (fileOption o) $
 			truncateFilePath pathmax $ sanitizeFilePath $
 				Quvi.pageTitle page ++ "." ++ fromMaybe "m" (Quvi.linkSuffix link)
 		showStart "addurl" file
-		next $ performQuvi relaxed urlstring (Quvi.linkUrl link) file
+		next $ performQuvi (relaxedOption o) urlstring (Quvi.linkUrl link) file
 #else
 	usequvi = error "not built with quvi support"
 #endif
@@ -367,3 +378,9 @@ urlString2file :: URLString -> Maybe Int -> Int -> FilePath
 urlString2file s pathdepth pathmax = case Url.parseURIRelaxed s of
 	Nothing -> error $ "bad uri " ++ s
 	Just u -> url2file u pathdepth pathmax
+
+adjustFile :: AddUrlOptions -> FilePath -> FilePath
+adjustFile o = addprefix . addsuffix
+  where
+	addprefix f = maybe f (++ f) (prefixOption o)
+	addsuffix f = maybe f (f ++) (suffixOption o)
diff --git a/debian/changelog b/debian/changelog
index fa04b17..429e467 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -17,6 +17,8 @@ git-annex (5.20150714) UNRELEASED; urgency=medium
   * version --raw now works when run outside a git repository.
   * assistant --startdelay now works when run outside a git repository.
   * dead now accepts multiple --key options.
+  * addurl now accepts --prefix and --suffix options to adjust the
+    filenames used.
   * sync --content: Fix bug that caused files to be uploaded to eg,
     more archive remotes than wanted copies, only to later be dropped
     to satisfy the preferred content settings.
diff --git a/doc/git-annex-addurl.mdwn b/doc/git-annex-addurl.mdwn
index 99b1f8c..888f6ac 100644
--- a/doc/git-annex-addurl.mdwn
+++ b/doc/git-annex-addurl.mdwn
@@ -48,13 +48,22 @@ be used to get better filenames.
 
 * `--pathdepth=N`
 
-  This causes a shorter filename to be used. For example,
-   `--pathdepth=1` will use "dir/subdir/bigfile",
-   while `--pathdepth=3` will use "bigfile". 
+  Rather than basing the filename on the whole url, this causes a path to
+  be constructed, starting at the specified depth within the path of the
+  url.
+
+  For example, adding the url http://www.example.com/dir/subdir/bigfile
+  with `--pathdepth=1` will use "dir/subdir/bigfile",
+  while `--pathdepth=3` will use "bigfile". 
 
   It can also be negative; `--pathdepth=-2` will use the last
   two parts of the url.
 
+* `--prefix=foo` `--suffix=bar`
+
+  Use to adjust the filenames that are created by addurl. For example,
+  `--suffix=.mp3` can be used to add an extension to the file.
+
 # SEE ALSO
 
 [[git-annex]](1)
diff --git a/doc/todo/Add___39__dir__39___option_to_addurl.mdwn b/doc/todo/Add___39__dir__39___option_to_addurl.mdwn
index ccba479..834b630 100644
--- a/doc/todo/Add___39__dir__39___option_to_addurl.mdwn
+++ b/doc/todo/Add___39__dir__39___option_to_addurl.mdwn
@@ -1 +1,4 @@
 Is it possible to add a '--dir' option to addurl (or some other mechanic) to make git annex create the symlinks in the specified directory?
+
+> --prefix makes sense, and might as well also add --suffix. [[done]]
+> --[[Joey]]

fix typo
diff --git a/doc/git-annex-importfeed.mdwn b/doc/git-annex-importfeed.mdwn
index 1c9af2f..26401f4 100644
--- a/doc/git-annex-importfeed.mdwn
+++ b/doc/git-annex-importfeed.mdwn
@@ -34,7 +34,7 @@ To make the import process add metadata to the imported files from the feed,
   
   Other available variables for templates: feedauthor, itemauthor, itemsummary, itemdescription, itemrights, itemid, itempubdate, title, author
 
-* `--relaxed`, `--fast`, `--raw`, `--template`
+* `--relaxed`, `--fast`, `--raw`
 
   These options behave the same as when using [[git-annex-addurl]](1).
 

Added a comment
diff --git a/doc/todo/Add___39__dir__39___option_to_addurl/comment_2_15a6571d57794c3f1268c7a064e05bef._comment b/doc/todo/Add___39__dir__39___option_to_addurl/comment_2_15a6571d57794c3f1268c7a064e05bef._comment
new file mode 100644
index 0000000..95504b1
--- /dev/null
+++ b/doc/todo/Add___39__dir__39___option_to_addurl/comment_2_15a6571d57794c3f1268c7a064e05bef._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="CandyAngel"
+ subject="comment 2"
+ date="2015-07-21T12:11:45Z"
+ content="""
+I was hoping something like tar's *-C*, or unzip's *-d* options would be easy to implement, given that git-annex will already create required directories when using --pathdepth. As far as I can tell, you can't mix --file and --pathdepth.. I'd have to reimplemnt --pathdepth and the directory creation in my script, which while not a major problem in Perl (aside from reinventing a potentially inferior wheel), may be if someone is using shell scripting.
+
+Maybe this request can be more generalised to *--prefix*?
+
+Then people could use --prefix to either just prefix the filename or set a directory for it to be put into. I had a look at Command/AddUrl.hs to see how feasible that would be but I'm struggling to follow it (not knowing Haskell yet).
+
+In the meantime(?), I have made my script remember the original directory it was started in and it cd's about as needed.
+"""]]

Added a comment
diff --git a/doc/forum/Windows_-_You_don__39__t_have_access/comment_5_f9041e48b911dbdd37ad3c1bbc801709._comment b/doc/forum/Windows_-_You_don__39__t_have_access/comment_5_f9041e48b911dbdd37ad3c1bbc801709._comment
new file mode 100644
index 0000000..b77d09c
--- /dev/null
+++ b/doc/forum/Windows_-_You_don__39__t_have_access/comment_5_f9041e48b911dbdd37ad3c1bbc801709._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="fusionx86@2cab672ef75a8502e153ceb90177dde38985dba9"
+ nickname="fusionx86"
+ subject="comment 5"
+ date="2015-07-20T20:41:00Z"
+ content="""
+Also, I created git-annex-shell.exe as a copy of git-annex.exe which you recommended here: https://git-annex.branchable.com/bugs/no_git-annex_shell_on_Windows/.
+
+I also made sure UAC and Windows Firewall were disabled and they already were.
+
+What environment variables should exist to support annex? I see references to GIT_ANNEX_SSHOPTION and GIT_SSH, but those aren't currently configured on my Windows server. The git, git-annex and git-annex-shell files are in the global path and accessible from anywhere.
+"""]]

Added a comment
diff --git a/doc/forum/Windows_-_You_don__39__t_have_access/comment_4_aa28602eb0b7fa7103eaf90dc1d5cf8f._comment b/doc/forum/Windows_-_You_don__39__t_have_access/comment_4_aa28602eb0b7fa7103eaf90dc1d5cf8f._comment
new file mode 100644
index 0000000..8977843
--- /dev/null
+++ b/doc/forum/Windows_-_You_don__39__t_have_access/comment_4_aa28602eb0b7fa7103eaf90dc1d5cf8f._comment
@@ -0,0 +1,54 @@
+[[!comment format=mdwn
+ username="fusionx86@2cab672ef75a8502e153ceb90177dde38985dba9"
+ nickname="fusionx86"
+ subject="comment 4"
+ date="2015-07-20T20:14:07Z"
+ content="""
+The bug you linked does look like the same thing I'm seeing. I decided to install cygwin on the same server to see if it made a difference. It started adding files this time and I thought I had a solution, but then it threw the same error about access.
+----
+$ git annex sync --verbose
+
+  Detected a filesystem without fifo support.
+
+  Disabling ssh connection caching.
+
+  Detected a crippled filesystem.
+(merging origin/git-annex into git-annex...)
+(recording state in git...)
+
+  Enabling direct mode.
+commit  (recording state in git...)
+add Bin/FastMM_FullDebugMode.dll ok
+add Bin/Res/bar_blank.gif ok
+add Bin/Res/bar_blank_gray.gif ok
+add Bin/Res/bar_gray.gif ok
+add Bin/Res/bar_left.gif ok
+add Bin/Res/bar_middle.gif ok
+add Bin/Res/bar_right.gif ok
+add Bin/Res/btn_back_0.gif ok
+add Bin/Res/btn_back_1.gif ok
+add Bin/Res/btn_back_2.gif ok
+add Bin/Res/btn_back_3.gif ok
+...
+(recording state in git...)
+ok
+pull origin git-annex.exe: unknown command git@gitlab.company.com
+
+Usage: git-annex command [option ...]
+...
+fatal: Could not read from remote repository.
+
+Please make sure you have the correct access rights
+and the repository exists.
+
+  Pushing to origin failed.
+
+  (non-fast-forward problems can be solved by setting receive.denyNonFastforwards to false in the remote's git config)
+failed
+(recording state in git...)
+git-annex.exe: sync: 2 failed
+----
+
+So it seemed to get a little further, but still fails. The key $HOME/.ssh/id_rsa has full access to the repo and I'm able to push/pull with git just fine. Not sure what else to try for annex sync.
+
+"""]]

update
diff --git a/doc/todo/Add_gitlab.com_as_cloud_provider/comment_5_edb7d9de2ec51ab3f51a35848b63c842._comment b/doc/todo/Add_gitlab.com_as_cloud_provider/comment_5_edb7d9de2ec51ab3f51a35848b63c842._comment
new file mode 100644
index 0000000..bfa5d36
--- /dev/null
+++ b/doc/todo/Add_gitlab.com_as_cloud_provider/comment_5_edb7d9de2ec51ab3f51a35848b63c842._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2015-07-20T19:07:18Z"
+ content="""
+Update: Gitlab is working with git-annex for me now.
+"""]]

response
diff --git a/doc/forum/Windows_-_You_don__39__t_have_access/comment_3_593a8a54fa80258d5048f5c061992664._comment b/doc/forum/Windows_-_You_don__39__t_have_access/comment_3_593a8a54fa80258d5048f5c061992664._comment
new file mode 100644
index 0000000..798aa12
--- /dev/null
+++ b/doc/forum/Windows_-_You_don__39__t_have_access/comment_3_593a8a54fa80258d5048f5c061992664._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2015-07-20T19:03:58Z"
+ content="""
+Pretty sure that the only difference gitlab can see between your Windows
+and Linux boxes there is the ssh key that they're using. So, maybe you need
+to add the Windows box's ssh key to the gitlab repo, or there's a problem
+in that area.
+"""]]

Added a comment
diff --git a/doc/forum/Windows_-_You_don__39__t_have_access/comment_2_aa6ea60465df9fab7990bd6f510b74c5._comment b/doc/forum/Windows_-_You_don__39__t_have_access/comment_2_aa6ea60465df9fab7990bd6f510b74c5._comment
new file mode 100644
index 0000000..dd64dd7
--- /dev/null
+++ b/doc/forum/Windows_-_You_don__39__t_have_access/comment_2_aa6ea60465df9fab7990bd6f510b74c5._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="fusionx86@2cab672ef75a8502e153ceb90177dde38985dba9"
+ nickname="fusionx86"
+ subject="comment 2"
+ date="2015-07-20T18:59:29Z"
+ content="""
+GitLab is working fine with annex. I'm able to annex sync and sync --content on Linux and OSX without any problems. It's just Windows client I'm struggling with. I'll look at the bug you linked and post back with anything interesting.
+"""]]

sync --content: Fix bug that caused files to be uploaded to eg, more archive remotes than wanted copies, only to later be dropped to satisfy the preferred content settings.
diff --git a/Command/Sync.hs b/Command/Sync.hs
index a5b6010..3411c94 100644
--- a/Command/Sync.hs
+++ b/Command/Sync.hs
@@ -414,7 +414,7 @@ syncFile ebloom rs af k = do
 	let (have, lack) = partition (\r -> Remote.uuid r `elem` locs) rs
 
 	got <- anyM id =<< handleget have
-	putrs <- catMaybes . snd . unzip <$> (sequence =<< handleput lack)
+	putrs <- handleput lack
 
 	u <- getUUID
 	let locs' = concat [[u | got], putrs, locs]
@@ -455,12 +455,14 @@ syncFile ebloom rs af k = do
 	wantput r
 		| Remote.readonly r || remoteAnnexReadOnly (Remote.gitconfig r) = return False
 		| otherwise = wantSend True (Just k) af (Remote.uuid r)
-	handleput lack = ifM (inAnnex k)
-		( map put <$> filterM wantput lack
+	handleput lack = catMaybes <$> ifM (inAnnex k)
+		( forM lack $ \r ->
+			ifM (wantput r <&&> put r)
+				( return (Just (Remote.uuid r))
+				, return Nothing
+				)
 		, return []
 		)
-	put dest = do
-		ok <- includeCommandAction $ do
-			showStart' "copy" k af
-			Command.Move.toStart' dest False af k
-		return (ok, if ok then Just (Remote.uuid dest) else Nothing)
+	put dest = includeCommandAction $ do
+		showStart' "copy" k af
+		Command.Move.toStart' dest False af k
diff --git a/debian/changelog b/debian/changelog
index f744390..e806490 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -17,6 +17,9 @@ git-annex (5.20150714) UNRELEASED; urgency=medium
   * version --raw now works when run outside a git repository.
   * assistant --startdelay now works when run outside a git repository.
   * dead now accepts multiple --key options.
+  * sync --content: Fix bug that caused files to be uploaded to eg,
+    more archive remotes than wanted copies, only to later be dropped
+    to satisfy the preferred content settings.
 
  -- Joey Hess <id@joeyh.name>  Fri, 10 Jul 2015 16:36:42 -0400
 
diff --git a/doc/bugs/git_annex_sync_--content_may_copy_then_drop_a_file_to_a_remote.mdwn b/doc/bugs/git_annex_sync_--content_may_copy_then_drop_a_file_to_a_remote.mdwn
index 3ec60ca..ff3a3b7 100644
--- a/doc/bugs/git_annex_sync_--content_may_copy_then_drop_a_file_to_a_remote.mdwn
+++ b/doc/bugs/git_annex_sync_--content_may_copy_then_drop_a_file_to_a_remote.mdwn
@@ -31,3 +31,5 @@ drop hubic3 Avatars/archer.jpg ok
 
 # End of transcript or log.
 """]]
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/bugs/git_annex_sync_--content_may_copy_then_drop_a_file_to_a_remote/comment_1_56eaabb5988caa043ab2e9c1429f8595._comment b/doc/bugs/git_annex_sync_--content_may_copy_then_drop_a_file_to_a_remote/comment_1_56eaabb5988caa043ab2e9c1429f8595._comment
new file mode 100644
index 0000000..a6a7f77
--- /dev/null
+++ b/doc/bugs/git_annex_sync_--content_may_copy_then_drop_a_file_to_a_remote/comment_1_56eaabb5988caa043ab2e9c1429f8595._comment
@@ -0,0 +1,35 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-07-20T18:07:04Z"
+ content="""
+A good bug report that I didn't get to for far too long..
+
+I reproduced this fairly easily; both remotes set to be 
+in the archive group and both set to use the "standard" preferred content
+expression.
+
+	joey@darkstar:~/tmp/bench/local>git annex sync --content
+	commit  ok
+	copy file copy file (to hubic3...) 
+	ok                      
+	copy file copy file (to hubic2...) 
+	ok                      
+	drop hubic3 file ok
+
+It wants to drop the file from hubic3 once it's present on hubic2,
+since archive remotes only want files not on other archive remotes.
+
+So, why does it send the file to hubic2, given that it's already in hubic3?
+
+If I manually copy the file to one of the remotes, sync --content won't
+send it to the other. So, I suspect it's getting a list of remotes that
+want the file first, and then copying the file to all of them.
+
+Aha, indeed:
+
+	map put <$> filterM wantput lack
+
+Fixed by making it check if each remote wants the file inside the loop,
+rather than checking when getting the list of remotes to loop over.
+"""]]

ping
diff --git a/doc/bugs/git-annex_sync_under_windows_fails_by_using_itself_as_the_ssh_command/comment_4_1922bb745ff4194902801714d2b45d4b._comment b/doc/bugs/git-annex_sync_under_windows_fails_by_using_itself_as_the_ssh_command/comment_4_1922bb745ff4194902801714d2b45d4b._comment
new file mode 100644
index 0000000..895cd82
--- /dev/null
+++ b/doc/bugs/git-annex_sync_under_windows_fails_by_using_itself_as_the_ssh_command/comment_4_1922bb745ff4194902801714d2b45d4b._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""ping"""
+ date="2015-07-20T18:00:19Z"
+ content="""
+Someone else mentioned seeing this same problem on Windows.
+
+Any chance you can respond to my last comment, Johannes?
+"""]]

response
diff --git a/doc/forum/Windows_-_You_don__39__t_have_access/comment_1_5c1da63922cc71483c9519e8670d532b._comment b/doc/forum/Windows_-_You_don__39__t_have_access/comment_1_5c1da63922cc71483c9519e8670d532b._comment
new file mode 100644
index 0000000..ad11ef8
--- /dev/null
+++ b/doc/forum/Windows_-_You_don__39__t_have_access/comment_1_5c1da63922cc71483c9519e8670d532b._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-07-20T17:51:33Z"
+ content="""
+The "GitLab: You don't have access" seems to be gitlab refusing to run
+git-annex-shell when asked to. Only the gitlab people could help you with
+that. (Gitlab does seem to work with git-annex today when I try it,
+I had some similar problems with their implementation refusing to
+start git-annex-shell earlier.)
+
+OTOH, the "git-annex.exe: unknown command git@gitlab.server.com"
+looks like you ran into this bug:
+<http://git-annex.branchable.com/bugs/git-annex_sync_under_windows_fails_by_using_itself_as_the_ssh_command/>
+Since I have still not managed to reproduce or get to the bottom of that
+bug report, any information about it would be useful.
+"""]]

diff --git a/doc/forum/Windows_-_You_don__39__t_have_access.mdwn b/doc/forum/Windows_-_You_don__39__t_have_access.mdwn
new file mode 100644
index 0000000..a12d46a
--- /dev/null
+++ b/doc/forum/Windows_-_You_don__39__t_have_access.mdwn
@@ -0,0 +1,42 @@
+git version: 1.9.5.msysgit.1
+git-annex version: 5.20150710-g8fd7052
+
+I have a repo up on GitLab. I have annex’d files in that repo. On a Linux server I can “git annex sync” and then “git annex get” just fine. On Windows when I try to run “git annex sync” I get:
+
+GitLab: You don't have access
+
+  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-a
+nnex-shell is available in PATH when you ssh into the remote. Once you have fixed the git-annex inst
+allation, run: git config remote.origin.annex-ignore false
+commit  ok
+pull origin
+git-annex.exe: unknown command git@gitlab.server.com
+…
+fatal: Could not read from remote repository.
+
+Please make sure you have the correct access rights
+and the repository exists.
+failed
+git-annex: sync: 1 failed
+
+I have access to the repo however. I can git pull/push…whatever. It’s just annex that is having problems with access and I’m not sure why. Here is my git config:
+
+[core]
+        repositoryformatversion = 0
+        filemode = false
+        bare = false
+        logallrefupdates = true
+        symlinks = false
+        ignorecase = true
+        hideDotFiles = dotGitOnly
+[remote "origin"]
+        url = git@gitlab.company.com:repo.git
+        fetch = +refs/heads/*:refs/remotes/origin/*
+        annex-ignore = false
+[annex]
+        uuid = 2noa1e70-9f88-4did-843c-3f8sdf3495990
+        sshcaching = false
+        crippledfilesystem = true
+        version = 5

move to todo
diff --git a/doc/bugs/Metadata_changes_are_not_reflected_in_a_view.mdwn b/doc/bugs/Metadata_changes_are_not_reflected_in_a_view.mdwn
deleted file mode 100644
index cf8e106..0000000
--- a/doc/bugs/Metadata_changes_are_not_reflected_in_a_view.mdwn
+++ /dev/null
@@ -1,31 +0,0 @@
-### Please describe the problem.
-Changing metadata while being in an active view will not update the view.
-
-### What steps will reproduce the problem?
-(inside a repository)
-
-1. Create a file
-
-        $ uuidgen >file
-
-2. switch into a view
-
-       $ git annex view !blah
-       $ ls
-       file
-
-3. changed the metadata the view is based upon
-
-       $ git annex metadata -t blah file
-       $ ls
-       file
-
-   It would be nice/expected that the view gets updated when the metadata changes, hiding 'file' now
-  
-
-### What version of git-annex are you using? On what operating system?
-
-git-annex version: 5.20141024~bpo70+1
-on debian wheezy with backports
-
-### Please provide any additional information below.
diff --git a/doc/bugs/Metadata_changes_are_not_reflected_in_a_view/comment_1_5c3a0d8ec7b1da69b0d81aa4acc0c75b._comment b/doc/bugs/Metadata_changes_are_not_reflected_in_a_view/comment_1_5c3a0d8ec7b1da69b0d81aa4acc0c75b._comment
deleted file mode 100644
index 9b07979..0000000
--- a/doc/bugs/Metadata_changes_are_not_reflected_in_a_view/comment_1_5c3a0d8ec7b1da69b0d81aa4acc0c75b._comment
+++ /dev/null
@@ -1,18 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 1"""
- date="2015-07-20T17:45:13Z"
- content="""
-This might be worth adding. But, one of the ways views can be used
-is to use file operations to adjust the metadata that is being viewed.
-
-So, when you delete a file from a view, and git commit, git-annex
-will remove the metadata that had made the file be in the view.
-
-And, if you copy or move a file in a view to a different subdirectory,
-and add and git commit the change, the metadata will be updated to
-update the metadata to reflect the files new location.
-
-As such, I see this as a wishlist todo item at best, and will move it from
-the bugs list to the todo list.
-"""]]
diff --git a/doc/todo/Metadata_changes_are_not_reflected_in_a_view.mdwn b/doc/todo/Metadata_changes_are_not_reflected_in_a_view.mdwn
new file mode 100644
index 0000000..cf8e106
--- /dev/null
+++ b/doc/todo/Metadata_changes_are_not_reflected_in_a_view.mdwn
@@ -0,0 +1,31 @@
+### Please describe the problem.
+Changing metadata while being in an active view will not update the view.
+
+### What steps will reproduce the problem?
+(inside a repository)
+
+1. Create a file
+
+        $ uuidgen >file
+
+2. switch into a view
+
+       $ git annex view !blah
+       $ ls
+       file
+
+3. changed the metadata the view is based upon
+
+       $ git annex metadata -t blah file
+       $ ls
+       file
+
+   It would be nice/expected that the view gets updated when the metadata changes, hiding 'file' now
+  
+
+### What version of git-annex are you using? On what operating system?
+
+git-annex version: 5.20141024~bpo70+1
+on debian wheezy with backports
+
+### Please provide any additional information below.
diff --git a/doc/todo/Metadata_changes_are_not_reflected_in_a_view/comment_1_5c3a0d8ec7b1da69b0d81aa4acc0c75b._comment b/doc/todo/Metadata_changes_are_not_reflected_in_a_view/comment_1_5c3a0d8ec7b1da69b0d81aa4acc0c75b._comment
new file mode 100644
index 0000000..9b07979
--- /dev/null
+++ b/doc/todo/Metadata_changes_are_not_reflected_in_a_view/comment_1_5c3a0d8ec7b1da69b0d81aa4acc0c75b._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-07-20T17:45:13Z"
+ content="""
+This might be worth adding. But, one of the ways views can be used
+is to use file operations to adjust the metadata that is being viewed.
+
+So, when you delete a file from a view, and git commit, git-annex
+will remove the metadata that had made the file be in the view.
+
+And, if you copy or move a file in a view to a different subdirectory,
+and add and git commit the change, the metadata will be updated to
+update the metadata to reflect the files new location.
+
+As such, I see this as a wishlist todo item at best, and will move it from
+the bugs list to the todo list.
+"""]]

comment
diff --git a/doc/bugs/Metadata_changes_are_not_reflected_in_a_view/comment_1_5c3a0d8ec7b1da69b0d81aa4acc0c75b._comment b/doc/bugs/Metadata_changes_are_not_reflected_in_a_view/comment_1_5c3a0d8ec7b1da69b0d81aa4acc0c75b._comment
new file mode 100644
index 0000000..9b07979
--- /dev/null
+++ b/doc/bugs/Metadata_changes_are_not_reflected_in_a_view/comment_1_5c3a0d8ec7b1da69b0d81aa4acc0c75b._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-07-20T17:45:13Z"
+ content="""
+This might be worth adding. But, one of the ways views can be used
+is to use file operations to adjust the metadata that is being viewed.
+
+So, when you delete a file from a view, and git commit, git-annex
+will remove the metadata that had made the file be in the view.
+
+And, if you copy or move a file in a view to a different subdirectory,
+and add and git commit the change, the metadata will be updated to
+update the metadata to reflect the files new location.
+
+As such, I see this as a wishlist todo item at best, and will move it from
+the bugs list to the todo list.
+"""]]

expand
diff --git a/doc/git-annex-view.mdwn b/doc/git-annex-view.mdwn
index 73b4d34..56c7e9b 100644
--- a/doc/git-annex-view.mdwn
+++ b/doc/git-annex-view.mdwn
@@ -19,7 +19,8 @@ will put files in subdirectories according to the value of their fields.
   
 Once within such a view, you can make additional directories, and
 copy or move files into them. When you commit, the metadata will
-be updated to correspond to your changes.
+be updated to correspond to your changes. Deleting files and committing
+also updates the metadata.
   
 There are fields corresponding to the path to the file. So a file
 "foo/bar/baz/file" has fields "/=foo", "foo/=bar", and "foo/bar/=baz".

response
diff --git a/doc/forum/Multiple_repos_on_same_path/comment_2_e1c4ac71eb0f9ff6ae1701b3a6d738dd._comment b/doc/forum/Multiple_repos_on_same_path/comment_2_e1c4ac71eb0f9ff6ae1701b3a6d738dd._comment
new file mode 100644
index 0000000..65a233c
--- /dev/null
+++ b/doc/forum/Multiple_repos_on_same_path/comment_2_e1c4ac71eb0f9ff6ae1701b3a6d738dd._comment
@@ -0,0 +1,26 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2015-07-20T17:38:10Z"
+ content="""
+sunny256 has a nice approach with the symlinks to make the paths
+to the remores explicitly contain the machine name.
+
+However, if you want to keep it simple, it's perfectly fine for a
+remote's path to point to a directory which has different
+repositories mounted on it at different times. I do this in my own
+removable media drives, so the "host" remote uses /home/joey/sound,
+for example.
+
+This is safe to do because git-annex always checks the UUID of the
+remote before using it. For a local path like this, it will automatically
+update the cached annex-uuid of the remote when it finds a repo with a
+different UUID mounted. (For a path to a repo on a remote server, it uses
+other methods to verify that it's accessing the repo with the UUID it
+expected.)
+
+The only thing I'd be careful about doing is switching the repository that
+is mounted at a path with another one while git-annex is running, since it
+only checks at startup and won't notice the substitution and could get
+confused.
+"""]]

response
diff --git a/doc/forum/__96__git_annex_sync__96___hangs/comment_2_fad59a54d92ed7cb230f0f365fddb0f4._comment b/doc/forum/__96__git_annex_sync__96___hangs/comment_2_fad59a54d92ed7cb230f0f365fddb0f4._comment
new file mode 100644
index 0000000..19c3b0a
--- /dev/null
+++ b/doc/forum/__96__git_annex_sync__96___hangs/comment_2_fad59a54d92ed7cb230f0f365fddb0f4._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2015-07-20T17:35:42Z"
+ content="""
+Sorry didn't get to this until now.
+
+It would probably help to pass the --debug option to git-annex sync,
+and paste the output up to the point where it hangs.
+"""]]

response
diff --git a/doc/forum/Exclude_specific_files_from_a_special_remote/comment_1_d5a9f3308e09a9b9460014904d23ef48._comment b/doc/forum/Exclude_specific_files_from_a_special_remote/comment_1_d5a9f3308e09a9b9460014904d23ef48._comment
new file mode 100644
index 0000000..0375b92
--- /dev/null
+++ b/doc/forum/Exclude_specific_files_from_a_special_remote/comment_1_d5a9f3308e09a9b9460014904d23ef48._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-07-20T16:32:29Z"
+ content="""
+This is a job for [[preferred_content]]!
+
+For example, you could configure the remote to not want
+any flac files, so only mp3, ogg, etc files should be stored on that
+remote:
+
+	git annex wanted myremotename 'exclude=*.flac'
+
+This configuration will automatically be honored if you use
+`git annex sync --content` (or the assistant). If you manually
+use `git annex copy` to copy files to the remote, you'll need to
+add the `--auto` flag to make it honor the preferred content settings.
+"""]]

Added a comment
diff --git a/doc/forum/git-annex_fails_on_Windows/comment_2_57b4fd347f74b3536ab0f0a5d7709af8._comment b/doc/forum/git-annex_fails_on_Windows/comment_2_57b4fd347f74b3536ab0f0a5d7709af8._comment
new file mode 100644
index 0000000..c10e85c
--- /dev/null
+++ b/doc/forum/git-annex_fails_on_Windows/comment_2_57b4fd347f74b3536ab0f0a5d7709af8._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="fusionx86@2cab672ef75a8502e153ceb90177dde38985dba9"
+ nickname="fusionx86"
+ subject="comment 2"
+ date="2015-07-20T16:34:30Z"
+ content="""
+Thanks. I have another box with the latest version 1.9 which I thought I had tested this on. But I went back and tried again to find it does indeed work with a newer version. My fault for thinking I had tried this with 1.9. Thanks again...
+"""]]

point to docs
diff --git a/doc/forum/Use_password_protected_gpg_keypair_without_password_prompt__63__/comment_3_a2eb4244788eebba5167cd32a73ff204._comment b/doc/forum/Use_password_protected_gpg_keypair_without_password_prompt__63__/comment_3_a2eb4244788eebba5167cd32a73ff204._comment
new file mode 100644
index 0000000..96a14aa
--- /dev/null
+++ b/doc/forum/Use_password_protected_gpg_keypair_without_password_prompt__63__/comment_3_a2eb4244788eebba5167cd32a73ff204._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2015-07-20T16:30:10Z"
+ content="""
+I gave you one way in my previous comment; you can put any gpg option in
+~/.gnupg/gpg.conf, just leave off the leading dashes.
+
+Another way is the annex.gnupg-options git configuration setting,
+see git-annex's man page.
+"""]]

ancient git version detected..
diff --git a/doc/forum/git-annex_fails_on_Windows/comment_1_451a2cdfa6f26e2bd319ebf4ce09da68._comment b/doc/forum/git-annex_fails_on_Windows/comment_1_451a2cdfa6f26e2bd319ebf4ce09da68._comment
new file mode 100644
index 0000000..f429669
--- /dev/null
+++ b/doc/forum/git-annex_fails_on_Windows/comment_1_451a2cdfa6f26e2bd319ebf4ce09da68._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-07-20T16:21:32Z"
+ content="""
+This is a mismatch between the version of git that git-annex was compiled
+to use, and the version of git that you have installed.
+
+You seem to have a git version older than 1.8.1.6 installed, since
+"--literal-pathspecs" was first added in that version. According
+to the [Windows installation instructions](http://git-annex.branchable.com/install/Windows),
+you need to install msysgit 1.9 to use git-annex.
+
+So, upgrade..
+"""]]

response
diff --git a/doc/todo/Add___39__dir__39___option_to_addurl/comment_1_0156942b1629ee994bf3699a56b3ceb7._comment b/doc/todo/Add___39__dir__39___option_to_addurl/comment_1_0156942b1629ee994bf3699a56b3ceb7._comment
new file mode 100644
index 0000000..112c4bb
--- /dev/null
+++ b/doc/todo/Add___39__dir__39___option_to_addurl/comment_1_0156942b1629ee994bf3699a56b3ceb7._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-07-20T16:19:15Z"
+ content="""
+--file=subdir/foo will work, assuming subdir already exists.
+
+If the goal is just to add whatever filename addurl comes up with by
+default to a subdirectory, why not just `cd` to that subdir before
+running addurl?
+"""]]

diff --git a/doc/forum/git-annex_fails_on_Windows.mdwn b/doc/forum/git-annex_fails_on_Windows.mdwn
new file mode 100644
index 0000000..6c10003
--- /dev/null
+++ b/doc/forum/git-annex_fails_on_Windows.mdwn
@@ -0,0 +1,56 @@
+Not sure if this is a bug or user error. I'm trying to use git-annex on Windows 2008 R2, but it isn't working for me. Works fine on Linux. I have a local git repo and then added some binary files to annex. Then I used git annex sync --content to push ennex'd files up to git server. Then I can clone that repo and sync again to pull all the files down. On windows I just get error messages when I try to clone the repo and use annex to init or sync.
+
+git version: 1.8.0.msysgit.0
+git-annex version:
+git-annex version: 5.20150710-g8fd7052
+build flags: Assistant Webapp Webapp-secure Pairing Testsuite S3 WebDAV DNS Feeds Quvi TDFA TorrentP
+arser
+key/value backends: SHA256E SHA1E SHA512E SHA224E SHA384E SKEIN256E SKEIN512E MD5E SHA256 SHA1 SHA51
+2 SHA224 SHA384 SKEIN256 SKEIN512 MD5 WORM URL
+remote types: git gcrypt S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook extern
+al
+local repository version: unknown
+supported repository version: 5
+upgrade supported from repository versions: 2 3 4
+
+If I try to init the cloned repo:
+
+$ git-annex init
+init  Unknown option: --literal-pathspecs
+usage: git [--version] [--exec-path[=<path>]] [--html-path] [--man-path] [--info-path]
+           [-p|--paginate|--no-pager] [--no-replace-objects] [--bare]
+           [--git-dir=<path>] [--work-tree=<path>] [--namespace=<name>]
+           [-c name=value] [--help]
+           <command> [<args>]
+Unknown option: --literal-pathspecs
+usage: git [--version] [--exec-path[=<path>]] [--html-path] [--man-path] [--info-path]
+           [-p|--paginate|--no-pager] [--no-replace-objects] [--bare]
+           [--git-dir=<path>] [--work-tree=<path>] [--namespace=<name>]
+           [-c name=value] [--help]
+           <command> [<args>]
+Unknown option: --literal-pathspecs
+usage: git [--version] [--exec-path[=<path>]] [--html-path] [--man-path] [--info-path]
+           [-p|--paginate|--no-pager] [--no-replace-objects] [--bare]
+           [--git-dir=<path>] [--work-tree=<path>] [--namespace=<name>]
+           [-c name=value] [--help]
+           <command> [<args>]
+Unknown option: --literal-pathspecs
+usage: git [--version] [--exec-path[=<path>]] [--html-path] [--man-path] [--info-path]
+           [-p|--paginate|--no-pager] [--no-replace-objects] [--bare]
+           [--git-dir=<path>] [--work-tree=<path>] [--namespace=<name>]
+           [-c name=value] [--help]
+           <command> [<args>]
+git-annex.exe: git [Param "config",Param "user.name",Param "user"] failed
+
+If I try to sync:
+
+$ git annex sync --content
+Unknown option: --literal-pathspecs
+usage: git [--version] [--exec-path[=<path>]] [--html-path] [--man-path] [--info-path]
+           [-p|--paginate|--no-pager] [--no-replace-objects] [--bare]
+           [--git-dir=<path>] [--work-tree=<path>] [--namespace=<name>]
+           [-c name=value] [--help]
+           <command> [<args>]
+git-annex: First run: git-annex init
+
+What am I missing? I love the idea of annex and really need it for an urgent project I'm working on, but unfortunately I need to use it with Windows...in addition to Linux.

diff --git a/doc/todo/Add___39__dir__39___option_to_addurl.mdwn b/doc/todo/Add___39__dir__39___option_to_addurl.mdwn
new file mode 100644
index 0000000..ccba479
--- /dev/null
+++ b/doc/todo/Add___39__dir__39___option_to_addurl.mdwn
@@ -0,0 +1 @@
+Is it possible to add a '--dir' option to addurl (or some other mechanic) to make git annex create the symlinks in the specified directory?

Fix typo in pubkey
diff --git a/doc/install/verifying_downloads.mdwn b/doc/install/verifying_downloads.mdwn
index b366448..7fc7e0a 100644
--- a/doc/install/verifying_downloads.mdwn
+++ b/doc/install/verifying_downloads.mdwn
@@ -16,7 +16,7 @@ You can then download the public key, and check that the package is signed
 with it.
 
 	$ wget https://downloads.kitenet.net/git-annex/gpg-pubkey.asc
-	$ gpg --import gpg-pubey.asc
+	$ gpg --import gpg-pubkey.asc
 	$ gpg --verify git-annex-standalone-*.tar.gz.sig
 
 (The git-annex assistant can automatically upgrade git-annex, and when it

Added a comment
diff --git a/doc/todo/Set_total_storage_limit_for_special_remotes./comment_2_86aa368db46dfedb065a18edfa7c9ad4._comment b/doc/todo/Set_total_storage_limit_for_special_remotes./comment_2_86aa368db46dfedb065a18edfa7c9ad4._comment
new file mode 100644
index 0000000..818b7f3
--- /dev/null
+++ b/doc/todo/Set_total_storage_limit_for_special_remotes./comment_2_86aa368db46dfedb065a18edfa7c9ad4._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="mawillcockson"
+ subject="comment 2"
+ date="2015-07-18T19:13:03Z"
+ content="""
+Perhaps server-side [git hooks](https://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks)?
+
+Maybe a git hook script that uses [inotify](https://en.wikipedia.org/wiki/Inotify) for inode size notifications.
+
+I would have no idea how to implement this, though.
+"""]]

Added a comment: hack
diff --git a/doc/bugs/migrate_and_move_duplicates_data/comment_2_68a876f2eed5c446d92367aae4070408._comment b/doc/bugs/migrate_and_move_duplicates_data/comment_2_68a876f2eed5c446d92367aae4070408._comment
new file mode 100644
index 0000000..8163bc2
--- /dev/null
+++ b/doc/bugs/migrate_and_move_duplicates_data/comment_2_68a876f2eed5c446d92367aae4070408._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="mennucc1@6758d6a3817a0a6b29e8adbdb068c5ba35f6992b"
+ nickname="mennucc1"
+ subject="hack"
+ date="2015-07-18T09:16:03Z"
+ content="""
+hi  Joey, thanks for your interest;
+
+I created a script to address this problem
+
+<http://mennucc1.debian.net/git-annex/git-annex_de-re-link_hash-E>
+
+it can relink keys that are not hardlinked anymore (-L option) ; it can use an unsed key to recreate a missin key (-R option) ; it can also drop redundant keys (-D option)
+
+a.
+"""]]

diff --git a/doc/forum/Exclude_specific_files_from_a_special_remote.mdwn b/doc/forum/Exclude_specific_files_from_a_special_remote.mdwn
new file mode 100644
index 0000000..898ebfd
--- /dev/null
+++ b/doc/forum/Exclude_specific_files_from_a_special_remote.mdwn
@@ -0,0 +1,3 @@
+I have a special remote configured to/from which I can copy files correctly.
+I would like to be prevent some annexed files to be copied to this remote, automatically (in other words, without excluding them manually on the command line)
+How can this be done?

my NFS tricks for git-annex
diff --git a/doc/tips/git-annex_on_NFS.mdwn b/doc/tips/git-annex_on_NFS.mdwn
new file mode 100644
index 0000000..b6a8a45
--- /dev/null
+++ b/doc/tips/git-annex_on_NFS.mdwn
@@ -0,0 +1,75 @@
+There are multiple issues that have been reported that are related to using git-annex on networked file systems. We're generally talking about NFS, which we'll cover here, but this may also be the case on SMB filesystems.
+
+Locking issues
+==============
+
+Here is the prior art here:
+
+* [[devblog/day_27__locking_fun/]]
+* [[devblog/day_286-287__rotten_locks/]]
+* [[forum/Can__39__t_init_git_annex/]]
+* [[bugs/git-annex_merge_stalls/]]
+
+All of those issues but the first are related to locking on NFS filesystems, which is [notoriously bad](https://en.wikipedia.org/wiki/File_locking#Problems). However, the problems with it are not insurmountable and git-annex can actually be used, even if unreliably, on NFS filesystems.
+
+The problem I mainly hit with NFS filesystems is with unreliable locking. If you have similar platforms (both running Linux for example, NFS locking doesn't work in BSD systems), locking *should* work, but sometimes fails without reason. This problem and the solution is well described in [this stackoverflow answer](http://serverfault.com/a/455080), taken from [this excellent blog](http://sophiedogg.com/lockd-and-statd-nfs-errors/). Basically, you need to restart a bunch of NFS daemon that get stuck on the server side and then locking works again. This generally fixed it for me:
+
+<pre>
+service nfs-kernel-server stop
+service rpcbind stop
+service nfs-common stop
+service rpcbind start
+service nfs-common start
+service nfs-kernel-server start
+</pre>
+
+This needs to be run as root on the server side. Having a simple test script to see if locking works is also useful, i use the following:
+
+<pre>
+#! /usr/bin/perl -w
+
+use Fcntl qw(LOCK_SH LOCK_EX LOCK_UN);
+
+$child = fork();
+open(TESTLCK, ">testlock");
+
+if ($child == 0) { # in child
+	print "locking exclusively\n";
+	flock(TESTLCK, LOCK_EX) || die "failed to lock exclusively: $!";
+	print "holding exclusively lock for 3 seconds\n";
+	sleep 3;
+	flock(TESTLCK, LOCK_UN) || die "failed to unlock exclusively: $!";
+	print "done locking exclusively\n";
+} else { # in parent
+	print "locking shared\n";
+	flock(TESTLCK, LOCK_SH) || die "failed to lock shared: $!";
+	print "holding shared lock for 3 seconds\n";
+	sleep 3;
+	flock(TESTLCK, LOCK_UN) || die "failed to unlock shared: $!";
+	print "done locking shared, waiting for child to finish\n";
+	wait;
+}
+</pre>
+
+Also note that the [NFS FAQ](http://nfs.sourceforge.net/) (currently offline, thanks to Sourceforge, see [this archive](https://archive.is/QMMO)) also has interesting snippets about NFS locking. In short: it's a mess, but it can be worked around! -- [[anarcat]]
+
+Socket issues
+=============
+
+Another thing that may fail is the "ssh caching code". Examples:
+
+* [[forum/git_annex_sync_dies___40__sometimes__41__/]]
+* [[forum/NTFS_usb_on_linux_unable_to_connect_to_ssh_remote/]]
+* [[todo/git-annex_ignores_GIT__95__SSH/]]
+* [[bugs/git-annex-shell_doesn__39__t_work_as_expected/]]
+
+As you can see, this affects way more than NFS, which often just works there. But it can be that the SSH client can't create a socket for the SSH multiplexing that git-annex uses. Normally, git-annex should detect that and fallback properly, but sometimes this fails, especially with older versions of git-annex. A workaround is to disable the feature:
+
+    git config annex.sshcaching false
+
+The tradeoff is that syncs are faster, but it works. -- [[anarcat]]
+
+Stray files issue
+=================
+
+This is a completely different issue, but could be related to file locking: [[bugs/huge_multiple_copies_of___39__.nfs__42____39___and___39__.panfs__42____39___being_created/]]. Basically, tons of files are left behind by git-annex when it is ran on an NFS server. It is yet unclear how this problem happens and how to resolve it. But it has been reproduced and could affect you, so until it is resolved, it is still an open issue here... -- [[anarcat]]

Added a comment
diff --git a/doc/forum/Use_password_protected_gpg_keypair_without_password_prompt__63__/comment_2_6d88e5a48de78e6add0e4e4b6ebc3f1b._comment b/doc/forum/Use_password_protected_gpg_keypair_without_password_prompt__63__/comment_2_6d88e5a48de78e6add0e4e4b6ebc3f1b._comment
new file mode 100644
index 0000000..99b6400
--- /dev/null
+++ b/doc/forum/Use_password_protected_gpg_keypair_without_password_prompt__63__/comment_2_6d88e5a48de78e6add0e4e4b6ebc3f1b._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="sfowijowa"
+ subject="comment 2"
+ date="2015-07-17T18:20:06Z"
+ content="""
+Hi, I am using the \"--passphrase-file\" option outside git-annex to sign the files that have to be backed up:
+\"gpg --batch --passphrase-file /home/user/.gnupg/pass.txt --no-tty --yes --detach-sign /tmp/root.tar.gz\" Unfortunately, I couldn't find a way to pass this option to gpg with git-annex. In duplicity, for example, you can pass gpg options with \"dupclitiy --gpg-options '--passphrase-file /home/user/.gnupg/pass.txt'\" Best regards
+"""]]

Added a comment: bup.bloom must be unlocked
diff --git a/doc/tips/Bup_repositories_in_git-annex/comment_1_738959a699755704baab6df778ecd120._comment b/doc/tips/Bup_repositories_in_git-annex/comment_1_738959a699755704baab6df778ecd120._comment
new file mode 100644
index 0000000..5b9566c
--- /dev/null
+++ b/doc/tips/Bup_repositories_in_git-annex/comment_1_738959a699755704baab6df778ecd120._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="sfowijowa"
+ subject="bup.bloom must be unlocked"
+ date="2015-07-17T17:45:24Z"
+ content="""
+Hi, Thanks for the help :) I didn't exlude any files. Therefore \"$BUP_REPO/objects/pack/bup.bloom\" gets added by git-annex. This file has to be unlocked beforehand for bup to be running correctly. Best regards
+"""]]

response
diff --git a/doc/forum/Is_setting_core.preloadindex_safe_with_git_annex__63__/comment_1_c250362236a33d8dc9bf5ed825318c40._comment b/doc/forum/Is_setting_core.preloadindex_safe_with_git_annex__63__/comment_1_c250362236a33d8dc9bf5ed825318c40._comment
new file mode 100644
index 0000000..073a91d
--- /dev/null
+++ b/doc/forum/Is_setting_core.preloadindex_safe_with_git_annex__63__/comment_1_c250362236a33d8dc9bf5ed825318c40._comment
@@ -0,0 +1,23 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-07-17T15:59:16Z"
+ content="""
+I don't fully understand what core.preloadindex does, but according to
+git's documentation, it's enabled by default. So, it seems pretty safe. :)
+
+Let's anwser the general question: When is a git config tweak not safe to
+use with a git-annex repository? Well, git-annex just stores symlinks in
+git. And, it maintains a separate git-annex branch with its own data, which
+it makes commits to behind the scenes, using its own .git/annex/index file.
+Otherwise, a git-annex repo is like any other git repo.
+
+It follows that, unless the git config tweak somehow breaks symlink
+support, or somehow breaks git-annex's use of the .git/annex/index file,
+the git config tweak should be safe to use with git-annex.
+
+An example of a config tweak that's not entirely safe is to configure
+gc.pruneexpire to a very short time period. That could result in git
+objects that .git/annex/index refers to being pruned before git-annex can
+commit them to the git-annex branch.
+"""]]

close
diff --git a/doc/bugs/SignatureDoesNotMatch_error_when_trying_to_enable_S3_remote_with_IAM_credentials.mdwn b/doc/bugs/SignatureDoesNotMatch_error_when_trying_to_enable_S3_remote_with_IAM_credentials.mdwn
index b22a816..125a3f6 100644
--- a/doc/bugs/SignatureDoesNotMatch_error_when_trying_to_enable_S3_remote_with_IAM_credentials.mdwn
+++ b/doc/bugs/SignatureDoesNotMatch_error_when_trying_to_enable_S3_remote_with_IAM_credentials.mdwn
@@ -28,3 +28,9 @@ I have an existing Git annex repository with an Amazon S3 remote. I don't have t
 
     [ollie@nixos:/media/music]$ cat /run/current-system/nixos-version 
     15.05pre-70b398d
+
+> Apparently something changed in a newer verison of git-annex that fixed
+> this. Since I can't think of what the change could be, my guess is the
+> newer git-annex was built against a newer version of the aws library, and
+> that the fix was in the aws library. In any case, apparently this bug is
+> [[done]] --[[Joey]]

fixed via --all option
diff --git a/doc/bugs/git_annex_sync_--content_not_syncing_all_objects.mdwn b/doc/bugs/git_annex_sync_--content_not_syncing_all_objects.mdwn
index 1056e96..ad7a05d 100644
--- a/doc/bugs/git_annex_sync_--content_not_syncing_all_objects.mdwn
+++ b/doc/bugs/git_annex_sync_--content_not_syncing_all_objects.mdwn
@@ -31,3 +31,6 @@ Linux (Ubuntu 13.10)
 """]]
 
 [[!tag confirmed]]
+
+> `git annex sync --content --all` was added in version 5.20150617.
+> [[done]] --[[Joey]]

close
diff --git a/doc/bugs/importfeed_can__39__t_deal_with_pycon_rss_feeds.mdwn b/doc/bugs/importfeed_can__39__t_deal_with_pycon_rss_feeds.mdwn
index 1cfe85c..bed954a 100644
--- a/doc/bugs/importfeed_can__39__t_deal_with_pycon_rss_feeds.mdwn
+++ b/doc/bugs/importfeed_can__39__t_deal_with_pycon_rss_feeds.mdwn
@@ -23,3 +23,6 @@ xargs doesn't actually work so well because every once in a while, youtube will
     curl -s http://pyvideo.org/category/65/pycon-us-2015/rss | xmllint --xpath '//enclosure/@url' - | sed 's/url="/\n/g;s/"//' | while read url ; do git annex addurl --fast $url ; done
 
 but it's pretty ugly! --[[anarcat]]
+
+> Per my comments, I don't think this is a bug in git-annex, but in the
+> feeds. So [[done]] --[[Joey]] 

comment
diff --git a/doc/bugs/migrate_and_move_duplicates_data/comment_1_ac3c5c141992c7b5d2cc36e085b0cba8._comment b/doc/bugs/migrate_and_move_duplicates_data/comment_1_ac3c5c141992c7b5d2cc36e085b0cba8._comment
new file mode 100644
index 0000000..83af059
--- /dev/null
+++ b/doc/bugs/migrate_and_move_duplicates_data/comment_1_ac3c5c141992c7b5d2cc36e085b0cba8._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-07-17T15:41:53Z"
+ content="""
+I don't feel that migration is an important enough feature to complicate
+the rest of git-annex with special handling of multiple keys that point to
+the same content.
+
+You could have used `mv` in your use case to move the repo to the new drive
+while preseving hard links.
+
+What might be useful is for `git annex migrate` to write a list of the old keys
+someplace. These could then be dropped when the user wants to get rid of them,
+with mixing them up with other unused files. Although if you care about old
+versions of files and don't want to drop them as unused, it seems to me you'd
+also want to be able to access the old keys from before the migration.
+"""]]

update arch page to mention haskell-core repo
diff --git a/doc/bugs/Installation_on_ArchLinux_fails.mdwn b/doc/bugs/Installation_on_ArchLinux_fails.mdwn
index a956e6a..54c6718 100644
--- a/doc/bugs/Installation_on_ArchLinux_fails.mdwn
+++ b/doc/bugs/Installation_on_ArchLinux_fails.mdwn
@@ -31,3 +31,6 @@ Both git-annex and git-annex-git fail with
     error: target not found: haskell-hs3
 
 as these packages are not available on AUR.
+
+> I have updated the arch documentation to replace the failing package with
+> the haskell-core one. [[done]] --[[Joey]]
diff --git a/doc/install/ArchLinux.mdwn b/doc/install/ArchLinux.mdwn
index 43b7d13..c051e85 100644
--- a/doc/install/ArchLinux.mdwn
+++ b/doc/install/ArchLinux.mdwn
@@ -1,12 +1,10 @@
-There are four non non-official packages for git-annex in the Arch Linux User Repository. Any of these may be installed manually per [AUR guidelines](https://wiki.archlinux.org/index.php/AUR_User_Guidelines#Installing_packages) or using a wrapper such as [`yaourt`](https://wiki.archlinux.org/index.php/yaourt) shown below.
+There are at least four non non-official packages for git-annex in the Arch Linux User Repository. Any of these may be installed manually per [AUR guidelines](https://wiki.archlinux.org/index.php/AUR_User_Guidelines#Installing_packages) or using a wrapper such as [`yaourt`](https://wiki.archlinux.org/index.php/yaourt) shown below.
 
 1. The simplest method is to use the [git-annex-bin](https://aur.archlinux.org/packages/git-annex-bin/) package based on the [prebuilt Linux tarballs](http://downloads.kitenet.net/git-annex/linux/current/). This package includes many of the binary shims from the pre-built package. Although common Linux system utilities have been stripped in favor of normal dependencies, the pre-configured Haskell libraries included out of the box make this an easy install. The disadvantage is the resulting installation is a bit on the heavy side at nearly 100M.
 
        $ yaourt -Sy git-annex-bin
 
-2. A more traditional source package is available at [git-annex](https://aur.archlinux.org/packages/git-annex/). This depends on a large number of Haskell packages available from a third party repository or through Cabal. You must either enable a 3rd party repo that has the dependencies or have a working Cabal installation. Unless you know what you are doing this is a bit problematic and some intervention may be required to get this option to work. The state of available dependency versions also varies so this may not work at all times.
-
-       $ yaourt -Sy git-annex
+2. A git-annex package is available in the haskell-core AUR <https://wiki.archlinux.org/index.php/ArchHaskell>
 
 3. A development package is available at [git-annex-git](https://aur.archlinux.org/packages/git-annex-git/) that functions similarly to the source package but builds directly from the HEAD of the git repository rather that the last official release.
 

response
diff --git a/doc/bugs/cannot_change_locale___40__en__95__US.UTF-8__41__/comment_1_d8d8e8f672ad7a95f6565d15ccd11e45._comment b/doc/bugs/cannot_change_locale___40__en__95__US.UTF-8__41__/comment_1_d8d8e8f672ad7a95f6565d15ccd11e45._comment
new file mode 100644
index 0000000..fa17f6e
--- /dev/null
+++ b/doc/bugs/cannot_change_locale___40__en__95__US.UTF-8__41__/comment_1_d8d8e8f672ad7a95f6565d15ccd11e45._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-07-17T15:34:21Z"
+ content="""
+This suggests that your system has misconfigured locales. Perhaps it has
+the locale set to en_US.UTF-8 but does not have that locale configured.
+
+Doesn't seem likely to be a bug in git-annex.
+
+The same message is reported in
+<http://git-annex.branchable.com/bugs/view_fails_with___34__invalid_character__34__/>.
+Arch linux was also being used there. Surely the Arch wiki has something
+about fixing your locale setting? :)
+"""]]

diff --git a/doc/bugs/cannot_change_locale___40__en__95__US.UTF-8__41__.mdwn b/doc/bugs/cannot_change_locale___40__en__95__US.UTF-8__41__.mdwn
new file mode 100644
index 0000000..dd0a2b7
--- /dev/null
+++ b/doc/bugs/cannot_change_locale___40__en__95__US.UTF-8__41__.mdwn
@@ -0,0 +1,30 @@
+### Please describe the problem.
+
+All git annex commands run successfully but are prefixed by an annoying error message:
+
+"/bin/sh: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)"
+
+
+### What steps will reproduce the problem?
+
+`git annex init` or just about any git annex command.
+
+
+### What version of git-annex are you using? On what operating system?
+
+git-annex version: 5.20150710-g8fd7052 on arch linux 4.0.7-2.
+
+### Please provide any additional information below.
+
+# locale -a 
+C
+en_US
+en_US.iso88591
+en_US.utf8
+hebrew
+he_IL
+he_IL.iso88598
+he_IL.utf8
+POSIX
+
+

Added a comment
diff --git a/doc/bugs/SignatureDoesNotMatch_error_when_trying_to_enable_S3_remote_with_IAM_credentials/comment_6_5e3bd68936199a29bf38fee43f1030b8._comment b/doc/bugs/SignatureDoesNotMatch_error_when_trying_to_enable_S3_remote_with_IAM_credentials/comment_6_5e3bd68936199a29bf38fee43f1030b8._comment
new file mode 100644
index 0000000..fc2a41f
--- /dev/null
+++ b/doc/bugs/SignatureDoesNotMatch_error_when_trying_to_enable_S3_remote_with_IAM_credentials/comment_6_5e3bd68936199a29bf38fee43f1030b8._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="ollie@6d66b5a4b0992998efe3e4c244a66708bf5d96f3"
+ nickname="ollie"
+ subject="comment 6"
+ date="2015-07-17T10:42:05Z"
+ content="""
+I've just updated to a much newer git-annex, and everything seems to be working again now. Hurrah!
+"""]]

diff --git a/doc/forum/Is_setting_core.preloadindex_safe_with_git_annex__63__.mdwn b/doc/forum/Is_setting_core.preloadindex_safe_with_git_annex__63__.mdwn
new file mode 100644
index 0000000..09ca5fe
--- /dev/null
+++ b/doc/forum/Is_setting_core.preloadindex_safe_with_git_annex__63__.mdwn
@@ -0,0 +1 @@
+I found [this suggestion](http://stackoverflow.com/a/2873039) on Stack Overflow. Is this safe to use in git annex? I don't know how the internals work. I have a very large annex and I don't want to screw it up.

Added a comment
diff --git a/doc/forum/MD5_and_MD5E_backends_no_longer_available__63__/comment_2_5025d16f59f314711e49537e542b7c83._comment b/doc/forum/MD5_and_MD5E_backends_no_longer_available__63__/comment_2_5025d16f59f314711e49537e542b7c83._comment
new file mode 100644
index 0000000..0756c3f
--- /dev/null
+++ b/doc/forum/MD5_and_MD5E_backends_no_longer_available__63__/comment_2_5025d16f59f314711e49537e542b7c83._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="ghen1"
+ subject="comment 2"
+ date="2015-07-17T09:52:02Z"
+ content="""
+Yes, I am using an older version. Thank you for the help.
+"""]]

devblogc
diff --git a/doc/devblog/day_301__completion_and_er_completion.mdwn b/doc/devblog/day_301__completion_and_er_completion.mdwn
new file mode 100644
index 0000000..871b4c4
--- /dev/null
+++ b/doc/devblog/day_301__completion_and_er_completion.mdwn
@@ -0,0 +1,9 @@
+Worked on bash tab completion some more. Got "git annex" to also tab complete.
+However, for that to work perfectly when using bash-completion to demand-load
+completion scripts, a small improvement is needed in git's own completion
+script, to have it load git-annex's completion script. I sent a 
+[patch for that to the git developers](http://thread.gmane.org/gmane.comp.version-control.git/274034),
+and hopefully it'll get accepted soon.
+
+Then fixed a relatively long-standing bug that prevented uploads to
+chunked remotes from resuming after the last successfully uploaded chunk.

move forum bug report to bugs, and close
diff --git a/doc/bugs/s3_special_remote_does_not_resume_uploads_even_with_new_chunking.mdwn b/doc/bugs/s3_special_remote_does_not_resume_uploads_even_with_new_chunking.mdwn
new file mode 100644
index 0000000..1241a00
--- /dev/null
+++ b/doc/bugs/s3_special_remote_does_not_resume_uploads_even_with_new_chunking.mdwn
@@ -0,0 +1,90 @@
+I'm trying to upload large files into s3 remote.  I'm using a very recent version of git-annex:
+
+    git-annex version: 5.20150616-g4d7683b
+    build flags: Assistant Webapp Webapp-secure Pairing Testsuite S3 WebDAV FsEvents 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
+
+Here's how my chunking is set up:
+
+    xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx bucket=mybucket chunk=256MiB cipher=xxxxxx cipherkeys=xxxxxx datacenter=US
+    host=s3.amazonaws.com name=mybucket port=80 s3creds=xxxxxx storageclass=STANDARD type=S3 timestamp=xxxxxx
+
+If I run an upload and `^C` it in the middle of the upload, then start it again, it will always resume from the beginning.
+
+I've proven this to myself by using the `--debug` switch, please see blow. I've renamed certain things for security reasons, however GPGHMACSHA1--1111111111 always refers to the same chunk and GPGHMACSHA1--2222222222 always refers to the same chunk, etc.
+
+You can see that even after it uploads the same chunk once, it tries again.
+
+This is consistent with the behavior of letting it sit there for an hour and upload half of the large file, and then interrupting it, and having it start from scratch again.
+
+    $ git annex copy --debug * --to mybucket
+
+    [2015-06-23 15:24:07 PDT] read: git ["--git-dir=../../.git","--work-tree=../..","--literal-pathspecs","show-ref","git-annex"]
+    [2015-06-23 15:24:07 PDT] read: git ["--git-dir=../../.git","--work-tree=../..","--literal-pathspecs","show-ref","--hash","refs/heads/git-annex"]
+    [2015-06-23 15:24:07 PDT] read: git ["--git-dir=../../.git","--work-tree=../..","--literal-pathspecs","log","refs/heads/git-annex..xxx","-n1","--pretty=%H"]
+    [2015-06-23 15:24:07 PDT] chat: git ["--git-dir=../../.git","--work-tree=../..","--literal-pathspecs","cat-file","--batch"]
+    [2015-06-23 15:24:07 PDT] read: git ["--git-dir=../../.git","--work-tree=../..","--literal-pathspecs","ls-files","--cached","-z","--","aaa.tgz","xxx.tgz","xxx.tgz","xxx.tgz","xxx.tgz","xxx.tgz"]
+    copy aaa.tgz [2015-06-23 15:24:07 PDT] chat: gpg ["--quiet","--trust-model","always","--decrypt"]
+    (checking mybucket...) [2015-06-23 15:24:07 PDT] String to sign: "HEAD\n\n\nTue, 23 Jun 2015 22:24:07 GMT\n/mybucket/GPGHMACSHA1--1111111111"
+    [2015-06-23 15:24:07 PDT] Host: "mybucket.s3.amazonaws.com"
+    [2015-06-23 15:24:07 PDT] Path: "/GPGHMACSHA1--1111111111"
+    [2015-06-23 15:24:07 PDT] Query string: ""
+    [2015-06-23 15:24:07 PDT] Response status: Status {statusCode = 404, statusMessage = "Not Found"}
+    [2015-06-23 15:24:07 PDT] Response header 'x-amz-request-id': 'xxx'
+    [2015-06-23 15:24:07 PDT] Response header 'x-amz-id-2': 'xxx'
+    [2015-06-23 15:24:07 PDT] Response header 'Content-Type': 'application/xml'
+    [2015-06-23 15:24:07 PDT] Response header 'Transfer-Encoding': 'chunked'
+    [2015-06-23 15:24:07 PDT] Response header 'Date': 'Tue, 23 Jun 2015 22:24:03 GMT'
+    [2015-06-23 15:24:07 PDT] Response header 'Server': 'AmazonS3'
+    [2015-06-23 15:24:07 PDT] Response metadata: S3: request ID=<none>, x-amz-id-2=<none>
+    (to mybucket...)
+    0%            0.0 B/s 0s[2015-06-23 15:24:07 PDT] chat: gpg ["--quiet","--trust-model","always","--batch","--passphrase-fd","18","--symmetric","--force-mdc","--no-textmode"]
+    [2015-06-23 15:24:19 PDT] String to sign: "PUT\n\n\nTue, 23 Jun 2015 22:24:19 GMT\nx-amz-storage-class:STANDARD\n/mybucket/GPGHMACSHA1--2222222222"
+    [2015-06-23 15:24:19 PDT] Host: "mybucket.s3.amazonaws.com"
+    [2015-06-23 15:24:19 PDT] Path: "/GPGHMACSHA1--2222222222"
+    [2015-06-23 15:24:19 PDT] Query string: ""
+    3%        636.3KB/s 3h0m[2015-06-23 15:31:01 PDT] Response status: Status {statusCode = 200, statusMessage = "OK"}
+    [2015-06-23 15:31:01 PDT] Response header 'x-amz-id-2': 'xxx'
+    [2015-06-23 15:31:01 PDT] Response header 'x-amz-request-id': 'xxx'
+    [2015-06-23 15:31:01 PDT] Response header 'Date': 'Tue, 23 Jun 2015 22:24:17 GMT'
+    [2015-06-23 15:31:01 PDT] Response header 'ETag': '"xxx"'
+    [2015-06-23 15:31:01 PDT] Response header 'Content-Length': '0'
+    [2015-06-23 15:31:01 PDT] Response header 'Server': 'AmazonS3'
+    [2015-06-23 15:31:01 PDT] Response metadata: S3: request ID=xxx, x-amz-id-2=xxx
+    3%        633.2KB/s 3h1m[2015-06-23 15:31:01 PDT] chat: gpg ["--quiet","--trust-model","always","--batch","--passphrase-fd","18","--symmetric","--force-mdc","--no-textmode"]
+    [2015-06-23 15:31:13 PDT] String to sign: "PUT\n\n\nTue, 23 Jun 2015 22:31:13 GMT\nx-amz-storage-class:STANDARD\n/mybucket/GPGHMACSHA1--3333333333"
+    [2015-06-23 15:31:13 PDT] Host: "mybucket.s3.amazonaws.com"
+    [2015-06-23 15:31:13 PDT] Path: "/GPGHMACSHA1--3333333333"
+    [2015-06-23 15:31:13 PDT] Query string: ""
+    3%        617.2KB/s 3h6m^C
+
+    $ git annex copy --debug * --to mybucket
+
+    [2015-06-23 15:31:25 PDT] read: git ["--git-dir=../../.git","--work-tree=../..","--literal-pathspecs","show-ref","git-annex"]
+    [2015-06-23 15:31:25 PDT] read: git ["--git-dir=../../.git","--work-tree=../..","--literal-pathspecs","show-ref","--hash","refs/heads/git-annex"]
+    [2015-06-23 15:31:25 PDT] read: git ["--git-dir=../../.git","--work-tree=../..","--literal-pathspecs","log","refs/heads/git-annex..xxx","-n1","--pretty=%H"]
+    [2015-06-23 15:31:25 PDT] chat: git ["--git-dir=../../.git","--work-tree=../..","--literal-pathspecs","cat-file","--batch"]
+    [2015-06-23 15:31:25 PDT] read: git ["--git-dir=../../.git","--work-tree=../..","--literal-pathspecs","ls-files","--cached","-z","--","aaa.tgz","xxx.tgz","xxx.tgz","xxx.tgz","xxx.tgz","xxx.tgz"]
+    copy aaa.tgz [2015-06-23 15:31:25 PDT] chat: gpg ["--quiet","--trust-model","always","--decrypt"]
+    (checking mybucket...) [2015-06-23 15:31:25 PDT] String to sign: "HEAD\n\n\nTue, 23 Jun 2015 22:31:25 GMT\n/mybucket/GPGHMACSHA1--1111111111"
+    [2015-06-23 15:31:25 PDT] Host: "mybucket.s3.amazonaws.com"
+    [2015-06-23 15:31:25 PDT] Path: "/GPGHMACSHA1--1111111111"
+    [2015-06-23 15:31:25 PDT] Query string: ""
+    [2015-06-23 15:31:25 PDT] Response status: Status {statusCode = 404, statusMessage = "Not Found"}
+    [2015-06-23 15:31:25 PDT] Response header 'x-amz-request-id': 'xxx'
+    [2015-06-23 15:31:25 PDT] Response header 'x-amz-id-2': 'xxx'
+    [2015-06-23 15:31:25 PDT] Response header 'Content-Type': 'application/xml'
+    [2015-06-23 15:31:25 PDT] Response header 'Transfer-Encoding': 'chunked'
+    [2015-06-23 15:31:25 PDT] Response header 'Date': 'Tue, 23 Jun 2015 22:31:21 GMT'
+    [2015-06-23 15:31:25 PDT] Response header 'Server': 'AmazonS3'
+    [2015-06-23 15:31:25 PDT] Response metadata: S3: request ID=<none>, x-amz-id-2=<none>
+    (to mybucket...)
+    0%            0.0 B/s 0s[2015-06-23 15:31:25 PDT] chat: gpg ["--quiet","--trust-model","always","--batch","--passphrase-fd","18","--symmetric","--force-mdc","--no-textmode"]
+    [2015-06-23 15:31:37 PDT] String to sign: "PUT\n\n\nTue, 23 Jun 2015 22:31:37 GMT\nx-amz-storage-class:STANDARD\n/mybucket/GPGHMACSHA1--2222222222"
+    [2015-06-23 15:31:37 PDT] Host: "mybucket.s3.amazonaws.com"
+    [2015-06-23 15:31:37 PDT] Path: "/GPGHMACSHA1--2222222222"
+    [2015-06-23 15:31:37 PDT] Query string: ""
+    0%       350.1KB/s 5h40m^C
+
+> [[fixed|done]] --[[Joey]] 
diff --git a/doc/bugs/s3_special_remote_does_not_resume_uploads_even_with_new_chunking/comment_1_f6b1991e259bf4b3d2c85a08f465aa4a._comment b/doc/bugs/s3_special_remote_does_not_resume_uploads_even_with_new_chunking/comment_1_f6b1991e259bf4b3d2c85a08f465aa4a._comment
new file mode 100644
index 0000000..79f0fe8
--- /dev/null
+++ b/doc/bugs/s3_special_remote_does_not_resume_uploads_even_with_new_chunking/comment_1_f6b1991e259bf4b3d2c85a08f465aa4a._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="anarcat"
+ subject="comment 1"
+ date="2015-06-24T00:31:43Z"
+ content="""
+did a single chunk get transfered correctly? i believe git-annex can only resume at the chunk granularity... that is what it is for, no? --[[anarcat]]
+"""]]
diff --git a/doc/bugs/s3_special_remote_does_not_resume_uploads_even_with_new_chunking/comment_2_db57d14b983a957c454968477d9de634._comment b/doc/bugs/s3_special_remote_does_not_resume_uploads_even_with_new_chunking/comment_2_db57d14b983a957c454968477d9de634._comment
new file mode 100644
index 0000000..df12abc
--- /dev/null
+++ b/doc/bugs/s3_special_remote_does_not_resume_uploads_even_with_new_chunking/comment_2_db57d14b983a957c454968477d9de634._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="digiuser"
+ subject="yes"
+ date="2015-06-24T00:49:22Z"
+ content="""
+Yes, a single chunk did get transferred correctly.
+
+Actually, many times I've run this experiment, many chunks did get transferred correctly. I've even verified that they are in S3, but git-annex is trying to re-upload them. 
+
+(I haven't checked their contents in S3 but the filenames are there and the sizes are there)
+"""]]
diff --git a/doc/bugs/s3_special_remote_does_not_resume_uploads_even_with_new_chunking/comment_3_85989f505931ec695d7f3de74db0f5a1._comment b/doc/bugs/s3_special_remote_does_not_resume_uploads_even_with_new_chunking/comment_3_85989f505931ec695d7f3de74db0f5a1._comment
new file mode 100644
index 0000000..aac24a0
--- /dev/null
+++ b/doc/bugs/s3_special_remote_does_not_resume_uploads_even_with_new_chunking/comment_3_85989f505931ec695d7f3de74db0f5a1._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="digiuser"
+ subject="any updates?"
+ date="2015-06-29T03:05:53Z"
+ content="""
+Sorry to post again here but I was wondering if this message got lost. Anyone have a solution here? Thanks!
+"""]]
diff --git a/doc/bugs/s3_special_remote_does_not_resume_uploads_even_with_new_chunking/comment_4_bd631d470ee0365a11483c9a2e563b32._comment b/doc/bugs/s3_special_remote_does_not_resume_uploads_even_with_new_chunking/comment_4_bd631d470ee0365a11483c9a2e563b32._comment
new file mode 100644
index 0000000..ecac791
--- /dev/null
+++ b/doc/bugs/s3_special_remote_does_not_resume_uploads_even_with_new_chunking/comment_4_bd631d470ee0365a11483c9a2e563b32._comment
@@ -0,0 +1,30 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2015-07-16T17:57:44Z"
+ content="""
+This should have been filed as a bug report... I will move the thread to
+bugs after posting this comment.
+
+In your obfuscated log, it tries to HEAD GPGHMACSHA1--1111111111
+and when that fails, it PUTs GPGHMACSHA1--2222222222. From this, we can
+deduce that GPGHMACSHA1--1111111111 is not the first chunk, but is the full
+non-chunked file, and GPGHMACSHA1--2222222222 is actually the first chunk.
+
+For testing, I modifed the S3 remote to make file uploads succeed, but then
+report to git-annex that they failed. So, git annex copy uploads the 1st
+chunk and then fails, same as it was interrupted there. Repeating the copy,
+I see the same thing; it HEADs the full key, does not HEAD the first chunk,
+and so doesn't notice it was uploaded before, and so re-uploads the first
+chunk.
+
+The HEAD of the full key is just done for backwards compatability reasons.
+The problem is that it's not checking if the current chunk it's gonna
+upload is present in the remote. But, there is code in seekResume that
+is supposed to do that very check: `tryNonAsync (checker k)`
+
+Aha, the problem seems to be in the checkpresent action that's passed to
+that. Looks like it's passing in a dummy checkpresent action.
+
+I've fixed this in git, and now it resumes properly in my test case.
+"""]]
diff --git a/doc/forum/s3_special_remote_does_not_resume_uploads_even_with_new_chunking.mdwn b/doc/forum/s3_special_remote_does_not_resume_uploads_even_with_new_chunking.mdwn
deleted file mode 100644
index bc0755c..0000000
--- a/doc/forum/s3_special_remote_does_not_resume_uploads_even_with_new_chunking.mdwn
+++ /dev/null
@@ -1,88 +0,0 @@
-I'm trying to upload large files into s3 remote.  I'm using a very recent version of git-annex:
-
-    git-annex version: 5.20150616-g4d7683b
-    build flags: Assistant Webapp Webapp-secure Pairing Testsuite S3 WebDAV FsEvents 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
-
-Here's how my chunking is set up:
-
-    xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx bucket=mybucket chunk=256MiB cipher=xxxxxx cipherkeys=xxxxxx datacenter=US
-    host=s3.amazonaws.com name=mybucket port=80 s3creds=xxxxxx storageclass=STANDARD type=S3 timestamp=xxxxxx
-
-If I run an upload and `^C` it in the middle of the upload, then start it again, it will always resume from the beginning.
-
-I've proven this to myself by using the `--debug` switch, please see blow. I've renamed certain things for security reasons, however GPGHMACSHA1--1111111111 always refers to the same chunk and GPGHMACSHA1--2222222222 always refers to the same chunk, etc.
-
-You can see that even after it uploads the same chunk once, it tries again.
-
-This is consistent with the behavior of letting it sit there for an hour and upload half of the large file, and then interrupting it, and having it start from scratch again.

(Diff truncated)
Fix bug that prevented uploads to remotes using new-style chunking from resuming after the last successfully uploaded chunk.
"checkPresent baser" was wrong; the baser has a dummy checkPresent action
not the real one. So, to fix this, we need to call preparecheckpresent to
get a checkpresent action that can be used to check if chunks are present.
Note that, for remotes like S3, this means that the preparer is run,
which opens a S3 handle, that will be used for each checkpresent of a
chunk. That's a good thing; if we're resuming an upload that's already many
chunks in, it'll reuse that same http connection for each chunk it checks.
Still, it's not a perfectly ideal thing, since this is a different http
connection that the one that will be used to upload chunks. It would be
nice to improve the API so that both use the same http connection.
diff --git a/Remote/Helper/Special.hs b/Remote/Helper/Special.hs
index 483ef57..956d482 100644
--- a/Remote/Helper/Special.hs
+++ b/Remote/Helper/Special.hs
@@ -184,12 +184,14 @@ specialRemote' cfg c preparestorer prepareretriever prepareremover preparecheckp
 	-- chunk, then encrypt, then feed to the storer
 	storeKeyGen k f p enc = safely $ preparestorer k $ safely . go
 	  where
-		go (Just storer) = sendAnnex k rollback $ \src ->
+		go (Just storer) = preparecheckpresent k $ safely . go' storer
+		go Nothing = return False
+		go' storer (Just checker) = sendAnnex k rollback $ \src ->
 			displayprogress p k f $ \p' ->
 				storeChunks (uuid baser) chunkconfig k src p'
 					(storechunk enc storer)
-					(checkPresent baser)
-		go Nothing = return False
+					checker
+		go' _ Nothing = return False
 		rollback = void $ removeKey encr k
 
 	storechunk Nothing storer k content p = storer k content p
diff --git a/debian/changelog b/debian/changelog
index d8e468d..e494f9c 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -3,6 +3,8 @@ git-annex (5.20150714) UNRELEASED; urgency=medium
   * Improve bash completion code so that "git annex" will also tab
     complete. However, git's bash completion script needs a patch,
     which I've submitted, for this to work prefectly.
+  * Fix bug that prevented uploads to remotes using new-style chunking
+    from resuming after the last successfully uploaded chunk.
 
  -- Joey Hess <id@joeyh.name>  Thu, 16 Jul 2015 14:55:07 -0400
 
diff --git a/doc/forum/s3_special_remote_does_not_resume_uploads_even_with_new_chunking/comment_4_bd631d470ee0365a11483c9a2e563b32._comment b/doc/forum/s3_special_remote_does_not_resume_uploads_even_with_new_chunking/comment_4_bd631d470ee0365a11483c9a2e563b32._comment
new file mode 100644
index 0000000..ecac791
--- /dev/null
+++ b/doc/forum/s3_special_remote_does_not_resume_uploads_even_with_new_chunking/comment_4_bd631d470ee0365a11483c9a2e563b32._comment
@@ -0,0 +1,30 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2015-07-16T17:57:44Z"
+ content="""
+This should have been filed as a bug report... I will move the thread to
+bugs after posting this comment.
+
+In your obfuscated log, it tries to HEAD GPGHMACSHA1--1111111111
+and when that fails, it PUTs GPGHMACSHA1--2222222222. From this, we can
+deduce that GPGHMACSHA1--1111111111 is not the first chunk, but is the full
+non-chunked file, and GPGHMACSHA1--2222222222 is actually the first chunk.
+
+For testing, I modifed the S3 remote to make file uploads succeed, but then
+report to git-annex that they failed. So, git annex copy uploads the 1st
+chunk and then fails, same as it was interrupted there. Repeating the copy,
+I see the same thing; it HEADs the full key, does not HEAD the first chunk,
+and so doesn't notice it was uploaded before, and so re-uploads the first
+chunk.
+
+The HEAD of the full key is just done for backwards compatability reasons.
+The problem is that it's not checking if the current chunk it's gonna
+upload is present in the remote. But, there is code in seekResume that
+is supposed to do that very check: `tryNonAsync (checker k)`
+
+Aha, the problem seems to be in the checkpresent action that's passed to
+that. Looks like it's passing in a dummy checkpresent action.
+
+I've fixed this in git, and now it resumes properly in my test case.
+"""]]

response
diff --git a/doc/bugs/high_cpu_usage_in_cat-file_and_webapp/comment_1_7fee933eb54272a0447851279d31825b._comment b/doc/bugs/high_cpu_usage_in_cat-file_and_webapp/comment_1_7fee933eb54272a0447851279d31825b._comment
new file mode 100644
index 0000000..d926d72
--- /dev/null
+++ b/doc/bugs/high_cpu_usage_in_cat-file_and_webapp/comment_1_7fee933eb54272a0447851279d31825b._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-07-16T17:36:07Z"
+ content="""
+The most likely reason for the assistant to use CPU like this is when it's running
+the expensive transfer scan to find files that need to be copied from/to
+remotes. That has to consider every file in your repository's work
+tree, and uses git cat-file to extract information from the git
+repository to see where the file is currently located. This is normally
+only done when the assistant starts up.
+
+.git/annex/daemon.log will show when the expensive transfer scan starts and
+finishes. Look for "starting scan" and "finished scan" lines. Or, open the
+webapp and look to see what activities it says it's performing.
+"""]]

got bash completion working for "git annex" not just "git-annex"
This needs a patch to git to cause the git-annex completion to be
auto-loaded when completing "git annex <tab>". Otherwise, it will only
load when "git-annex" is tab completed. Once loaded, it works for both
uses. I've submitted the git patch to the git mailing list.
diff --git a/Makefile b/Makefile
index 2f7d3b2..ddc56e3 100644
--- a/Makefile
+++ b/Makefile
@@ -49,7 +49,7 @@ install: build install-docs Build/InstallDesktopFile
 	ln -sf git-annex $(DESTDIR)$(PREFIX)/bin/git-annex-shell
 	./Build/InstallDesktopFile $(PREFIX)/bin/git-annex || true
 	install -d $(DESTDIR)$(PREFIX)/share/bash-completion/completions
-	./git-annex --bash-completion-script git-annex > $(DESTDIR)$(PREFIX)/share/bash-completion/completions/git-annex
+	install -m 0644 bash-completion.bash $(DESTDIR)$(PREFIX)/share/bash-completion/completions/git-annex
 
 test: git-annex
 	./git-annex test
diff --git a/bash-completion.bash b/bash-completion.bash
new file mode 100644
index 0000000..b0367c0
--- /dev/null
+++ b/bash-completion.bash
@@ -0,0 +1,25 @@
+# Use git-annex's built-in bash completion
+# This bash completion is generated by the option parser, so it covers all
+# commands, all options, and will never go out of date!
+source <(git-annex --bash-completion-script git-annex)
+
+# Called by git's bash completion script when completing "git annex"
+_git_annex() {
+    local cmdline
+    CMDLINE=(--bash-completion-index $(($COMP_CWORD - 1)))
+
+    local seen_git
+    local seen_annex
+    for arg in ${COMP_WORDS[@]}; do
+        if [ "$arg" = git ] && [ -z "$seen_git" ]; then
+		seen_git=1
+		CMDLINE=(${CMDLINE[@]} --bash-completion-word git-annex)
+	elif [ "$arg" = annex ] && [ -z "$seen_annex" ]; then
+		seen_annex=1
+	else
+		CMDLINE=(${CMDLINE[@]} --bash-completion-word $arg)
+	fi
+    done
+
+    COMPREPLY=( $(git-annex "${CMDLINE[@]}") )
+}
diff --git a/doc/forum/bash_completion/comment_5_d45570fd750ae8d69dedc3edeef0cc10._comment b/doc/forum/bash_completion/comment_5_d45570fd750ae8d69dedc3edeef0cc10._comment
index 050c81d..d6797b5 100644
--- a/doc/forum/bash_completion/comment_5_d45570fd750ae8d69dedc3edeef0cc10._comment
+++ b/doc/forum/bash_completion/comment_5_d45570fd750ae8d69dedc3edeef0cc10._comment
@@ -3,13 +3,11 @@
  subject="""comment 5"""
  date="2015-07-15T15:44:11Z"
  content="""
-I've recently added built-in bash completion to git-annex, which is output
-by the `--bash-completion-script` option. It knows about all sub-commands,
+I've recently added built-in bash completion to git-annex, enabled by the
+`bash-completion.bash` file. It knows about all sub-commands,
 and all options, and will automatically always be up-to-date with the
 argument parser!
 
 Currently, it only works for completing "git-annex", not "git annex".
-Supporting the latter would probably require some hacks to git's own bash
-completion code, or possibly a smart way to hook into it.. Help with that
-would be appreciated.
+I have submitted a patch to git's bash completion to make the latter work.
 """]]
diff --git a/doc/git-annex.mdwn b/doc/git-annex.mdwn
index 5cbab59..73894c0 100644
--- a/doc/git-annex.mdwn
+++ b/doc/git-annex.mdwn
@@ -763,18 +763,6 @@ may not be explicitly listed on their individual man pages.
 
   Overrides git configuration settings. May be specified multiple times.
 
-# COMMAND-LINE TAB COMPLETION
-
-To enable bash completion, paste this into your shell prompt:
-
-	source <(git-annex --bash-completion-script git-annex)
-
-The output of "git-annex --bash-completion-script git-annex" can also
-be written to a bash completion file so bash loads it automatically.
-
-This bash completion is generated by the option parser, so it covers all
-commands, all options, and will never go out of date!
-
 # CONFIGURATION VIA .git/config
 
 Like other git commands, git-annex is configured via `.git/config`.

response
diff --git a/doc/forum/Trouble_adding_ssh_remote_using_assistant_on_windows/comment_3_8ddec87534a9025c26394fecd5456b84._comment b/doc/forum/Trouble_adding_ssh_remote_using_assistant_on_windows/comment_3_8ddec87534a9025c26394fecd5456b84._comment
new file mode 100644
index 0000000..07fefd2
--- /dev/null
+++ b/doc/forum/Trouble_adding_ssh_remote_using_assistant_on_windows/comment_3_8ddec87534a9025c26394fecd5456b84._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2015-07-15T16:05:01Z"
+ content="""
+git-remote-gcrpyt unfortunately is written as a shell script, so getting it
+to work on windows would probably be very hard unless it can be run with
+cygwin's shell somehow.
+"""]]

response
diff --git a/doc/forum/Can_the_assistant_sync_files_if_committed_manually___40__autocommit__61__false__41____63__/comment_1_bc838634442883e541de1ceab520d71e._comment b/doc/forum/Can_the_assistant_sync_files_if_committed_manually___40__autocommit__61__false__41____63__/comment_1_bc838634442883e541de1ceab520d71e._comment
new file mode 100644
index 0000000..fb0fbf4
--- /dev/null
+++ b/doc/forum/Can_the_assistant_sync_files_if_committed_manually___40__autocommit__61__false__41____63__/comment_1_bc838634442883e541de1ceab520d71e._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-07-15T16:01:30Z"
+ content="""
+Right, the assistant doesn't have a way to get notified of your manual
+commits, so it doesn't promptly push them.
+
+While the assistant could be modified to watch git branch files for changes,
+I think that for most people wanting to make manual commits, running `git
+annex sync --content` is a better approach. It does all the same syncing
+that the assistant would.
+"""]]

response
diff --git a/doc/forum/MD5_and_MD5E_backends_no_longer_available__63__/comment_1_e21fa57a2f2dc4e99737877c6a48cbfe._comment b/doc/forum/MD5_and_MD5E_backends_no_longer_available__63__/comment_1_e21fa57a2f2dc4e99737877c6a48cbfe._comment
new file mode 100644
index 0000000..549b115
--- /dev/null
+++ b/doc/forum/MD5_and_MD5E_backends_no_longer_available__63__/comment_1_e21fa57a2f2dc4e99737877c6a48cbfe._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-07-15T15:59:10Z"
+ content="""
+These have not been removed.
+
+Since they were first added in git-annex version 5.20150205,
+the most likely reason for your problem is if you're using an older version
+of git-annex than that. `git annex version` will tell you.
+"""]]

response
diff --git a/doc/forum/Use_password_protected_gpg_keypair_without_password_prompt__63__/comment_1_b177f16daeab7f02022f18154cfa1c3c._comment b/doc/forum/Use_password_protected_gpg_keypair_without_password_prompt__63__/comment_1_b177f16daeab7f02022f18154cfa1c3c._comment
new file mode 100644
index 0000000..b5dc5b4
--- /dev/null
+++ b/doc/forum/Use_password_protected_gpg_keypair_without_password_prompt__63__/comment_1_b177f16daeab7f02022f18154cfa1c3c._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-07-15T15:55:31Z"
+ content="""
+Any method that can be used to provide a passphrase to gpg should work. 
+
+For example, gpg-agent can cache the passphrase.
+
+Or, you could use gpg's passphrase-file option to make it read the
+passphrase from a file. This could be put in ~/.gnupg/gpg.conf.
+Although this configuration is probably no more secure than just removing
+the passphrase from the gpg key..
+"""]]

followup
diff --git a/doc/install/fromsource/comment_50_c1ce6084ba1e96afa30e18f0f6433aa4._comment b/doc/install/fromsource/comment_50_c1ce6084ba1e96afa30e18f0f6433aa4._comment
new file mode 100644
index 0000000..2e51353
--- /dev/null
+++ b/doc/install/fromsource/comment_50_c1ce6084ba1e96afa30e18f0f6433aa4._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 50"""
+ date="2015-07-15T15:54:15Z"
+ content="""
+Yes, Debian has a by now very outdated version of git-annex.
+
+You can clone git-annex's git repo and build a debian package from there;
+it's been updated for these changes.
+"""]]

comment
diff --git a/doc/todo/transfer_between_git-annexes/comment_3_adc2bfd00ffa6d85e68daabf7ad12aaa._comment b/doc/todo/transfer_between_git-annexes/comment_3_adc2bfd00ffa6d85e68daabf7ad12aaa._comment
new file mode 100644
index 0000000..3e90418
--- /dev/null
+++ b/doc/todo/transfer_between_git-annexes/comment_3_adc2bfd00ffa6d85e68daabf7ad12aaa._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2015-07-15T15:50:35Z"
+ content="""
+You can avoid the git-annex branch commits by passing -c
+annex.alwayscommit=false to git-annex commands. At the end, run `git annex
+merge` to commit all the changes in one go.
+
+The git-annex branch changes are temporarily stored in .git/anenx/journal/
+files if you wanted to delete them for rollback.
+"""]]

response
diff --git a/doc/forum/importfeed_does_not_work_with_youtube_anymore/comment_1_2fcbc85d7aa51dfdb2025a00c37fa8ac._comment b/doc/forum/importfeed_does_not_work_with_youtube_anymore/comment_1_2fcbc85d7aa51dfdb2025a00c37fa8ac._comment
new file mode 100644
index 0000000..9a76767
--- /dev/null
+++ b/doc/forum/importfeed_does_not_work_with_youtube_anymore/comment_1_2fcbc85d7aa51dfdb2025a00c37fa8ac._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-07-15T15:48:44Z"
+ content="""
+There's no API involved; git-annex importfeed consumes RSS feeds. Google no
+longer supports such reasonable technology.
+"""]]

update re builtin support
diff --git a/doc/forum/bash_completion/comment_5_d45570fd750ae8d69dedc3edeef0cc10._comment b/doc/forum/bash_completion/comment_5_d45570fd750ae8d69dedc3edeef0cc10._comment
new file mode 100644
index 0000000..050c81d
--- /dev/null
+++ b/doc/forum/bash_completion/comment_5_d45570fd750ae8d69dedc3edeef0cc10._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2015-07-15T15:44:11Z"
+ content="""
+I've recently added built-in bash completion to git-annex, which is output
+by the `--bash-completion-script` option. It knows about all sub-commands,
+and all options, and will automatically always be up-to-date with the
+argument parser!
+
+Currently, it only works for completing "git-annex", not "git annex".
+Supporting the latter would probably require some hacks to git's own bash
+completion code, or possibly a smart way to hook into it.. Help with that
+would be appreciated.
+"""]]

Added a comment
diff --git a/doc/todo/transfer_between_git-annexes/comment_2_2a494355a114a3df7ff0b35aa12ed10d._comment b/doc/todo/transfer_between_git-annexes/comment_2_2a494355a114a3df7ff0b35aa12ed10d._comment
new file mode 100644
index 0000000..e81266a
--- /dev/null
+++ b/doc/todo/transfer_between_git-annexes/comment_2_2a494355a114a3df7ff0b35aa12ed10d._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="CandyAngel"
+ subject="comment 2"
+ date="2015-07-15T10:20:55Z"
+ content="""
+Been thinking about this as I am getting close to needing it, but would like some advice.
+
+My current plan is to copy the symlink to the target annex, add it to the index (fix it?), copy the source file from $source/.git/annex/objects to $target/.git/annex/tmp, then use 'reinject $target/.git/annex/tmp/$keyed_file $path_to_symlink'.
+
+As far as I can tell, this is safest way (uses mostly git-annex) to transfer a file between annexes. However, when transferring a directory of files, this will end up with 1 commit per file on the git-annex branch, which may be a problem.
+
+Is there any easy way to make this \"atomic\", so that git-annex will only get a commit if everything went okay and if not, revert any changes to $target? Am I looking at 'git stash', recording the master/git-annex references before the move and resetting to them in case of an error or rebasing(fixup) git-annex on success?
+"""]]

diff --git a/doc/forum/importfeed_does_not_work_with_youtube_anymore.mdwn b/doc/forum/importfeed_does_not_work_with_youtube_anymore.mdwn
new file mode 100644
index 0000000..9d81b7e
--- /dev/null
+++ b/doc/forum/importfeed_does_not_work_with_youtube_anymore.mdwn
@@ -0,0 +1 @@
+Did youtube change their api? My youtube feeds doesn't work anymore. No problems with other sites.

removed
diff --git a/doc/install/verifying_downloads/comment_1_c216c2d7d42cc578caff815eba85f448._comment b/doc/install/verifying_downloads/comment_1_c216c2d7d42cc578caff815eba85f448._comment
deleted file mode 100644
index c1fbbb0..0000000
--- a/doc/install/verifying_downloads/comment_1_c216c2d7d42cc578caff815eba85f448._comment
+++ /dev/null
@@ -1,8 +0,0 @@
-[[!comment format=mdwn
- username="04448cae@7f89c9ec07b399265c20ea79b979d2afa5f75fa8"
- nickname="04448cae"
- subject="GPG Key"
- date="2015-07-12T03:23:07Z"
- content="""
-According to https://git-annex.branchable.com/install/verifying_downloads/ we should expect GPG key, C910D9222512E3C7 Joey Hess <id@joeyh.name> for this Windows installer file, but git-annex-installer.exe returns \"Signed on 2015-07-10 14:56 by id@joeyh.name (Key ID: 0x89C809CB). The validity of the signature cannot be verified.\" That key is on the keyserver http://pgp.surfnet.nl:11371/pks/lookup?op=vindex&fingerprint=on&search=0x89C809CB but doesn't match the verify page. Is this file legit, or the page in need of update? Thanks!
-"""]]

devblog
diff --git a/doc/devblog/day_300__optparse-applicative_landed.mdwn b/doc/devblog/day_300__optparse-applicative_landed.mdwn
new file mode 100644
index 0000000..e46dfce
--- /dev/null
+++ b/doc/devblog/day_300__optparse-applicative_landed.mdwn
@@ -0,0 +1,3 @@
+Worked through the rest of the changes this weekend and morning, and the
+optparse-applicative branch has landed in master,
+including bash completion support.

typo
diff --git a/doc/git-annex.mdwn b/doc/git-annex.mdwn
index e3790bd..5cbab59 100644
--- a/doc/git-annex.mdwn
+++ b/doc/git-annex.mdwn
@@ -770,7 +770,7 @@ To enable bash completion, paste this into your shell prompt:
 	source <(git-annex --bash-completion-script git-annex)
 
 The output of "git-annex --bash-completion-script git-annex" can also
-be written to a bash completion file so bach loads it automatically.
+be written to a bash completion file so bash loads it automatically.
 
 This bash completion is generated by the option parser, so it covers all
 commands, all options, and will never go out of date!

diff --git a/doc/forum/Can_the_assistant_sync_files_if_committed_manually___40__autocommit__61__false__41____63__.mdwn b/doc/forum/Can_the_assistant_sync_files_if_committed_manually___40__autocommit__61__false__41____63__.mdwn
index 7a100c6..2f1491a 100644
--- a/doc/forum/Can_the_assistant_sync_files_if_committed_manually___40__autocommit__61__false__41____63__.mdwn
+++ b/doc/forum/Can_the_assistant_sync_files_if_committed_manually___40__autocommit__61__false__41____63__.mdwn
@@ -2,3 +2,5 @@ I have some repositories where I want to manually control what files are added (
 However it seems that the assistant is not notified if I manually do a commit.
 
 The only solution right now seems to frequently restart the assistant since the startup scan will transfer files if required or run git annex get/copy manually.
+
+Is there another possibility?

diff --git a/doc/forum/Can_the_assistant_sync_files_if_committed_manually___40__autocommit__61__false__41____63__.mdwn b/doc/forum/Can_the_assistant_sync_files_if_committed_manually___40__autocommit__61__false__41____63__.mdwn
new file mode 100644
index 0000000..7a100c6
--- /dev/null
+++ b/doc/forum/Can_the_assistant_sync_files_if_committed_manually___40__autocommit__61__false__41____63__.mdwn
@@ -0,0 +1,4 @@
+I have some repositories where I want to manually control what files are added (autocommit=false), but would like to have the assistant/webapp automatically sync commits and transfer files.
+However it seems that the assistant is not notified if I manually do a commit.
+
+The only solution right now seems to frequently restart the assistant since the startup scan will transfer files if required or run git annex get/copy manually.

Added a comment: GPG Key
diff --git a/doc/install/verifying_downloads/comment_1_c216c2d7d42cc578caff815eba85f448._comment b/doc/install/verifying_downloads/comment_1_c216c2d7d42cc578caff815eba85f448._comment
new file mode 100644
index 0000000..c1fbbb0
--- /dev/null
+++ b/doc/install/verifying_downloads/comment_1_c216c2d7d42cc578caff815eba85f448._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="04448cae@7f89c9ec07b399265c20ea79b979d2afa5f75fa8"
+ nickname="04448cae"
+ subject="GPG Key"
+ date="2015-07-12T03:23:07Z"
+ content="""
+According to https://git-annex.branchable.com/install/verifying_downloads/ we should expect GPG key, C910D9222512E3C7 Joey Hess <id@joeyh.name> for this Windows installer file, but git-annex-installer.exe returns \"Signed on 2015-07-10 14:56 by id@joeyh.name (Key ID: 0x89C809CB). The validity of the signature cannot be verified.\" That key is on the keyserver http://pgp.surfnet.nl:11371/pks/lookup?op=vindex&fingerprint=on&search=0x89C809CB but doesn't match the verify page. Is this file legit, or the page in need of update? Thanks!
+"""]]

Add some information about Ubuntu Phone's
diff --git a/doc/install/Ubuntu/Phone.mdwn b/doc/install/Ubuntu/Phone.mdwn
new file mode 100644
index 0000000..8fccef4
--- /dev/null
+++ b/doc/install/Ubuntu/Phone.mdwn
@@ -0,0 +1,20 @@
+Ubuntu is available on multiple phones, and as they are running Ubuntu, git-annex can be installed.
+
+## Installation
+
+Use phablet-config writable-image to make the image writable.
+
+Then install git-annex using apt (apt install git-annex).
+
+## Issues
+
+The Debian package does not include the webapp:
+git-annex version: 5.20141125
+build flags: Assistant Pairing Testsuite S3 Inotify DBus DesktopNotify XMPP DNS Feeds Quvi TDFA CryptoHash
+key/value backends: SHA256E SHA1E SHA512E SHA224E SHA384E SKEIN256E SKEIN512E SHA256 SHA1 SHA512 SHA224 SHA384 SKEIN256 SKEIN512 WORM URL
+remote types: git gcrypt S3 bup directory rsync web tahoe glacier ddar hook external
+
+### Application Compatibility
+
+I have had difficulties getting the Music app to play music in a git-annex repository.
+

devblog
diff --git a/doc/devblog/day_299__so_many_commands_and_options.mdwn b/doc/devblog/day_299__so_many_commands_and_options.mdwn
new file mode 100644
index 0000000..04a2c1e
--- /dev/null
+++ b/doc/devblog/day_299__so_many_commands_and_options.mdwn
@@ -0,0 +1,9 @@
+Day 3 of the optparse-applicative conversion.  
+116 files changed, 1607 insertions(+), 1135 deletions(-)  
+At this point, everything is done except for around 20 sub-commands.
+Probably takes 15 minutes work for each. Will finish plowing through
+it in the evenings.
+
+Meanwhile, made the release of version 5.20150710. The Android build for
+this version is not available yet, since I broke the autobuilder last week
+and haven't fixed it yet.