Recent changes to this wiki:

response
diff --git a/doc/bugs/bash_completion_file_is_missing_in_the_6.20160527_tarball_on_hackage/comment_1_e8ed6b5705bf5fc7c3c85cee354b5bfd._comment b/doc/bugs/bash_completion_file_is_missing_in_the_6.20160527_tarball_on_hackage/comment_1_e8ed6b5705bf5fc7c3c85cee354b5bfd._comment
new file mode 100644
index 0000000..d4964bf
--- /dev/null
+++ b/doc/bugs/bash_completion_file_is_missing_in_the_6.20160527_tarball_on_hackage/comment_1_e8ed6b5705bf5fc7c3c85cee354b5bfd._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-05-31T15:56:20Z"
+ content="""
+The tarball on hackage is only there to make `cabal install git-annex` /
+`stack install git-annex`
+work, and that does not currently install the bash completion script.
+So, it's omitted.
+
+If you're using the tarball for some other purpose, it's never been a
+complete clone of git-annex, and it's rather less of one now, as documented
+in the CHANGELOG for this release. I recommend cloning from git to get
+the full source tree.
+"""]]

response
diff --git a/doc/forum/Problem_with_corrupt_SQLite_DB/comment_1_4e10e6d1882feba8d0c1ad058e01143c._comment b/doc/forum/Problem_with_corrupt_SQLite_DB/comment_1_4e10e6d1882feba8d0c1ad058e01143c._comment
new file mode 100644
index 0000000..ecb3206
--- /dev/null
+++ b/doc/forum/Problem_with_corrupt_SQLite_DB/comment_1_4e10e6d1882feba8d0c1ad058e01143c._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-05-31T15:53:32Z"
+ content="""
+Delete .git/annex/keys/db
+
+This database is not really needed unless your repository is in v6 mode.
+"""]]

Added a comment: subdirectories above FILEKEY directory
diff --git a/doc/special_remotes/directory/comment_17_01559b914ed43c4468e0980f3f794ea7._comment b/doc/special_remotes/directory/comment_17_01559b914ed43c4468e0980f3f794ea7._comment
new file mode 100644
index 0000000..bb6a890
--- /dev/null
+++ b/doc/special_remotes/directory/comment_17_01559b914ed43c4468e0980f3f794ea7._comment
@@ -0,0 +1,23 @@
+[[!comment format=mdwn
+ username="uwe.nagler@9f80ad68e498fcdb09e20b17ff4539f94ef73ea9"
+ nickname="uwe.nagler"
+ subject="subdirectories above FILEKEY directory"
+ date="2016-05-31T11:51:56Z"
+ content="""
+Format appears to be /BASE_DIR/xxx/yyy/FILEKEY/FILEKEY
+
+How can I get the xxx/yyy or the complete storage path of an annexed file in a fast way?
+
+Background:<br>
+I have to \"chmod\" the xxx/yyy within an '.git/hooks/pre-commit' action (shared used NFS location).<br>
+Following way using 'find' needs too much time in case of a big remote:
+
+    $ git annex info --fast inputbinaries | grep 'directory:' | awk '{print $2}'
+    /gitworkspace/inputbinaries/DWDM1830-all_playground
+
+    $ git annex info vendor-libs/x86/libsnmpdm.a | grep 'key:' | awk '{print $2}'
+    SHA256E-s3992448--82604383354b28f8efcdf8d83bb63607a8d5967551ded055e782ac342bb7f8e0.a
+
+    $ find /gitworkspace/inputbinaries/DWDM1830-all_playground -type f -name SHA256E-s3992448--82604383354b28f8efcdf8d83bb63607a8d5967551ded055e782ac342bb7f8e0.a
+    /gitworkspace/inputbinaries/DWDM1830-all_playground/28e/785/SHA256E-s3992448--82604383354b28f8efcdf8d83bb63607a8d5967551ded055e782ac342bb7f8e0.a/SHA256E-s3992448--82604383354b28f8efcdf8d83bb63607a8d5967551ded055e782ac342bb7f8e0.a
+"""]]

diff --git a/doc/forum/Problem_with_corrupt_SQLite_DB.mdwn b/doc/forum/Problem_with_corrupt_SQLite_DB.mdwn
new file mode 100644
index 0000000..7cc2a5d
--- /dev/null
+++ b/doc/forum/Problem_with_corrupt_SQLite_DB.mdwn
@@ -0,0 +1,17 @@
+Apparently, I managed to corrupt an SQLite DB when `git-annex get` ran out of space.  This prevents git-annex operations from
+working at all now.
+
+For example:
+
+    % git annex find --in .
+    sqlite worker thread crashed: SQLite3 returned ErrorError while attempting to perform prepare "SELECT null from content limit 1": no such table: content
+    git-annex: sqlite query crashed
+
+One of the few mentions of SQLite being used is in incremental fsck
+([[design/caching_database]]).  I did run incremental fsck in
+another repository a few days before this.  The fsck finished
+without issues, so I'd be happy with a solution that involves simply
+deleting the DB or something.
+
+- git-annex version: 6.20160527-gb7d4774
+- All repositories/remotes: version 5, indirect

Added a comment
diff --git a/doc/bugs/__34__invalid_object__34___errors_cropping_up/comment_2_6585b15aa7ae63175482d08b2b5b79fc._comment b/doc/bugs/__34__invalid_object__34___errors_cropping_up/comment_2_6585b15aa7ae63175482d08b2b5b79fc._comment
new file mode 100644
index 0000000..72417ff
--- /dev/null
+++ b/doc/bugs/__34__invalid_object__34___errors_cropping_up/comment_2_6585b15aa7ae63175482d08b2b5b79fc._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="xloem"
+ subject="comment 2"
+ date="2016-05-29T02:02:38Z"
+ content="""
+This has occurred for me yet again, after starting a new remote.
+
+Strangely 'git fsck' succeeds, showing only dangling objects, but 'git annex sync' fails on commit with this error.
+
+litelog is a set of service scripts I'm making which automatically record and log from devices when they are connected.  Voice recorder and sensor logs are copied off of android phones from a handful of supported apps.
+"""]]

diff --git a/doc/bugs/gcrypt_special_remote_not_being_encrypted.mdwn b/doc/bugs/gcrypt_special_remote_not_being_encrypted.mdwn
index b264fca..2185bec 100644
--- a/doc/bugs/gcrypt_special_remote_not_being_encrypted.mdwn
+++ b/doc/bugs/gcrypt_special_remote_not_being_encrypted.mdwn
@@ -9,7 +9,7 @@ On the first machine:
 cd MyStuffs
 git init
 git annex init "Macbook"
-cat "First file" > first.txt
+echo "First file" > first.txt
 git annex add .
 git commit -a -m added
 git annex initremote personal-server type=gcrypt gitrepo=ssh://user@foo.bar.com/home/user/MyStuffs keyid=XXXXXXXXX
@@ -23,7 +23,7 @@ On second machine
 git clone gcrypt::ssh://user@foo.bar.com/home/user/MyStuffs test
 git annex enableremote personal-server gitrepo=ssh://user@foo.bar.com/home/user/MyStuffs 
 cd test 
-cat "BananaTest" > test
+echo "BananaTest" > test
 git annex add .
 git commit -a -m added
 git annex sync --content

diff --git a/doc/bugs/bash_completion_file_is_missing_in_the_6.20160527_tarball_on_hackage.mdwn b/doc/bugs/bash_completion_file_is_missing_in_the_6.20160527_tarball_on_hackage.mdwn
new file mode 100644
index 0000000..5bea510
--- /dev/null
+++ b/doc/bugs/bash_completion_file_is_missing_in_the_6.20160527_tarball_on_hackage.mdwn
@@ -0,0 +1 @@
+The bash-completion.bash was gone in the 6.20160527 tarball on hackage. It used to be inside the tarball in <= 6.20160511 versions.

devblog
diff --git a/doc/devblog/day_395__leaky_abstractions.mdwn b/doc/devblog/day_395__leaky_abstractions.mdwn
new file mode 100644
index 0000000..41bce37
--- /dev/null
+++ b/doc/devblog/day_395__leaky_abstractions.mdwn
@@ -0,0 +1,7 @@
+Release today includes a last-minute fix to parsing lines from the
+git-annex branch that might have one or more carriage returns at the end.
+This comes from Windows of course, where since some things transparently
+add/remove `\r` before the end of lines, while other things don't,
+it could result in quite a mess. Luckily it was not hard or expensive to
+handle. If you are lucky enough not to use Windows, the release also
+has several more interesting improvements.

Windows: Avoid terminating git-annex branch lines with \r\n when union merging.
diff --git a/CHANGELOG b/CHANGELOG
index ff09e72..5daca23 100644
--- a/CHANGELOG
+++ b/CHANGELOG
@@ -1,6 +1,8 @@
 git-annex (6.20160528) UNRELEASED; urgency=medium
 
   * Improve SHA*E extension extraction code.
+  * Windows: Avoid terminating git-annex branch lines with \r\n when
+    union merging and performing transitions.
 
  -- Joey Hess <id@joeyh.name>  Fri, 27 May 2016 13:12:48 -0400
 
diff --git a/Git/HashObject.hs b/Git/HashObject.hs
index 07c72d0..ed3baf4 100644
--- a/Git/HashObject.hs
+++ b/Git/HashObject.hs
@@ -5,6 +5,8 @@
  - Licensed under the GNU GPL version 3 or higher.
  -}
 
+{-# LANGUAGE CPP #-}
+
 module Git.HashObject where
 
 import Common
@@ -39,6 +41,10 @@ hashFile h file = CoProcess.query h send receive
  - interface does not allow batch hashing without using temp files. -}
 hashBlob :: HashObjectHandle -> String -> IO Sha
 hashBlob h s = withTmpFile "hash" $ \tmp tmph -> do
+	fileEncoding tmph
+#ifdef mingw32_HOST_OS
+	hSetNewlineMode tmph noNewlineTranslation
+#endif
 	hPutStr tmph s
 	hClose tmph
 	hashFile h tmp
diff --git a/doc/bugs/Whereis_reports_same_UUID_multiple_times.mdwn b/doc/bugs/Whereis_reports_same_UUID_multiple_times.mdwn
index baeea5e..249576b 100644
--- a/doc/bugs/Whereis_reports_same_UUID_multiple_times.mdwn
+++ b/doc/bugs/Whereis_reports_same_UUID_multiple_times.mdwn
@@ -92,3 +92,6 @@ I am running "git-annex version: 6.20160511-g4633f0b" on Windows, but I have bee
 ### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
 Yes it is working very nicely on all my linux computers, and right now I am mostly concerned that I might have messed up the repository by trying out Windows :-(.
 
+> [[fixed|done]]; repositories in this state are now handled appropriately
+> by git-annex. And, I've fixed at least the places I was able to identify
+> where '\r' slipped in. --[[Joey]]
diff --git a/doc/bugs/Whereis_reports_same_UUID_multiple_times/comment_6_d3adcfad215b3f39cc5bc3ff248e4b86._comment b/doc/bugs/Whereis_reports_same_UUID_multiple_times/comment_6_d3adcfad215b3f39cc5bc3ff248e4b86._comment
new file mode 100644
index 0000000..3095137
--- /dev/null
+++ b/doc/bugs/Whereis_reports_same_UUID_multiple_times/comment_6_d3adcfad215b3f39cc5bc3ff248e4b86._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-05-27T19:03:05Z"
+ content="""
+Union merge on windows does indeed add \r onto lines. 
+
+Looks like hashBlob is at fault; it writes a string to a temp file,
+and the IO layer does CRLF conversion at that point. 
+
+The git-annex branch transition code also uses hashBlob so would also
+do it.
+
+So I've reproduced the root cause of this now. Fixing..
+"""]]

Improve SHA*E extension extraction code.
Filter out over-long "extensions" before stripping out non-alphanumerics
from them, so that eg "foo.ba__________r" is not considered a .bar
extension.
diff --git a/Backend/Hash.hs b/Backend/Hash.hs
index fd51d87..ba8d4bc 100644
--- a/Backend/Hash.hs
+++ b/Backend/Hash.hs
@@ -101,8 +101,9 @@ selectExtension f
 	| otherwise = intercalate "." ("":es)
   where
 	es = filter (not . null) $ reverse $
-		take 2 $ takeWhile shortenough $
-		reverse $ split "." $ filter validInExtension $ takeExtensions f
+		take 2 $ map (filter validInExtension) $
+		takeWhile shortenough $
+		reverse $ split "." $ takeExtensions f
 	shortenough e = length e <= 4 -- long enough for "jpeg"
 
 {- A key's checksum is checked during fsck. -}
diff --git a/CHANGELOG b/CHANGELOG
index 5b1502e..ff09e72 100644
--- a/CHANGELOG
+++ b/CHANGELOG
@@ -1,3 +1,9 @@
+git-annex (6.20160528) UNRELEASED; urgency=medium
+
+  * Improve SHA*E extension extraction code.
+
+ -- Joey Hess <id@joeyh.name>  Fri, 27 May 2016 13:12:48 -0400
+
 git-annex (6.20160527) unstable; urgency=medium
 
   * Split lines in the git-annex branch on \r as well as \n, to deal
diff --git a/doc/bugs/strips___95___from_extensions_in_E_backends__63__.mdwn b/doc/bugs/strips___95___from_extensions_in_E_backends__63__.mdwn
index 30bda2b..e0785b3 100644
--- a/doc/bugs/strips___95___from_extensions_in_E_backends__63__.mdwn
+++ b/doc/bugs/strips___95___from_extensions_in_E_backends__63__.mdwn
@@ -13,3 +13,5 @@ lrwxrwxrwx 1 yoh yoh 126 May 25 14:27 ds001_R1.1.0_raw.tgz -> .git/annex/objects
 """]]
 
 [[!meta author=yoh]]
+
+> [[fixed|done]] --[[Joey]]

comment
diff --git a/doc/bugs/strips___95___from_extensions_in_E_backends__63__/comment_1_9a3d0866b5c54f6f5dca59c39960e28f._comment b/doc/bugs/strips___95___from_extensions_in_E_backends__63__/comment_1_9a3d0866b5c54f6f5dca59c39960e28f._comment
new file mode 100644
index 0000000..069dc7f
--- /dev/null
+++ b/doc/bugs/strips___95___from_extensions_in_E_backends__63__/comment_1_9a3d0866b5c54f6f5dca59c39960e28f._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-05-27T17:06:41Z"
+ content="""
+Non-alphanumerics are stripped.
+
+This also results in a file "foo.ba________________________r" having
+".bar" picked as its extension.
+
+I think the fix is to filter out over-long "extensions" before stripping
+the non-alphanumerics.
+"""]]

add news item for git-annex 6.20160527
diff --git a/doc/news/version_6.20160412.mdwn b/doc/news/version_6.20160412.mdwn
deleted file mode 100644
index babe005..0000000
--- a/doc/news/version_6.20160412.mdwn
+++ /dev/null
@@ -1,21 +0,0 @@
-git-annex 6.20160412 released with [[!toggle text="these changes"]]
-[[!toggleable text="""
-   * adjust --unlock: Enters an adjusted branch in which all annexed files
-     are unlocked. The v6 equivilant of direct mode, but much cleaner!
-   * Upgrading a direct mode repository to v6 has changed to enter
-     an adjusted unlocked branch. This makes the direct mode to v6 upgrade
-     able to be performed in one clone of a repository without affecting
-     other clones, which can continue using v5 and direct mode.
-   * init --version=6: Automatically enter the adjusted unlocked branch
-     when filesystem doesn't support symlinks.
-   * ddar remote: fix ssh calls
-     Thanks, Robie Basak
-   * log: Display time with time zone.
-   * log --raw-date: Use to display seconds from unix epoch.
-   * v6: Close pointer file handles more quickly, to avoid problems on Windows.
-   * sync: Show output of git commit.
-   * annex.thin and annex.hardlink are now supported on Windows.
-   * unannex --fast now makes hard links on Windows.
-   * Fix bug in annex.largefiles mimetype= matching when git-annex
-     is run in a subdirectory of the repository.
-   * Fix build with ghc v7.11. Thanks, Gabor Greif."""]]
\ No newline at end of file
diff --git a/doc/news/version_6.20160418.mdwn b/doc/news/version_6.20160418.mdwn
deleted file mode 100644
index a353a4d..0000000
--- a/doc/news/version_6.20160418.mdwn
+++ /dev/null
@@ -1,22 +0,0 @@
-git-annex 6.20160418 released with [[!toggle text="these changes"]]
-[[!toggleable text="""
-   * smudge: Print a warning when annex.thin is set, as git's smudge
-     interface does not allow honoring that configuration.
-   * webapp: When $HOME is a git repository, and has been initialized for
-     use by git-annex, opening the webapp went ahead and ran the assistant
-     there, annexing all files. Since this is almost certianly not
-     desirable, especially when the user is just opening the webapp from
-     a dekstop menu which happens to run it in $HOME, the webapp will now not
-     treat such a $HOME git repository as a git-annex repository.
-   * webapp: Update url to add gitlab.com ssh key.
-   * Fix bug in v6 mode that prevented treating unlocked executable files
-     as annexed. If you have such files, run git annex init --version=6
-     to update the cache after upgrading to this version of git-annex.
-   * Preserve execute bits of unlocked files in v6 mode.
-   * fsck: Warn when core.sharedRepository is set and an annex object file's
-     write bit is not set and cannot be set due to the file being owned
-     by a different user.
-   * Fix hang when dropping content needs to lock the content on a
-     ssh remote, which occurred when the remote has git-annex version
-     5.20151019 or newer. (The bug was in the client side; the remote
-     git-annex-shell does not need to be upgraded.)"""]]
\ No newline at end of file
diff --git a/doc/news/version_6.20160527.mdwn b/doc/news/version_6.20160527.mdwn
new file mode 100644
index 0000000..ee91d85
--- /dev/null
+++ b/doc/news/version_6.20160527.mdwn
@@ -0,0 +1,37 @@
+git-annex 6.20160527 released with [[!toggle text="these changes"]]
+[[!toggleable text="""
+   * Split lines in the git-annex branch on \r as well as \n, to deal
+     with \r\n terminated lines written by some versions of git-annex on
+     Windows. This fixes strange displays in some cases.
+   * assistant: Fix bug that caused v6 pointer files to be annexed by the
+     assistant.
+   * assistant: Fix race in v6 mode that caused downloaded file content to
+     sometimes not replace pointer files.
+   * add: Adding a v6 pointer file used to annex it; now the pointer file is
+     added to git as-is. (git add of a pointer file already did the right
+     thing)
+   * enableremote: Can now be used to explicitly enable git-annex to use
+     git remotes. Using the command this way prevents other git-annex
+     commands from probing new git remotes to auto-enable them.
+   * enableremote: Remove annex-ignore configuration from a remote.
+   * Change git annex info remote encryption description to use wording
+     closer to what's used in initremote.
+   * Pass the various gnupg-options configs to gpg in several cases where
+     they were not before. Most notably, gnupg-decrypt-options is now
+     passed when decrypting an encrypted cipher.
+   * adjust: Add --fix adjustment, which is useful when the git directory
+     is in a nonstandard place.
+   * adjust: If the adjusted branch already exists, avoid overwriting it,
+     since it might contain changes that have not yet been propigated to the
+     original branch.
+   * Work around git weirdness in handling of relative path to GIT\_INDEX\_FILE
+     when in a subdirectory of the repository. This affected git annex view.
+   * Fix crash when entering/changing view in a subdirectory of a repo that
+     has a dotfile in its root.
+   * webapp: Avoid confusing display of dead remotes.
+   * Support building with ghc 8.0.1.
+   * Updated cabal file explicitly lists source files. The tarball
+     on hackage will include only the files needed for cabal install;
+     it is NOT the full git-annex source tree.
+   * debian/changelog, debian/NEWS, debian/copyright: Converted to symlinks
+     to CHANGELOG, NEWS, and COPYRIGHT, which used to symlink to these instead."""]]
\ No newline at end of file

comment
diff --git a/doc/contribute/comment_2_637b05cfd48d2e337c3192989356d183._comment b/doc/contribute/comment_2_637b05cfd48d2e337c3192989356d183._comment
new file mode 100644
index 0000000..c57755a
--- /dev/null
+++ b/doc/contribute/comment_2_637b05cfd48d2e337c3192989356d183._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2016-05-27T15:45:49Z"
+ content="""
+Please open [[todo]] items for patches, don't send them as comments here.
+
+(I suspect that the patch as provided might break compilation with old
+versions of ghc, or old versions of yesod..)
+"""]]

Split lines in the git-annex branch on \r as well as \n, to deal with \r\n terminated lines written by some versions of git-annex on Windows.
This fixes strange displays in some cases, including whereis showing
many duplicate locations, and showing more total copies than actually
exist.
It's unknown if that lead to data loss when eg, dropping. At the moment,
it seems unlikely it could, since the UUID with \r's appended is not the
same as a UUID without, and so no remote matches it.
It's also unknown if \r's can leak in on windows, perhaps when merging the
git-annex branch.
diff --git a/CHANGELOG b/CHANGELOG
index e58c6ee..0c5b6db 100644
--- a/CHANGELOG
+++ b/CHANGELOG
@@ -1,5 +1,8 @@
 git-annex (6.20160512) UNRELEASED; urgency=medium
 
+  * Split lines in the git-annex branch on \r as well as \n, to deal
+    with \r\n terminated lines written by some versions of git-annex on
+    Windows. This fixes strange displays in some cases.
   * Change git annex info remote encryption description to use wording
     closer to what's used in initremote.
   * webapp: Avoid confusing display of dead remotes.
diff --git a/COPYRIGHT b/COPYRIGHT
index 6620962..119bbf6 100644
--- a/COPYRIGHT
+++ b/COPYRIGHT
@@ -95,6 +95,38 @@ License: MIT-twitter
   OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
   THE SOFTWARE.
 
+Files: Logs/Line.hs
+Copyright: 2001, The University Court of the University of Glasgow.
+License: other
+  All rights reserved.
+  .
+  Redistribution and use in source and binary forms, with or without
+  modification, are permitted provided that the following conditions are met:
+  .
+  - Redistributions of source code must retain the above copyright notice,
+  this list of conditions and the following disclaimer.
+  .
+  - Redistributions in binary form must reproduce the above copyright notice,
+  this list of conditions and the following disclaimer in the documentation
+  and/or other materials provided with the distribution.
+  .
+  - Neither name of the University nor the names of its contributors may be
+  used to endorse or promote products derived from this software without
+  specific prior written permission.
+  .
+  THIS SOFTWARE IS PROVIDED BY THE UNIVERSITY COURT OF THE UNIVERSITY OF
+  GLASGOW AND THE CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES,
+  INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND
+  FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
+  UNIVERSITY COURT OF THE UNIVERSITY OF GLASGOW OR THE CONTRIBUTORS BE LIABLE
+  FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+  DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
+  SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
+  CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+  LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+  OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH
+  DAMAGE.
+
 License: GPL-3+
  The full text of version 3 of the GPL is distributed as doc/license/GPL in
  this package's source, or in /usr/share/common-licenses/GPL-3 on
diff --git a/Logs/Line.hs b/Logs/Line.hs
new file mode 100644
index 0000000..a7e1719
--- /dev/null
+++ b/Logs/Line.hs
@@ -0,0 +1,51 @@
+{- 
+
+The Glasgow Haskell Compiler License
+
+Copyright 2001, The University Court of the University of Glasgow.
+All rights reserved.
+
+Redistribution and use in source and binary forms, with or without
+modification, are permitted provided that the following conditions are met:
+
+- Redistributions of source code must retain the above copyright notice,
+this list of conditions and the following disclaimer.
+
+- Redistributions in binary form must reproduce the above copyright notice,
+this list of conditions and the following disclaimer in the documentation
+and/or other materials provided with the distribution.
+
+- Neither name of the University nor the names of its contributors may be
+used to endorse or promote products derived from this software without
+specific prior written permission.
+
+THIS SOFTWARE IS PROVIDED BY THE UNIVERSITY COURT OF THE UNIVERSITY OF
+GLASGOW AND THE CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES,
+INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND
+FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
+UNIVERSITY COURT OF THE UNIVERSITY OF GLASGOW OR THE CONTRIBUTORS BE LIABLE
+FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
+SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
+CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH
+DAMAGE.
+
+-}
+
+module Logs.Line where
+
+-- This is the same as Data.List.lines, with \r added.
+-- This works around some versions of git-annex which wrote \r
+-- into git-annex branch files on Windows. Those \r's sometimes
+-- accumulated over time, so a single line could end with multiple \r's
+-- before the \n.
+splitLines :: String -> [String]
+splitLines "" =  []
+splitLines s =  cons (case break (\c -> c == '\n' || c == '\r') s of
+	(l, s') -> (l, case s' of
+		[]      -> []
+		_:s''   -> splitLines s''))
+  where
+	cons ~(h, t) = h : t
diff --git a/Logs/MapLog.hs b/Logs/MapLog.hs
index d5bb67f..097439a 100644
--- a/Logs/MapLog.hs
+++ b/Logs/MapLog.hs
@@ -18,6 +18,7 @@ import Data.Time.Clock.POSIX
 
 import Common
 import Logs.TimeStamp
+import Logs.Line
 
 data TimeStamp = Unknown | Date POSIXTime
 	deriving (Eq, Ord, Show)
@@ -38,7 +39,7 @@ showMapLog fieldshower valueshower = unlines . map showpair . M.toList
 		unwords ["0", fieldshower f, valueshower v]
 
 parseMapLog :: Ord f => (String -> Maybe f) -> (String -> Maybe v) -> String -> MapLog f v
-parseMapLog fieldparser valueparser = M.fromListWith best . mapMaybe parse . lines
+parseMapLog fieldparser valueparser = M.fromListWith best . mapMaybe parse . splitLines
   where
 	parse line = do
 		let (ts, rest) = splitword line
diff --git a/Logs/Presence/Pure.hs b/Logs/Presence/Pure.hs
index e2ec3f1..7955c8d 100644
--- a/Logs/Presence/Pure.hs
+++ b/Logs/Presence/Pure.hs
@@ -12,6 +12,7 @@ import qualified Data.Map as M
 
 import Annex.Common
 import Logs.TimeStamp
+import Logs.Line
 import Utility.QuickCheck
 
 data LogLine = LogLine {
@@ -25,7 +26,7 @@ data LogStatus = InfoPresent | InfoMissing | InfoDead
 
 {- Parses a log file. Unparseable lines are ignored. -}
 parseLog :: String -> [LogLine]
-parseLog = mapMaybe parseline . lines
+parseLog = mapMaybe parseline . splitLines
   where
 	parseline l = LogLine
 		<$> parsePOSIXTime d
diff --git a/Logs/SingleValue.hs b/Logs/SingleValue.hs
index 9b1306c..201e205 100644
--- a/Logs/SingleValue.hs
+++ b/Logs/SingleValue.hs
@@ -16,6 +16,7 @@ module Logs.SingleValue where
 import Annex.Common
 import qualified Annex.Branch
 import Logs.TimeStamp
+import Logs.Line
 
 import qualified Data.Set as S
 import Data.Time.Clock.POSIX
@@ -37,7 +38,7 @@ showLog = unlines . map showline . S.toList
 	showline (LogEntry t v) = unwords [show t, serialize v]
 
 parseLog :: (Ord v, SingleValueSerializable v) => String -> Log v
-parseLog = S.fromList . mapMaybe parse . lines
+parseLog = S.fromList . mapMaybe parse . splitLines
   where
 	parse line = do
 		let (ts, s) = splitword line
diff --git a/Logs/Transitions.hs b/Logs/Transitions.hs
index 5440047..07667c4 100644
--- a/Logs/Transitions.hs
+++ b/Logs/Transitions.hs
@@ -19,6 +19,7 @@ import qualified Data.Set as S
 
 import Annex.Common
 import Logs.TimeStamp
+import Logs.Line
 
 transitionsLog :: FilePath
 transitionsLog = "transitions.log"
@@ -50,7 +51,7 @@ showTransitions = unlines . map showTransitionLine . S.elems
 
 {- If the log contains new transitions we don't support, returns Nothing. -}
 parseTransitions :: String -> Maybe Transitions
-parseTransitions = check . map parseTransitionLine . lines
+parseTransitions = check . map parseTransitionLine . splitLines
   where
 	check l
 		| all isJust l = Just $ S.fromList $ catMaybes l
diff --git a/Logs/UUIDBased.hs b/Logs/UUIDBased.hs
index 5613c6f..97ecd10 100644
--- a/Logs/UUIDBased.hs

(Diff truncated)
followup
diff --git a/doc/bugs/Whereis_reports_same_UUID_multiple_times/comment_4_d26052bc19fbb6eaa84b2d72c280f11a._comment b/doc/bugs/Whereis_reports_same_UUID_multiple_times/comment_4_d26052bc19fbb6eaa84b2d72c280f11a._comment
new file mode 100644
index 0000000..92f711e
--- /dev/null
+++ b/doc/bugs/Whereis_reports_same_UUID_multiple_times/comment_4_d26052bc19fbb6eaa84b2d72c280f11a._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2016-05-27T15:02:05Z"
+ content="""
+In git-annex version 5.20140606, we have:
+
+	  * Windows: Fix bug introduced in last release that caused files
+	    in the git-annex branch to have lines teminated with \r.
+
+There was only 1 week where git-annex had that bug AFAIK, but of
+course the broken version could have kept on being used for some time.
+
+It's also always possible that this same problem popped up again in the
+code. The fix in 1ab3d7c81049e4ce7e8e47800e2ef1fecb3a9ab4 was to
+Annex.Journal and that still seems ok. The merge code is another place
+this could perhaps happen.
+"""]]

followup
diff --git a/doc/bugs/Whereis_reports_same_UUID_multiple_times/comment_3_96eeccef3cf2678b30b892cb264bc7e1._comment b/doc/bugs/Whereis_reports_same_UUID_multiple_times/comment_3_96eeccef3cf2678b30b892cb264bc7e1._comment
new file mode 100644
index 0000000..7c4b483
--- /dev/null
+++ b/doc/bugs/Whereis_reports_same_UUID_multiple_times/comment_3_96eeccef3cf2678b30b892cb264bc7e1._comment
@@ -0,0 +1,30 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2016-05-27T14:47:40Z"
+ content="""
+I tried reproducing this artificially by duplicating a presence log line.
+That didn't work; whereis showed only 1 copy, not multiple ones.
+Which makes sense, because the log reader makes a map that has the UUID as
+the key. So a single UUID can't appear more than once at that point. Good!
+
+So, there's something else going on in the problem repository that
+allows this behavior to occur.
+
+Aha! It's sequences of one or more `\r` at the end of the line.
+
+	fromList [("0866153a-19e5-4382-aeb6-30e8210706cc",LogLine {date = 1444995329.589s, status = InfoPresent, info = "0866153a-19e5-4382-aeb6-30e8210706cc"}),("0866153a-19e5-4382-aeb6-30e8210706cc\r",LogLine {date = 1444995329.589s, status = InfoPresent, info = "0866153a-19e5-4382-aeb6-30e8210706cc\r"}),("0866153a-19e5-4382-aeb6-30e8210706cc\r\r",LogLine {date = 1444995329.589s, status = InfoPresent, info = "0866153a-19e5-4382-aeb6-30e8210706cc\r\r"}) ...
+
+So, 0866153a-19e5-4382-aeb6-30e8210706cc seems to appear multiple times, but it's really due to these `\r`'s.
+
+Suspect this means that this problem only impacts display. It should not lead
+to data loss, because no remote will have a UUID ending in `\r', so there
+should be no way for git-annex to somehow count a remote twice as containing
+a copy of a file when dropping. Indeed, we can see in the whereis output that
+it only matches up some instances of the "duplicate" uuid with remotes -- because
+the other instances have carriage returns appended.
+
+Also, this suggests that the reason the duplicate lines occurred in the first
+place was something to do with a windows system, which presumably added some
+`\r\n` that is being stumbled over.
+"""]]

analysis
diff --git a/doc/bugs/Whereis_reports_same_UUID_multiple_times/comment_2_148e8a83da7f9208ab7e0619b70b7093._comment b/doc/bugs/Whereis_reports_same_UUID_multiple_times/comment_2_148e8a83da7f9208ab7e0619b70b7093._comment
new file mode 100644
index 0000000..2c9b917
--- /dev/null
+++ b/doc/bugs/Whereis_reports_same_UUID_multiple_times/comment_2_148e8a83da7f9208ab7e0619b70b7093._comment
@@ -0,0 +1,43 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2016-05-27T14:26:18Z"
+ content="""
+Received a clone of this repository (in git-annex-test-repos/annex.bundle
+here), and was able to reproduce the bug.
+
+Looking at one duplicate UUID for one file, I see:
+
+	1444995510.830128s 1 0866153a-19e5-4382-aeb6-30e8210706cc
+	1444995510.830128s 1 0866153a-19e5-4382-aeb6-30e8210706cc
+	1444995510.830128s 1 0866153a-19e5-4382-aeb6-30e8210706cc
+	1444995510.830128s 1 0866153a-19e5-4382-aeb6-30e8210706cc
+	1444995510.830128s 1 0866153a-19e5-4382-aeb6-30e8210706cc
+
+The notable thing here is not that there are multiple lines for a UUID, but
+that they somehow have the *exact* same timestamp down to the
+microsecond.
+
+I'm a) unsure how this could happen and b) afraid that the log file
+compaction fails in this case, with catastrophic results.
+
+Regarding how this could happen, git blame shows a single commit
+adding duplicate lines with the same timestamp. Commit message was
+"update". The commit touched a wide swath of the repository, including even
+non-location-log files like trust.log, which also got duplicate lines with
+the same timestamp.
+
+Some of the lines were entirely new, but some existing lines also
+got duplicated.
+
+There were some duplicate lines before this commit, so it was not an
+isolated incident.
+
+Clearly, log compaction needs to collapse down lines that are identical except
+for timestamp. The location log code also needs to throw out all but one
+current item for a given uuid, since other code treats each returned location
+as a copy, expecting there to not be any duplicate UUIDs. With these changes,
+whatever caused these duplicate lines to occur in the first place at least
+won't result in weird output or data loss. I have not verified yet if data
+loss can actually occur in this case.
+"""]]

Added a comment: GHC HEAD warnings
diff --git a/doc/contribute/comment_1_c61530e14bdbd7c5ec8b0137c0da92f8._comment b/doc/contribute/comment_1_c61530e14bdbd7c5ec8b0137c0da92f8._comment
new file mode 100644
index 0000000..0b43b3f
--- /dev/null
+++ b/doc/contribute/comment_1_c61530e14bdbd7c5ec8b0137c0da92f8._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="ggreif@8132a868199b4ffec14150c87f538dc06a538220"
+ nickname="ggreif"
+ subject="GHC HEAD warnings"
+ date="2016-05-27T14:21:11Z"
+ content="""
+I have a patch:
+
+https://github.com/ggreif/git-annex/tree/patch-1
+
+It heals e.g.
+
+    Assistant/WebApp/Form.hs:52:1: warning: [-Wredundant-constraints]
+        ? Redundant constraint: Monad m
+        ? In the type signature for:
+               withNote :: (Monad m, ToWidget (HandlerSite m) a) =>
+                           Field m v -> a -> Field m v
+
+"""]]

diff --git a/doc/bugs/strips___95___from_extensions_in_E_backends__63__.mdwn b/doc/bugs/strips___95___from_extensions_in_E_backends__63__.mdwn
new file mode 100644
index 0000000..30bda2b
--- /dev/null
+++ b/doc/bugs/strips___95___from_extensions_in_E_backends__63__.mdwn
@@ -0,0 +1,15 @@
+in my obscure case filename is ds001_R1.1.0_raw.tgz  and resultant extension annex takes for the E backend is .0raw.tgz which is formed from .0_raw.tgz with _ removed.  IMHO if _ is not expected in the extensions, the target extension then should have been just .tgz.  If it does expect/allow for _ in extension -- should have been .0_raw.tgz
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+$> f=ds001_R1.1.0_raw.tgz; rm -rf /tmp/repo1; mkdir /tmp/repo1; cd /tmp/repo1; git init; git annex init ; echo 123>$f; git annex add --backend MD5E $f; ls -ld $f              
+Initialized empty Git repository in /tmp/repo1/.git/
+init  ok
+(recording state in git...)
+add ds001_R1.1.0_raw.tgz ok
+(recording state in git...)
+lrwxrwxrwx 1 yoh yoh 126 May 25 14:27 ds001_R1.1.0_raw.tgz -> .git/annex/objects/g5/jW/MD5E-s4--ba1f2511fc30423bdbb183fe33f3dd0f.0raw.tgz/MD5E-s4--ba1f2511fc30423bdbb183fe33f3dd0f.0raw.tgz
+"""]]
+
+[[!meta author=yoh]]

just added a tag to claim my ownership
diff --git a/doc/todo/parallel_get.mdwn b/doc/todo/parallel_get.mdwn
index 0734964..fb3f8d0 100644
--- a/doc/todo/parallel_get.mdwn
+++ b/doc/todo/parallel_get.mdwn
@@ -81,3 +81,5 @@ See also: [[parallel_possibilities]]
 >> Waiting on some updates to ascii-progress. --[[Joey]]
 
 >>> Wrote concurrent-output; [[done]] --[[Joey]]
+
+[[!meta author=yoh]]

diff --git a/doc/todo/Store_git_pack_files_on_special_remotes.mdwn b/doc/todo/Store_git_pack_files_on_special_remotes.mdwn
new file mode 100644
index 0000000..e4a86c7
--- /dev/null
+++ b/doc/todo/Store_git_pack_files_on_special_remotes.mdwn
@@ -0,0 +1 @@
+It would be nice to be able to upload and download git history with special remotes.  This could be a move towards full special remote syncing.

Added a comment
diff --git a/doc/todo/make_copy_--fast__faster/comment_2_0c67f467d730a0966b43171de0382c42._comment b/doc/todo/make_copy_--fast__faster/comment_2_0c67f467d730a0966b43171de0382c42._comment
new file mode 100644
index 0000000..6c37e77
--- /dev/null
+++ b/doc/todo/make_copy_--fast__faster/comment_2_0c67f467d730a0966b43171de0382c42._comment
@@ -0,0 +1,49 @@
+[[!comment format=mdwn
+ username="https://me.yahoo.com/a/EbvxpTI_xP9Aod7Mg4cwGhgjrCrdM5s-#7c0f4"
+ subject="comment 2"
+ date="2016-05-25T01:09:56Z"
+ content="""
+\"to remote host \"  so it was \"--to\". annex is already aware of having those files in that remote (see below).
+
+[[!format sh \"\"\"
+$> git annex copy --to=datalad-public --fast .        
+git annex copy --to=datalad-public --fast .  7.33s user 0.91s system 55% cpu 14.772 total
+
+$> git annex info
+repository mode: indirect
+trusted repositories: 0
+semitrusted repositories: 5
+	00000000-0000-0000-0000-000000000001 -- web
+ 	00000000-0000-0000-0000-000000000002 -- bittorrent
+ 	123c73e5-a8dc-4cff-8ffc-679c7ea67f94 -- yoh@smaug:/mnt/datasets/datalad/crawl/neurovault [here]
+ 	48c1556f-6241-45de-9497-338d437fcb62 -- yoh@falkor:/srv/datasets.datalad.org/www/neurovault/snapshots [datalad-public]
+ 	af2785da-2538-4346-a6f6-f2f30fc3f025 -- [datalad-archives]
+untrusted repositories: 0
+transfers in progress: none
+available local disk space: 31.42 terabytes (+1 megabyte reserved)
+local annex keys: 6615
+local annex size: 12.77 gigabytes
+annexed files in working tree: 6628
+size of annexed files in working tree: 6.31 gigabytes
+bloom filter size: 32 mebibytes (1.3% full)
+backend usage: 
+	SHA256E: 6628
+
+$> git annex whereis | head -30               
+whereis 1003/13873.nii.gz (3 copies) 
+  	123c73e5-a8dc-4cff-8ffc-679c7ea67f94 -- yoh@smaug:/mnt/datasets/datalad/crawl/neurovault [here]
+   	48c1556f-6241-45de-9497-338d437fcb62 -- yoh@falkor:/srv/datasets.datalad.org/www/neurovault/snapshots [datalad-public]
+   	af2785da-2538-4346-a6f6-f2f30fc3f025 -- [datalad-archives]
+
+  datalad-archives: dl+archive:SHA256E-s6460020224--710cc05117e2290e2f793271d11e26452cdc111121e09a937dbf5a34b3cc0107.tar/neurovault_snapshot/1003/13873.nii.gz#size=23262
+ok
+whereis 1003/13874.nii.gz (3 copies) 
+  	123c73e5-a8dc-4cff-8ffc-679c7ea67f94 -- yoh@smaug:/mnt/datasets/datalad/crawl/neurovault [here]
+   	48c1556f-6241-45de-9497-338d437fcb62 -- yoh@falkor:/srv/datasets.datalad.org/www/neurovault/snapshots [datalad-public]
+   	af2785da-2538-4346-a6f6-f2f30fc3f025 -- [datalad-archives]
+...
+> git annex copy --to=datalad-public .       
+copy 1003/13873.nii.gz (checking datalad-public...) yoh@datasets.datalad.org's password: 
+
+\"\"\"]]
+"""]]

closing
diff --git a/doc/bugs/standalone_builds_shouldn__39__t_pollute___126____47__.ssh_with_helpers_merely_upon_annex_init.mdwn b/doc/bugs/standalone_builds_shouldn__39__t_pollute___126____47__.ssh_with_helpers_merely_upon_annex_init.mdwn
index 5b4032c..58c7d71 100644
--- a/doc/bugs/standalone_builds_shouldn__39__t_pollute___126____47__.ssh_with_helpers_merely_upon_annex_init.mdwn
+++ b/doc/bugs/standalone_builds_shouldn__39__t_pollute___126____47__.ssh_with_helpers_merely_upon_annex_init.mdwn
@@ -14,3 +14,5 @@ Originally described in http://git-annex.branchable.com/devblog/day_155__missing
 5.20150916+gitg79661ef-1~ndall+1
 
 [[!meta author=yoh]]
+
+Since packaged version suggestively (I think I did check) resolved the issue, marking it as [[done]]

diff --git a/doc/todo/add_option_to_whereis_to_avoid_network_interactions.mdwn b/doc/todo/add_option_to_whereis_to_avoid_network_interactions.mdwn
index f9516b5..c322660 100644
--- a/doc/todo/add_option_to_whereis_to_avoid_network_interactions.mdwn
+++ b/doc/todo/add_option_to_whereis_to_avoid_network_interactions.mdwn
@@ -18,3 +18,4 @@ whereis bold.nii.gz
 """]]
 
 [[!meta author=yoh]]
+Was [[done]] by [[Joey]] as of 6.20160524+gitg2b7b2c4-1~ndall+1

minor typos in devblog
diff --git a/doc/devblog/day_394__implicit_vs_explicit.mdwn b/doc/devblog/day_394__implicit_vs_explicit.mdwn
index 681ef92..300ac4c 100644
--- a/doc/devblog/day_394__implicit_vs_explicit.mdwn
+++ b/doc/devblog/day_394__implicit_vs_explicit.mdwn
@@ -1,7 +1,7 @@
 git-annex has always balanced implicit and explicit behavior.
-Enabling a git reository to be used with git-annex needs an explicit init,
+Enabling a git repository to be used with git-annex needs an explicit init,
 to avoid foot-shooting; but a clone of a repository that is already
-using git-annex will be implicitally initialized. Git remotes implicitly
+using git-annex will be implicitly initialized. Git remotes implicitly
 are checked to see if they use git-annex, so the user can immediately
 follow `git remote add` with `git annex get` to get files from it.
 

devblog
diff --git a/doc/devblog/day_394__implicit_vs_explicit.mdwn b/doc/devblog/day_394__implicit_vs_explicit.mdwn
new file mode 100644
index 0000000..681ef92
--- /dev/null
+++ b/doc/devblog/day_394__implicit_vs_explicit.mdwn
@@ -0,0 +1,23 @@
+git-annex has always balanced implicit and explicit behavior.
+Enabling a git reository to be used with git-annex needs an explicit init,
+to avoid foot-shooting; but a clone of a repository that is already
+using git-annex will be implicitally initialized. Git remotes implicitly
+are checked to see if they use git-annex, so the user can immediately
+follow `git remote add` with `git annex get` to get files from it.
+
+There's a fine line here, and implicit git remote enabling sometimes
+crosses it; sometimes the remote doesn't have git-annex-shell, and so
+there's an ugly error message and annex-ignore has to be set to avoid
+trying to enable that git remote again. Sometimes the probe of a remote
+can occur when the user doesn't really expect it to (and it can involve a
+ssh password prompt).
+
+Part of the problem is, there's not an explicit way to enable a git remote
+to be used by git-annex. So, today, I made `git annex enableremote` do
+that, when the remote name passed to it is a git remote rather than a
+special remote. This way, you can avoid the implicit behavior if you want
+to.
+
+I also made `git annex enableremote` un-set annex-ignore, so if a remote
+got that set due to a transient configuration problem, it can be explicitly
+enabled.

close
diff --git a/doc/bugs/ghc_8.0.1_build_fixes.mdwn b/doc/bugs/ghc_8.0.1_build_fixes.mdwn
index 8770104..f9c8768 100644
--- a/doc/bugs/ghc_8.0.1_build_fixes.mdwn
+++ b/doc/bugs/ghc_8.0.1_build_fixes.mdwn
@@ -39,3 +39,5 @@ inreplace "git-annex.cabal",
 end
 """]]
 
+> [[fixed|done]], I hope. Have not tested the build myself but everything
+> applied. --[[Joey]]

close
diff --git a/doc/bugs/addurl_--batch_decides_to_talk_to_ssh_remotes_for_some_reason.mdwn b/doc/bugs/addurl_--batch_decides_to_talk_to_ssh_remotes_for_some_reason.mdwn
index 2008e68..cd2e2b5 100644
--- a/doc/bugs/addurl_--batch_decides_to_talk_to_ssh_remotes_for_some_reason.mdwn
+++ b/doc/bugs/addurl_--batch_decides_to_talk_to_ssh_remotes_for_some_reason.mdwn
@@ -17,3 +17,5 @@ yoh@datasets.datalad.org's password:
 That repository indeed has a remote (ssh) setup pointing to datasets.datalad.org (which carries no load for annex, besides git-annex repository, ATM), but that remote should not be consulted IMHO for addurl operation (not to mention in the --batch mode shouldn't request any user interaction)
 
 [[!meta author=yoh]]
+
+> [[done]] --[[Joey]]
diff --git a/doc/bugs/addurl_--batch_decides_to_talk_to_ssh_remotes_for_some_reason/comment_3_7f6507e71c6ed9147f01cdf6efdda48b._comment b/doc/bugs/addurl_--batch_decides_to_talk_to_ssh_remotes_for_some_reason/comment_3_7f6507e71c6ed9147f01cdf6efdda48b._comment
new file mode 100644
index 0000000..ee5ad14
--- /dev/null
+++ b/doc/bugs/addurl_--batch_decides_to_talk_to_ssh_remotes_for_some_reason/comment_3_7f6507e71c6ed9147f01cdf6efdda48b._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2016-05-24T19:59:36Z"
+ content="""
+Made `git annex enableremote` be able to be used to explicitly enable
+git-annex to use a git remote, probing its UUID.
+"""]]

enableremote: Remove annex-ignore configuration from a remote.
diff --git a/CHANGELOG b/CHANGELOG
index 8a40585..e58c6ee 100644
--- a/CHANGELOG
+++ b/CHANGELOG
@@ -22,6 +22,7 @@ git-annex (6.20160512) UNRELEASED; urgency=medium
   * enableremote: Can now be used to explicitly enable git-annex to use
     git remotes. Using the command this way prevents other git-annex
     commands from probing new git remotes to auto-enable them.
+  * enableremote: Remove annex-ignore configuration from a remote.
   * Support building with ghc 8.0.1.
   * Pass the various gnupg-options configs to gpg in several cases where
     they were not before. Most notably, gnupg-decrypt-options is now
diff --git a/Command/EnableRemote.hs b/Command/EnableRemote.hs
index bf0ad37..dc3e7bc 100644
--- a/Command/EnableRemote.hs
+++ b/Command/EnableRemote.hs
@@ -11,13 +11,14 @@ import Command
 import qualified Annex
 import qualified Logs.Remote
 import qualified Types.Remote as R
-import qualified Git.Types as Git
+import qualified Git
 import qualified Annex.SpecialRemote
 import qualified Remote
 import qualified Types.Remote as Remote
 import qualified Remote.Git
 import Logs.UUID
 import Annex.UUID
+import Config
 
 import qualified Data.Map as M
 
@@ -45,9 +46,10 @@ startNormalRemote :: RemoteName -> Git.Repo -> CommandStart
 startNormalRemote name r = do
 	showStart "enableremote" name
 	next $ next $ do
+		setRemoteIgnore r False
 		r' <- Remote.Git.configRead False r
 		u <- getRepoUUID r'
-		return (u /= NoUUID)
+		return $ u /= NoUUID
 
 startSpecialRemote :: RemoteName -> Remote.RemoteConfig -> Maybe (UUID, Remote.RemoteConfig) -> CommandStart
 startSpecialRemote name config Nothing = do
@@ -74,6 +76,10 @@ performSpecialRemote t u c gc = do
 cleanupSpecialRemote :: UUID -> R.RemoteConfig -> CommandCleanup
 cleanupSpecialRemote u c = do
 	Logs.Remote.configSet u c
+	mr <- Remote.byUUID u
+	case mr of
+		Nothing -> noop
+		Just r -> setRemoteIgnore (R.repo r) False
 	return True
 
 unknownNameError :: String -> Annex a
@@ -85,8 +91,12 @@ unknownNameError prefix = do
 			else Remote.prettyPrintUUIDsDescs
 				"known special remotes"
 				descm (M.keys m)
-	nouuids <- filterM (\r -> (==) NoUUID <$> getRepoUUID r)
-		=<< Annex.fromRepo Git.remotes
-	let nouuidmsg = unlines $ map ("\t" ++) $
-		mapMaybe Git.remoteName nouuids
-	error $ concat $ filter (not . null) [prefix ++ "\n", nouuidmsg, specialmsg]
+	disabledremotes <- filterM isdisabled =<< Annex.fromRepo Git.remotes
+	let remotesmsg = unlines $ map ("\t" ++) $
+		mapMaybe Git.remoteName disabledremotes
+	error $ concat $ filter (not . null) [prefix ++ "\n", remotesmsg, specialmsg]
+  where
+	isdisabled r = anyM id
+		[ (==) NoUUID <$> getRepoUUID r
+		, remoteAnnexIgnore <$> Annex.getRemoteGitConfig r
+		]
diff --git a/Config.hs b/Config.hs
index 0ff688d..75d7b4c 100644
--- a/Config.hs
+++ b/Config.hs
@@ -80,6 +80,12 @@ setRemoteCost r c = setConfig (remoteConfig r "cost") (show c)
 setRemoteAvailability :: Git.Repo -> Availability -> Annex ()
 setRemoteAvailability r c = setConfig (remoteConfig r "availability") (show c)
 
+setRemoteIgnore :: Git.Repo -> Bool -> Annex ()
+setRemoteIgnore r b = setConfig (remoteConfig r "ignore") (Git.Config.boolConfig b)
+
+setRemoteBare :: Git.Repo -> Bool -> Annex ()
+setRemoteBare r b = setConfig (remoteConfig r "bare") (Git.Config.boolConfig b)
+
 isDirect :: Annex Bool
 isDirect = annexDirect <$> Annex.getGitConfig
 
diff --git a/Remote/Git.hs b/Remote/Git.hs
index 0528f9f..403c91b 100644
--- a/Remote/Git.hs
+++ b/Remote/Git.hs
@@ -247,7 +247,7 @@ tryGitConfigRead autoinit r
 				-- Cache when http remote is not bare for
 				-- optimisation.
 				unless (Git.Config.isBare r') $
-					setremote "annex-bare" (Git.Config.boolConfig False)
+					setremote setRemoteBare False
 				return r'
 
 	store = observe $ \r' -> do
@@ -274,21 +274,18 @@ tryGitConfigRead autoinit r
 			return r
 	
 	set_ignore msg longmessage = do
-		let k = "annex-ignore"
 		case Git.remoteName r of
 			Nothing -> noop
 			Just n -> do
-				warning $ "Remote " ++ n ++ " " ++ msg ++ "; setting " ++ k
+				warning $ "Remote " ++ n ++ " " ++ msg ++ "; setting annex-ignore"
 				when longmessage $
-					warning $ "This could be a problem with the git-annex installation on the remote. Please make sure that git-annex-shell is available in PATH when you ssh into the remote. Once you have fixed the git-annex installation, run: git config remote." ++ n ++ "." ++ k ++ " false"
-		setremote k (Git.Config.boolConfig True)
+					warning $ "This could be a problem with the git-annex installation on the remote. Please make sure that git-annex-shell is available in PATH when you ssh into the remote. Once you have fixed the git-annex installation, run: git annex enableremote " ++ n
+		setremote setRemoteIgnore True
 	
-	setremote k v = case Git.remoteName r of
+	setremote setter v = case Git.remoteName r of
 		Nothing -> noop
-		Just n -> do
-			let k' = "remote." ++ n ++ "." ++ k
-			inRepo $ Git.Command.run [Param "config", Param k', Param v]
-		
+		Just n -> setter r v
+	
 	handlegcrypt Nothing = return r
 	handlegcrypt (Just _cacheduuid) = do
 		-- Generate UUID from the gcrypt-id
diff --git a/doc/git-annex-enableremote.mdwn b/doc/git-annex-enableremote.mdwn
index d63dfaf..d424f60 100644
--- a/doc/git-annex-enableremote.mdwn
+++ b/doc/git-annex-enableremote.mdwn
@@ -59,6 +59,9 @@ a new clone, it will will attempt to enable the special remote. Of course,
 this works best when the special remote does not need anything special
 to be done to get it enabled.
 
+(This command also can be used to enable a remote that git-annex has been
+prevented from using by the `remote.<name>.annex-ignore` setting.)
+
 # SEE ALSO
 
 [[git-annex]](1)

enableremote: Can now be used to explicitly enable git-annex to use git remotes. Using the command this way prevents other git-annex commands from probing new git remotes to auto-enable them.
diff --git a/CHANGELOG b/CHANGELOG
index 0a971b3..8a40585 100644
--- a/CHANGELOG
+++ b/CHANGELOG
@@ -19,6 +19,9 @@ git-annex (6.20160512) UNRELEASED; urgency=medium
     when in a subdirectory of the repository. This affected git annex view.
   * Fix crash when entering/changing view in a subdirectory of a repo that
     has a dotfile in its root.
+  * enableremote: Can now be used to explicitly enable git-annex to use
+    git remotes. Using the command this way prevents other git-annex
+    commands from probing new git remotes to auto-enable them.
   * Support building with ghc 8.0.1.
   * Pass the various gnupg-options configs to gpg in several cases where
     they were not before. Most notably, gnupg-decrypt-options is now
diff --git a/Command/EnableRemote.hs b/Command/EnableRemote.hs
index be20ea0..bf0ad37 100644
--- a/Command/EnableRemote.hs
+++ b/Command/EnableRemote.hs
@@ -1,6 +1,6 @@
 {- git-annex command
  -
- - Copyright 2013 Joey Hess <id@joeyh.name>
+ - Copyright 2013-2016 Joey Hess <id@joeyh.name>
  -
  - Licensed under the GNU GPL version 3 or higher.
  -}
@@ -8,18 +8,22 @@
 module Command.EnableRemote where
 
 import Command
+import qualified Annex
 import qualified Logs.Remote
 import qualified Types.Remote as R
+import qualified Git.Types as Git
 import qualified Annex.SpecialRemote
 import qualified Remote
 import qualified Types.Remote as Remote
+import qualified Remote.Git
 import Logs.UUID
+import Annex.UUID
 
 import qualified Data.Map as M
 
 cmd :: Command
 cmd = command "enableremote" SectionSetup
-	"enables use of an existing special remote"
+	"enables git-annex to use a remote"
 	(paramPair paramName $ paramOptional $ paramRepeating paramKeyValue)
 	(withParams seek)
 
@@ -27,43 +31,62 @@ seek :: CmdParams -> CommandSeek
 seek = withWords start
 
 start :: [String] -> CommandStart
-start [] = unknownNameError "Specify the special remote to enable."
-start (name:ws) = go =<< Annex.SpecialRemote.findExisting name
+start [] = unknownNameError "Specify the remote to enable."
+start (name:rest) = go =<< filter matchingname <$> Annex.fromRepo Git.remotes
   where
-	config = Logs.Remote.keyValToConfig ws
-	
-	go Nothing = do
-		m <- Annex.SpecialRemote.specialRemoteMap
-		confm <- Logs.Remote.readRemoteLog
-		v <- Remote.nameToUUID' name
-		case v of
-			Right u | u `M.member` m ->
-				go (Just (u, fromMaybe M.empty (M.lookup u confm)))
-			_ -> unknownNameError "Unknown special remote."
-	go (Just (u, c)) = do
-		let fullconfig = config `M.union` c	
-		t <- either error return (Annex.SpecialRemote.findType fullconfig)
-		showStart "enableremote" name
-		gc <- maybe def Remote.gitconfig <$> Remote.byUUID u
-		next $ perform t u fullconfig gc
+	matchingname r = Git.remoteName r == Just name
+	go [] = startSpecialRemote name (Logs.Remote.keyValToConfig rest)
+		=<< Annex.SpecialRemote.findExisting name
+	go (r:_) = startNormalRemote name r
+
+type RemoteName = String
+
+startNormalRemote :: RemoteName -> Git.Repo -> CommandStart
+startNormalRemote name r = do
+	showStart "enableremote" name
+	next $ next $ do
+		r' <- Remote.Git.configRead False r
+		u <- getRepoUUID r'
+		return (u /= NoUUID)
+
+startSpecialRemote :: RemoteName -> Remote.RemoteConfig -> Maybe (UUID, Remote.RemoteConfig) -> CommandStart
+startSpecialRemote name config Nothing = do
+	m <- Annex.SpecialRemote.specialRemoteMap
+	confm <- Logs.Remote.readRemoteLog
+	v <- Remote.nameToUUID' name
+	case v of
+		Right u | u `M.member` m ->
+			startSpecialRemote name config $
+				Just (u, fromMaybe M.empty (M.lookup u confm))
+		_ -> unknownNameError "Unknown remote name."
+startSpecialRemote name config (Just (u, c)) = do
+	let fullconfig = config `M.union` c	
+	t <- either error return (Annex.SpecialRemote.findType fullconfig)
+	showStart "enableremote" name
+	gc <- maybe def Remote.gitconfig <$> Remote.byUUID u
+	next $ performSpecialRemote t u fullconfig gc
+
+performSpecialRemote :: RemoteType -> UUID -> R.RemoteConfig -> RemoteGitConfig -> CommandPerform
+performSpecialRemote t u c gc = do
+	(c', u') <- R.setup t (Just u) Nothing c gc
+	next $ cleanupSpecialRemote u' c'
+
+cleanupSpecialRemote :: UUID -> R.RemoteConfig -> CommandCleanup
+cleanupSpecialRemote u c = do
+	Logs.Remote.configSet u c
+	return True
 
 unknownNameError :: String -> Annex a
 unknownNameError prefix = do
 	m <- Annex.SpecialRemote.specialRemoteMap
 	descm <- M.unionWith Remote.addName <$> uuidMap <*> pure m
-	msg <- if M.null m
+	specialmsg <- if M.null m
 			then pure "(No special remotes are currently known; perhaps use initremote instead?)"
 			else Remote.prettyPrintUUIDsDescs
 				"known special remotes"
 				descm (M.keys m)
-	error $ prefix ++ "\n" ++ msg
-
-perform :: RemoteType -> UUID -> R.RemoteConfig -> RemoteGitConfig -> CommandPerform
-perform t u c gc = do
-	(c', u') <- R.setup t (Just u) Nothing c gc
-	next $ cleanup u' c'
-
-cleanup :: UUID -> R.RemoteConfig -> CommandCleanup
-cleanup u c = do
-	Logs.Remote.configSet u c
-	return True
+	nouuids <- filterM (\r -> (==) NoUUID <$> getRepoUUID r)
+		=<< Annex.fromRepo Git.remotes
+	let nouuidmsg = unlines $ map ("\t" ++) $
+		mapMaybe Git.remoteName nouuids
+	error $ concat $ filter (not . null) [prefix ++ "\n", nouuidmsg, specialmsg]
diff --git a/doc/git-annex-enableremote.mdwn b/doc/git-annex-enableremote.mdwn
index 8467247..d63dfaf 100644
--- a/doc/git-annex-enableremote.mdwn
+++ b/doc/git-annex-enableremote.mdwn
@@ -1,6 +1,6 @@
 # NAME
 
-git-annex enableremote - enables use of an existing special remote
+git-annex enableremote - enables git-annex to use a remote
 
 # SYNOPSIS
 
@@ -8,15 +8,22 @@ git annex enableremote `name|uuid|desc [param=value ...]`
 
 # DESCRIPTION
 
-Enables use of an existing special remote in the current repository,
-which may be a different repository than the one in which it was
-originally created with the initremote command.
+Enables use of an existing remote in the current repository.
 
-The name of the remote is the same name used when originally
+This is often used to enable use of a special (non-git) remote, by
+a different repository than the one in which it was
+originally created with the initremote command. 
+
+It can also be used to explicitly enable a git remote,
+so that git-annex can store the contents of files there. First
+run `git remote add`, and then `git annex enableremote` with the name of
+the remote.
+
+When enabling a special remote, specify the same name used when originally
 creating that remote with `git annex initremote`. Run 
 `git annex enableremote` without any name to get a list of
 special remote names. Or you can specify the uuid or description of the
-remote.
+special remote.
   
 Some special remotes may need parameters to be specified every time they are
 enabled. For example, the directory special remote requires a directory=

replace redudundant and incomplete encryption para with link
diff --git a/doc/git-annex-initremote.mdwn b/doc/git-annex-initremote.mdwn
index 4265d89..1b46ff5 100644
--- a/doc/git-annex-initremote.mdwn
+++ b/doc/git-annex-initremote.mdwn
@@ -21,20 +21,11 @@ The remote's configuration is specified by the parameters passed
 to this command. Different types of special remotes need different
 configuration values. The command will prompt for parameters as needed.
 
-All special remotes support encryption. You can either specify
+All special remotes support encryption. You can specify
 `encryption=none` to disable encryption, or specify
 `encryption=hybrid keyid=$keyid ...` to specify a GPG key id (or an email
-address associated with a key).
-
-There are actually three schemes that can be used for management of the
-encryption keys. When using the encryption=hybrid scheme, additional
-GPG keys can be given access to the encrypted special remote easily
-(without re-encrypting everything). When using encryption=shared,
-a shared key is generated and stored in the git repository, allowing
-anyone who can clone the git repository to access it. Finally, when using
-encryption=pubkey, content in the special remote is directly encrypted
-to the specified GPG keys, and additional ones cannot easily be given
-access.
+address associated with a key). For details about ways to configure
+encryption, see <https://git-annex.branchable.com/encryption/>
 
 If you anticipate using the new special remote in other clones of the
 repository, you can pass "autoenable=true". Then when [[git-annex-init]](1)

diff --git a/doc/bugs/gcrypt_special_remote_not_being_encrypted.mdwn b/doc/bugs/gcrypt_special_remote_not_being_encrypted.mdwn
index 3d4a217..b264fca 100644
--- a/doc/bugs/gcrypt_special_remote_not_being_encrypted.mdwn
+++ b/doc/bugs/gcrypt_special_remote_not_being_encrypted.mdwn
@@ -40,7 +40,7 @@ grep -r "Banana" . #On the other hand, this has a result
 ```
 If the first machine do `git annex sync --content`, it can get and view the new file normally, trying to add new file afterward from the first machine works fine as well. Adding file from the 2nd machine results in the same behaviour (unencrypted file content). 
 
-When using gcrypt special remote on local machine , it does not seem to be an issue.
+When using gcrypt special remote on local machine , it does not seem to be an issue. Additionally, on machine 2 if I clone from the first machine then enableremote to the gcrypt server, it is also not a problem. Seems like the issue only happens when cloning the bare repo. On inspection of the annex/objects folder, the issue seems to be that beside the "GPGHMACSHA1*" files (which I assume is encrypted data), a bunch of "SHA256E*" files are also added which contains the raw unencrypted data.
 
 ### What version of git-annex are you using? On what operating system?
 

diff --git a/doc/bugs/gcrypt_special_remote_not_being_encrypted.mdwn b/doc/bugs/gcrypt_special_remote_not_being_encrypted.mdwn
index 6b4c8da..3d4a217 100644
--- a/doc/bugs/gcrypt_special_remote_not_being_encrypted.mdwn
+++ b/doc/bugs/gcrypt_special_remote_not_being_encrypted.mdwn
@@ -38,7 +38,7 @@ grep -r "Banana" . #On the other hand, this has a result
 > ./annex/objects/ee1/042/SHA256E-s5--11861eaa2e70e8ac73d9d20cd172b6a5396cb0116fed5bfe432ca075144b2d48.org/SHA256E-s5--11861eaa2e70e8ac73d9d20cd172b6a5396cb0116fed5bfe432ca075144b2d48.org:BananaTest
 
 ```
-If the first machine do `git annex sync --content`, it can get and view the new file normally, trying to add new file afterward from the first machine works fine as well. Adding file from the 2nd machine results in the same behaviour (unencrypted file name). 
+If the first machine do `git annex sync --content`, it can get and view the new file normally, trying to add new file afterward from the first machine works fine as well. Adding file from the 2nd machine results in the same behaviour (unencrypted file content). 
 
 When using gcrypt special remote on local machine , it does not seem to be an issue.
 

Added a comment
diff --git a/doc/bugs/ghc_8.0.1_build_fixes/comment_3_010ee40d55d345f4a4d7d5bc310adfc2._comment b/doc/bugs/ghc_8.0.1_build_fixes/comment_3_010ee40d55d345f4a4d7d5bc310adfc2._comment
new file mode 100644
index 0000000..18d1727
--- /dev/null
+++ b/doc/bugs/ghc_8.0.1_build_fixes/comment_3_010ee40d55d345f4a4d7d5bc310adfc2._comment
@@ -0,0 +1,60 @@
+[[!comment format=mdwn
+ username="ilovezfs"
+ subject="comment 3"
+ date="2016-05-24T09:32:31Z"
+ content="""
+> I've relaxed the bounds on base. AFAICS there are no bounds on time and transformers, so what were you suggesting I change there?
+
+The following assumes passing --flags=\"webapp s3\" and --max-backjumps=-1.
+
+Adding allow-newer for just base hangs.
+
+Adding allow-newer for just base and transformers leads to solver failure due to
+\"rejecting: aws-0.13.0 (conflict: unix => time==1.6.0.1/installed-1.6..., aws => time>=1.1.4 && <1.6)\"
+This has already been fixed by aws https://github.com/aristidb/aws/commit/512d4f7aa908b4fd2a2b72be79733d865d36652e but that commit is not in the released version of aws yet, so one option would be to patch aws directly with that commit. The other option is to set allow-newer for time.
+
+Adding allow-newer for just base and time leads to a failed build due to a transformers-0.4.3.0 issue, which doesn't affect newer versions of transformers. However, the current aws restricts transformers to <0.5, and the last version before 0.5 is 0.4.3.0. The error message is
+
+[[!format  text \"\"\"
+[11 of 27] Compiling Control.Monad.Trans.Error ( Control/Monad/Trans/Error.hs, dist/dist-sandbox-81571458/build/Control/Monad/Trans/Error.o )
+
+Control/Monad/Trans/Error.hs:69:10: error:
+    Duplicate instance declarations:
+      instance MonadPlus IO
+        -- Defined at Control/Monad/Trans/Error.hs:69:10
+      instance MonadPlus IO -- Defined in ‘GHC.Base’
+
+Control/Monad/Trans/Error.hs:73:10: error:
+    Duplicate instance declarations:
+      instance Alternative IO
+        -- Defined at Control/Monad/Trans/Error.hs:73:10
+      instance Alternative IO -- Defined in ‘GHC.Base’
+\"\"\"]]
+
+
+>Would -XNoMonomorphismRestriction fix it?
+
+Setting that option leads to
+[[!format  text \"\"\"
+[ 89 of 538] Compiling Utility.Url      ( Utility/Url.hs, dist/dist-sandbox-516bc87d/build/git-annex/git-annex-tmp/Utility/Url.o )
+
+Utility/Url.hs:160:85: error:
+    • Ambiguous type variable ‘a0’ arising from a use of ‘len’
+      prevents the constraint ‘(Read a0)’ from being solved.
+      Probable fix: use a type annotation to specify what ‘a0’ should be.
+      These potential instances exist:
+        instance Read a => Read (ZipList a)
+          -- Defined in ‘Control.Applicative’
+        instance (Read a, Read b) => Read (Either a b)
+          -- Defined in ‘Data.Either’
+        instance forall k a (b :: k). Read a => Read (Const a b)
+          -- Defined in ‘Data.Functor.Const’
+        ...plus 47 others
+        ...plus 177 instances involving out-of-scope types
+        (use -fprint-potential-instances to see them all)
+    • In the first argument of ‘isJust’, namely ‘len’
+      In the second argument of ‘(&&)’, namely ‘isJust len’
+      In the expression: \"ftp\" `isInfixOf` uriScheme u && isJust len
+\"\"\"]]
+
+"""]]

diff --git a/doc/bugs/gcrypt_special_remote_not_being_encrypted.mdwn b/doc/bugs/gcrypt_special_remote_not_being_encrypted.mdwn
index 0650bc6..6b4c8da 100644
--- a/doc/bugs/gcrypt_special_remote_not_being_encrypted.mdwn
+++ b/doc/bugs/gcrypt_special_remote_not_being_encrypted.mdwn
@@ -38,7 +38,9 @@ grep -r "Banana" . #On the other hand, this has a result
 > ./annex/objects/ee1/042/SHA256E-s5--11861eaa2e70e8ac73d9d20cd172b6a5396cb0116fed5bfe432ca075144b2d48.org/SHA256E-s5--11861eaa2e70e8ac73d9d20cd172b6a5396cb0116fed5bfe432ca075144b2d48.org:BananaTest
 
 ```
-If the first machine do `git annex sync --content`, it can get and view the new file normally, trying to add new file afterward from the first machine works fine as well. Adding file from the 2nd machine results in the same behaviour (unencrypted file name)
+If the first machine do `git annex sync --content`, it can get and view the new file normally, trying to add new file afterward from the first machine works fine as well. Adding file from the 2nd machine results in the same behaviour (unencrypted file name). 
+
+When using gcrypt special remote on local machine , it does not seem to be an issue.
 
 ### What version of git-annex are you using? On what operating system?
 

diff --git a/doc/bugs/gcrypt_special_remote_not_being_encrypted.mdwn b/doc/bugs/gcrypt_special_remote_not_being_encrypted.mdwn
new file mode 100644
index 0000000..0650bc6
--- /dev/null
+++ b/doc/bugs/gcrypt_special_remote_not_being_encrypted.mdwn
@@ -0,0 +1,71 @@
+### Please describe the problem.
+I'm trying to setup a ssh special remote with gcrypt as an always-on sync point for 2 other machines. However, when syncing, only the first machine that was setup seems to do the encryption properly, the other machine that clones from the gcrypt remote sync the file content without encryption. I followed the instruction on https://git-annex.branchable.com/tips/fully_encrypted_git_repositories_with_gcrypt/
+
+### What steps will reproduce the problem?
+
+On the first machine:
+
+```
+cd MyStuffs
+git init
+git annex init "Macbook"
+cat "First file" > first.txt
+git annex add .
+git commit -a -m added
+git annex initremote personal-server type=gcrypt gitrepo=ssh://user@foo.bar.com/home/user/MyStuffs keyid=XXXXXXXXX
+git annex sync 
+git annex sync--content
+```
+
+On second machine
+
+```
+git clone gcrypt::ssh://user@foo.bar.com/home/user/MyStuffs test
+git annex enableremote personal-server gitrepo=ssh://user@foo.bar.com/home/user/MyStuffs 
+cd test 
+cat "BananaTest" > test
+git annex add .
+git commit -a -m added
+git annex sync --content
+```
+
+On the remote server
+
+```
+cd ~/MyStuffs
+grep -r "First" . #There is no result, which is good
+grep -r "Banana" . #On the other hand, this has a result
+> ./annex/objects/ee1/042/SHA256E-s5--11861eaa2e70e8ac73d9d20cd172b6a5396cb0116fed5bfe432ca075144b2d48.org/SHA256E-s5--11861eaa2e70e8ac73d9d20cd172b6a5396cb0116fed5bfe432ca075144b2d48.org:BananaTest
+
+```
+If the first machine do `git annex sync --content`, it can get and view the new file normally, trying to add new file afterward from the first machine works fine as well. Adding file from the 2nd machine results in the same behaviour (unencrypted file name)
+
+### What version of git-annex are you using? On what operating system?
+
+The first and second machine was in fact the same machine ,running OS X El Capitan
+
+```
+git-annex version: 6.20160511
+build flags: Assistant Webapp Pairing Testsuite S3(multipartupload)(storageclasses) WebDAV FsEvents XMPP ConcurrentOutput TorrentParser MagicMime Feeds Quvi
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 SHA1E SHA1 MD5E 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 versions: 5 6
+upgrade supported from repository versions: 0 1 2 4 5
+operating system: darwin x86_64
+```
+
+The remote server that use ssh is Debian Jessie, without git-annex installed (I tried it with git-annex installed on the server, it has the same behaviour)
+### Please provide any additional information below.
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+
+
+# End of transcript or log.
+"""]]
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+Yes, everything works very nicely except this issue.

diff --git a/doc/forum/problem_with_non-ascii_filenames.mdwn b/doc/forum/problem_with_non-ascii_filenames.mdwn
new file mode 100644
index 0000000..64885c1
--- /dev/null
+++ b/doc/forum/problem_with_non-ascii_filenames.mdwn
@@ -0,0 +1,5 @@
+git-annex add . fails with:
+
+ git-annex: unknown response from git cat-file ("HEAD:./MYDIRECTORYNAME/Icon missing","HEAD:./MYDIRECTORYNAME/Icon\r")
+
+There's a file in the directory called Icon^M or Icon? (there's some kind of control character or unicode or other weirdness at the end)

Updated cabal file explictly lists source files.
The tarball on hackage will include only the files needed for cabal install;
it is NOT the full git-annex source tree. While it's totally obnoxious that
cabal files need every file listed out when basic wildcard support could
avoid hundreds of lines, and have to be maintained when files are added,
this does get the tarball size back down to 1 mb.
This also stops stack from complaining that it found modules not listed in
the cabal file.
debian/changelog, debian/NEWS, debian/copyright: Converted to symlinks
to CHANGELOG, NEWS, and COPYRIGHT, which used to symlink to these instead.
This avoids needing to include debian/ in the hackage tarball.
Setup.hs: Build man pages at install time using make and mdwn2man.
If it fails, which it probably will on windows, just skip installing
them.
diff --git a/Build/Version.hs b/Build/Version.hs
index 87315b0..d39a0fe 100644
--- a/Build/Version.hs
+++ b/Build/Version.hs
@@ -46,7 +46,7 @@ getVersion = do
 	
 getChangelogVersion :: IO Version
 getChangelogVersion = do
-	changelog <- readFile "debian/changelog"
+	changelog <- readFile "CHANGELOG"
 	let verline = takeWhile (/= '\n') changelog
 	return $ middle (words verline !! 1)
   where
diff --git a/Build/make-sdist.sh b/Build/make-sdist.sh
deleted file mode 100755
index 6e1ddae..0000000
--- a/Build/make-sdist.sh
+++ /dev/null
@@ -1,22 +0,0 @@
-#!/bin/sh
-#
-# Workaround for `cabal sdist` requiring all included files to be listed
-# in .cabal.
-
-# Create target directory
-sdist_dir=git-annex-$(grep '^Version:' git-annex.cabal | sed -re 's/Version: *//')
-mkdir --parents dist/$sdist_dir
-
-find . \( -name .git -or -name dist -or -name cabal-dev \) -prune \
-	-or -not -name \\*.orig -not -type d -print \
-	| perl -ne "print unless length >= 100 - length q{$sdist_dir}" \
-	| grep -v ':' \
-	| xargs cp --parents --target-directory dist/$sdist_dir
-
-cd dist
-tar --format=ustar -caf $sdist_dir.tar.gz $sdist_dir
-
-# Check that tarball can be unpacked by cabal.
-# It's picky about tar longlinks etc.
-rm -rf $sdist_dir
-cabal unpack $sdist_dir.tar.gz
diff --git a/CHANGELOG b/CHANGELOG
deleted file mode 120000
index d526672..0000000
--- a/CHANGELOG
+++ /dev/null
@@ -1 +0,0 @@
-debian/changelog
\ No newline at end of file
diff --git a/CHANGELOG b/CHANGELOG
new file mode 100644
index 0000000..0a971b3
--- /dev/null
+++ b/CHANGELOG
@@ -0,0 +1,4620 @@
+git-annex (6.20160512) UNRELEASED; urgency=medium
+
+  * Change git annex info remote encryption description to use wording
+    closer to what's used in initremote.
+  * webapp: Avoid confusing display of dead remotes.
+  * adjust: If the adjusted branch already exists, avoid overwriting it,
+    since it might contain changes that have not yet been propigated to the
+    original branch.
+  * assistant: Fix bug that caused v6 pointer files to be annexed by the
+    assistant.
+  * assistant: Fix race in v6 mode that caused downloaded file content to
+    sometimes not replace pointer files.
+  * add: Adding a v6 pointer file used to annex it; now the pointer file is
+    added to git as-is. (git add of a pointer file already did the right
+    thing)
+  * adjust: Add --fix adjustment, which is useful when the git directory
+    is in a nonstandard place.
+  * Work around git weirdness in handling of relative path to GIT_INDEX_FILE
+    when in a subdirectory of the repository. This affected git annex view.
+  * Fix crash when entering/changing view in a subdirectory of a repo that
+    has a dotfile in its root.
+  * Support building with ghc 8.0.1.
+  * Pass the various gnupg-options configs to gpg in several cases where
+    they were not before. Most notably, gnupg-decrypt-options is now
+    passed when decrypting an encrypted cipher.
+  * Updated cabal file explictly lists source files. The tarball
+    on hackage will include only the files needed for cabal install;
+    it is NOT the full git-annex source tree.
+  * debian/changelog, debian/NEWS, debian/copyright: Converted to symlinks
+    to CHANGELOG, NEWS, and COPYRIGHT, which used to symlink to these instead.
+
+ -- Joey Hess <id@joeyh.name>  Wed, 11 May 2016 16:08:38 -0400
+
+git-annex (6.20160511) unstable; urgency=medium
+
+  * Fix bug that sometimes prevented git-annex smudge --clean from consuming
+    all its input, which resulted in git add bypassing git-annex.
+  * Fix build with directory-1.2.6.2.
+  * Improve behavior when a just added http remote is not available
+    during uuid probe. Do not mark it as annex-ignore, so it will be tried
+    again later.
+  * Android: Icon refresh.
+    Thanks, freewheelinfranks.
+  * Added DIRHASH-LOWER to external special remote protocol.
+  * git-annex.cabal: Add Setup-Depends.
+  * stack.yaml: Enable explicit-setup-deps.
+  * Windows: Fix several bugs in propigation of changes from the adjusted
+    branch back to the master branch.
+  * Windows: Fix an over-long temp directory name.
+  * map: Hide dead repositories that are not connected to the graph.
+  * map: Changed colors; red is used for untrusted repositories and grey
+    for dead.
+  * version: Display OS version and architecture too.
+  * Propigate GIT_DIR and GIT_WORK_TREE environment to external special
+    remotes.
+  * Added annex.gnupg-decrypt-options and
+    remote.<name>.annex-gnupg-decrypt-options, which are passed to gpg
+    when it's decrypting data.
+  * fsck: When a key is not previously known in the location log,
+    record something so that reinject --known will work.
+  * In the unusual configuration where annex.crippledfilesystem=true but
+    core.symlinks=true, store object contents in mixed case hash
+    directories so that symlinks will point to them.
+  * Added new encryption=sharedpubkey mode for special remotes.
+    This is useful for makking a special remote that anyone with a clone
+    of the repo and your public keys can upload files to, but only you can
+    decrypt the files stored in it.
+
+ -- Joey Hess <id@joeyh.name>  Wed, 11 May 2016 12:41:42 -0400
+
+git-annex (6.20160419) unstable; urgency=medium
+
+  * Fix bug that prevented resuming of uploads to encrypted special remotes
+    that used chunking.
+  * That bug could also expose the names of keys to such remotes, so it is a
+    minor security issue.
+  * Fix duplicate progress meter display when downloading from a git remote
+    over http with -J.
+  * reinject: When src file's content cannot be verified, leave it alone,
+    instead of deleting it.
+  * reinject: Added new mode which can reinject known files into the annex.
+    For example: git-annex reinject --known /mnt/backup/*
+  * calckey: New plumbing command, calculates the key that would be used
+    to refer to a file.
+  * Fix bug that prevented annex.sshcaching=false configuration from taking
+    effect when on a crippled filesystem. Thanks, divergentdave.
+  * git 2.9.0 is going to prevent git merge from merging in unrelated
+    branches. Since the webapp's pairing etc features often combine
+    together repositories with unrelated histories, work around
+    this behavior change when the assistant merges, by passing
+    --allow-unrelated-histories. Note though that this is not done
+    for git annex sync's merges, so it will follow git's default or
+    configured behavior.
+  * When git-annex is used with a git version older than 2.2.0, disable
+    support for adjusted branches, since GIT_COMMON_DIR is needed to update
+    them and was first added in that version of git.
+  * Avoid setting LOCPATH in linux standalone builds that are built with
+    a ghc that has been fixed to not hang when it cannot find locale files.
+  * Isolate test suite from global git config settings.
+
+ -- Joey Hess <id@joeyh.name>  Thu, 28 Apr 2016 09:31:14 -0400
+
+git-annex (6.20160418) unstable; urgency=medium
+
+  * smudge: Print a warning when annex.thin is set, as git's smudge
+    interface does not allow honoring that configuration.
+  * webapp: When $HOME is a git repository, and has been initialized for
+    use by git-annex, opening the webapp went ahead and ran the assistant
+    there, annexing all files. Since this is almost certianly not
+    desirable, especially when the user is just opening the webapp from
+    a dekstop menu which happens to run it in $HOME, the webapp will now not
+    treat such a $HOME git repository as a git-annex repository.
+  * webapp: Update url to add gitlab.com ssh key.
+  * Fix bug in v6 mode that prevented treating unlocked executable files
+    as annexed. If you have such files, run git annex init --version=6
+    to update the cache after upgrading to this version of git-annex.
+  * Preserve execute bits of unlocked files in v6 mode.
+  * fsck: Warn when core.sharedRepository is set and an annex object file's
+    write bit is not set and cannot be set due to the file being owned
+    by a different user.
+  * Fix hang when dropping content needs to lock the content on a
+    ssh remote, which occurred when the remote has git-annex version
+    5.20151019 or newer. (The bug was in the client side; the remote
+    git-annex-shell does not need to be upgraded.)
+
+ -- Joey Hess <id@joeyh.name>  Mon, 18 Apr 2016 18:33:52 -0400
+
+git-annex (6.20160412) unstable; urgency=medium
+
+  * adjust --unlock: Enters an adjusted branch in which all annexed files
+    are unlocked. The v6 equivilant of direct mode, but much cleaner!
+  * Upgrading a direct mode repository to v6 has changed to enter
+    an adjusted unlocked branch. This makes the direct mode to v6 upgrade
+    able to be performed in one clone of a repository without affecting
+    other clones, which can continue using v5 and direct mode.
+  * init --version=6: Automatically enter the adjusted unlocked branch
+    when filesystem doesn't support symlinks.
+  * ddar remote: fix ssh calls
+    Thanks, Robie Basak
+  * log: Display time with time zone.
+  * log --raw-date: Use to display seconds from unix epoch.
+  * v6: Close pointer file handles more quickly, to avoid problems on Windows.
+  * sync: Show output of git commit.
+  * annex.thin and annex.hardlink are now supported on Windows.
+  * unannex --fast now makes hard links on Windows.

(Diff truncated)
Added a comment: what would be the "best" command to run?
diff --git a/doc/bugs/addurl_--batch_decides_to_talk_to_ssh_remotes_for_some_reason/comment_2_fbd8bb1607e308b47dca5b27fd73d67e._comment b/doc/bugs/addurl_--batch_decides_to_talk_to_ssh_remotes_for_some_reason/comment_2_fbd8bb1607e308b47dca5b27fd73d67e._comment
new file mode 100644
index 0000000..cfa46a3
--- /dev/null
+++ b/doc/bugs/addurl_--batch_decides_to_talk_to_ssh_remotes_for_some_reason/comment_2_fbd8bb1607e308b47dca5b27fd73d67e._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="https://me.yahoo.com/a/EbvxpTI_xP9Aod7Mg4cwGhgjrCrdM5s-#7c0f4"
+ subject="what would be the &quot;best&quot; command to run?"
+ date="2016-05-24T00:10:23Z"
+ content="""
+Something was nagging back in my mind that issue was indeed similar to previously observed but I, as you, couldn't quickly locate it.  Now that you reminded that it was about whois -- [found it](http://git-annex.branchable.com/todo/add_option_to_whereis_to_avoid_network_interactions/) .
+What would be the best annex command to run to accomplish just that -- to \"register\" that given remote with annex (without bothering with sync/merge/...)?
+I guess I could run 'annex info' but that might want to deal with every remote.
+"""]]

added that reconfirmed with 6.20160523+gitg33c00ab-1~ndall+1
diff --git a/doc/bugs/addurl_--batch_decides_to_talk_to_ssh_remotes_for_some_reason.mdwn b/doc/bugs/addurl_--batch_decides_to_talk_to_ssh_remotes_for_some_reason.mdwn
index f99feae..2008e68 100644
--- a/doc/bugs/addurl_--batch_decides_to_talk_to_ssh_remotes_for_some_reason.mdwn
+++ b/doc/bugs/addurl_--batch_decides_to_talk_to_ssh_remotes_for_some_reason.mdwn
@@ -1,7 +1,7 @@
 ### What version of git-annex are you using? On what operating system?
 
 6.20160425+gitgffe2ea2-1~ndall+1
-I am building now a brand new snapshot to see if replicates
+(reconfirmed with 6.20160523+gitg33c00ab-1~ndall+1)
 
 ### Please provide any additional information below.
 Here is a debug output from datalad which shows the interaction

devblog
diff --git a/doc/devblog/day_393__fun_and_more_fun.mdwn b/doc/devblog/day_393__fun_and_more_fun.mdwn
new file mode 100644
index 0000000..9d1fc0c
--- /dev/null
+++ b/doc/devblog/day_393__fun_and_more_fun.mdwn
@@ -0,0 +1,15 @@
+Over the weekend, I noticed that a relative path to `GIT_INDEX_FILE` is
+interpreted in several different, inconsistent ways by git. git-annex
+mostly used absolute paths, but did use a relative path in `git annex
+view`. Now it will only use absolute paths to avoid git's wacky behavior.
+
+Integrated some patches to support building with ghc 8.0.1, which was
+recently released.
+
+The gnupg-options git configs were not always passed to gpg. Fixing this
+involved quite a lot of plumbing to get the options to the right functions,
+and consumed half of today.
+
+Also did some design work on [[design/external_special_remote_protocol]]
+to avoid backwards compatability problems when adding new protocol
+features.

deja vu all over again
diff --git a/doc/bugs/addurl_--batch_decides_to_talk_to_ssh_remotes_for_some_reason/comment_1_7206ade4d4d124aa428a4051d4592302._comment b/doc/bugs/addurl_--batch_decides_to_talk_to_ssh_remotes_for_some_reason/comment_1_7206ade4d4d124aa428a4051d4592302._comment
new file mode 100644
index 0000000..2fefd37
--- /dev/null
+++ b/doc/bugs/addurl_--batch_decides_to_talk_to_ssh_remotes_for_some_reason/comment_1_7206ade4d4d124aa428a4051d4592302._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-05-23T22:15:40Z"
+ content="""
+I seem to remember you filing a bug about the same thing with whereis,
+although I can't find it just now. Let's not file duplicate bugs when
+different git-annex commands exhibit the same bevavior, please?
+
+As I said before, when you set up a new git remote, you need to run some
+git-annex command so that it can query the UUID of the remote. Or, set
+remote.name.annex-ignore to make git-annex not use the remote.
+
+Why does addurl need to set up the remote objects including getting their
+UUIDs? Because remotes can claim urls.
+
+(--batch mode can't prevent stuff from prompting for passwords.)
+"""]]

add todo item
diff --git a/doc/design/external_special_remote_protocol.mdwn b/doc/design/external_special_remote_protocol.mdwn
index d775fb8..40f764c 100644
--- a/doc/design/external_special_remote_protocol.mdwn
+++ b/doc/design/external_special_remote_protocol.mdwn
@@ -396,3 +396,24 @@ It works like this:
 * uuid discovery during INITREMOTE.
 * Hook into webapp. Needs a way to provide some kind of prompt to the user
   in the webapp, etc.
+
+* When a new "special remote message" is added to this protocol, and a
+  program wants to use it,  an old version of git-annex will reject the
+  message as unknown, and fail to use the remote with a protocol error.
+
+  The program can check `git-annex version`, but that's not very
+  satisfactory. Version comparison can be hard and
+  PATH might not point to the same git-annex that's running the program.
+
+  One way to fix this would be to make git-annex reply to VERSION
+  with a PROTOCOLKEYWORDS message listing all the keywords in the
+  protocol that it knows.
+  The program could then check if the new message it wants to send is on
+  the list. PROTOCOLKEYWORDS would be ignored by any program that doesn't
+  care/know about it; programs are required to send UNSUPPORTED-REQUEST.
+
+  I worry that some special remote programs might expect to get only 
+  PREPARE or INITREMOTE after VERSION, so this change would break them.
+  I mean, they shouldn't.. But a quickly/badly written one might.
+  Probably want to review all the linked external special remote programs
+  before doing this.

re-close
diff --git a/doc/bugs/annex.gnupg-options_not_used_by_assistant.mdwn b/doc/bugs/annex.gnupg-options_not_used_by_assistant.mdwn
index 09ff1ab..67ebb88 100644
--- a/doc/bugs/annex.gnupg-options_not_used_by_assistant.mdwn
+++ b/doc/bugs/annex.gnupg-options_not_used_by_assistant.mdwn
@@ -81,3 +81,5 @@ gpg: cannot open `/dev/tty': Device not configured
 > added annex.gnupg-decrypt-options; done --[[Joey]]
 
 >> Reopening, see comment. --[[Joey]]
+
+>>> Fixed again, [[done]] --[[Joey]]
diff --git a/doc/bugs/annex.gnupg-options_not_used_by_assistant/comment_4_60246ce3751486ed0f3b761fa8ac5ce8._comment b/doc/bugs/annex.gnupg-options_not_used_by_assistant/comment_4_60246ce3751486ed0f3b761fa8ac5ce8._comment
new file mode 100644
index 0000000..e5ae750
--- /dev/null
+++ b/doc/bugs/annex.gnupg-options_not_used_by_assistant/comment_4_60246ce3751486ed0f3b761fa8ac5ce8._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2016-05-23T21:06:53Z"
+ content="""
+Yeah, that was 2 thousand lines of fun patch..
+
+I'm nearly 100% sure that every place git-annex calls gpg will pass the
+configured options now.
+"""]]

fixed meta tag
diff --git a/doc/bugs/addurl_--batch_decides_to_talk_to_ssh_remotes_for_some_reason.mdwn b/doc/bugs/addurl_--batch_decides_to_talk_to_ssh_remotes_for_some_reason.mdwn
index ebc3bf0..f99feae 100644
--- a/doc/bugs/addurl_--batch_decides_to_talk_to_ssh_remotes_for_some_reason.mdwn
+++ b/doc/bugs/addurl_--batch_decides_to_talk_to_ssh_remotes_for_some_reason.mdwn
@@ -1,4 +1,3 @@
-
 ### What version of git-annex are you using? On what operating system?
 
 6.20160425+gitgffe2ea2-1~ndall+1
@@ -17,4 +16,4 @@ yoh@datasets.datalad.org's password:
 
 That repository indeed has a remote (ssh) setup pointing to datasets.datalad.org (which carries no load for annex, besides git-annex repository, ATM), but that remote should not be consulted IMHO for addurl operation (not to mention in the --batch mode shouldn't request any user interaction)
 
-[[!author meta=yoh]]
+[[!meta author=yoh]]

diff --git a/doc/bugs/addurl_--batch_decides_to_talk_to_ssh_remotes_for_some_reason.mdwn b/doc/bugs/addurl_--batch_decides_to_talk_to_ssh_remotes_for_some_reason.mdwn
new file mode 100644
index 0000000..ebc3bf0
--- /dev/null
+++ b/doc/bugs/addurl_--batch_decides_to_talk_to_ssh_remotes_for_some_reason.mdwn
@@ -0,0 +1,20 @@
+
+### What version of git-annex are you using? On what operating system?
+
+6.20160425+gitgffe2ea2-1~ndall+1
+I am building now a brand new snapshot to see if replicates
+
+### Please provide any additional information below.
+Here is a debug output from datalad which shows the interaction
+
+[[!format sh """
+2016-05-23 16:41:59,955 [DEBUG  ] Initiating a new process for BatchedAnnex(annex_cmd='addurl', annex_options=<<['-c', 'annex.largefil...>>, git_options=[], output_proc=<function>, path=<<'/mnt/btrfs/datasets/d...>>) (annexrepo.py:1177)
+2016-05-23 16:41:59,956 [Level 5] Command: ['git', '-c', 'receive.autogc=0', '-c', 'gc.auto=0', 'annex', 'addurl', '-c', 'annex.largefiles=exclude=Makefile and exclude=LICENSE* and exclude=ISSUES* and exclude=CHANGES* and exclude=README* and exclude=*.[mc] and exclude=dataset*.json and (exclude=*.txt or include=*/*.txt) and (exclude=*.json or include=*/*.json) and (exclude=*.tsv or include=*/*.tsv)', '--with-files', '--json', '--batch'] (annexrepo.py:1180)
+2016-05-23 16:41:59,967 [Level 5] Sending u'http://openfmri.s3.amazonaws.com/tarballs/ds052_R2.0.0_metadata_derivatives.tgz?versionId=nrIMjS3lH6TMoSkA.27U.Md_k2BSva3i ds052_R2.0.0_metadata_derivatives.tgz\n' to batched annex BatchedAnnex(annex_cmd='addurl', annex_options=<<['-c', 'annex.largefil...>>, git_options=[], output_proc=<function>, path=<<'/mnt/btrfs/datasets/d...>>) (annexrepo.py:1234)
+2016-05-23 16:41:59,968 [Level 5] Done sending. (annexrepo.py:1242)
+yoh@datasets.datalad.org's password: 
+"""]]
+
+That repository indeed has a remote (ssh) setup pointing to datasets.datalad.org (which carries no load for annex, besides git-annex repository, ATM), but that remote should not be consulted IMHO for addurl operation (not to mention in the --batch mode shouldn't request any user interaction)
+
+[[!author meta=yoh]]

reply
diff --git a/doc/design/external_special_remote_protocol/comment_30_7d045871f9ebbb89e3f9bbfa28e8468f._comment b/doc/design/external_special_remote_protocol/comment_30_7d045871f9ebbb89e3f9bbfa28e8468f._comment
new file mode 100644
index 0000000..4330e7f
--- /dev/null
+++ b/doc/design/external_special_remote_protocol/comment_30_7d045871f9ebbb89e3f9bbfa28e8468f._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 30"""
+ date="2016-05-23T18:54:35Z"
+ content="""
+You can find out the size of a key by using 
+`git-annex examinekey $key --format='${bytesize}\n'` 
+(There's a --batch option to avoid needing to spin up
+repeated such processes.)
+
+I suppose I could add a PROGRESSPRECENT, but any version of git-annex that
+didn't support it would fail with a protocol error if a special remote
+tried to use that. So, the special remote would need to check git-annex
+version to use it.
+
+So, maybe better to get the size of the key yourself, and convert the
+percentage to bytes for PROGRESS.
+"""]]

note commands which do not get a reply
diff --git a/doc/design/external_special_remote_protocol.mdwn b/doc/design/external_special_remote_protocol.mdwn
index 06d00b5..d775fb8 100644
--- a/doc/design/external_special_remote_protocol.mdwn
+++ b/doc/design/external_special_remote_protocol.mdwn
@@ -150,7 +150,7 @@ so if an unknown request is seen, reply with `UNSUPPORTED-REQUEST`.
 
 These should be sent only in response to the git-annex request messages.
 They do not have to be sent immediately after the request; the special
-remote can send its own requests (listed in the next section below)
+remote can send its own messages (listed in the next section below)
 while it's handling a request.
 
 * `PREPARE-SUCCESS`  
@@ -220,7 +220,9 @@ in control.
 * `VERSION Int`  
   Supported protocol version. Current version is 1. Must be sent first
   thing at startup, as until it sees this git-annex does not know how to
-  talk with the special remote program!
+  talk with the special remote program!  
+  (git-annex does not send a reply to this message, but may give up if it
+  doesn't support the necessary protocol version.)
 * `PROGRESS Int`  
   Indicates the current progress of the transfer (in bytes). May be repeated
   any number of times during the transfer process, but it's wasteful to
@@ -246,7 +248,8 @@ in control.
   Normally this is sent during INITREMOTE, which allows these settings
   to be stored in the git-annex branch, so will be available if the same
   special remote is used elsewhere. (If sent after INITREMOTE, the changed
-  configuration will only be available while the remote is running.)
+  configuration will only be available while the remote is running.)  
+  (git-annex does not send a reply to this message.)
 * `GETCONFIG Setting`  
   Gets one of the special remote's configuration settings, which can have
   been passed by the user when running `git annex initremote`, or
@@ -264,7 +267,8 @@ in control.
   case the creds will be encrypted using it. If creds are not stored in
   the configuration, they'll only be stored in a local file.  
   (embedcreds can be set to yes by the user or by SETCONFIG to force
-   the creds to be stored in the remote's configuration).
+   the creds to be stored in the remote's configuration).  
+  (git-annex does not send a reply to this message.)
 * `GETCREDS Setting`  
   Gets any creds that were previously stored in the remote's configuration
   or a file.
@@ -282,7 +286,8 @@ in control.
   this is not configured by a special remote, but it may make sense
   in some situations to hint at the kind of content that should be stored
   in the special remote. Note that if a unparsable expression is set,
-  git-annex will ignore it.
+  git-annex will ignore it.  
+  (git-annex does not send a reply to this message.)
 * `GETWANTED`  
   Gets the current preferred content setting of the repository.
   (git-annex replies with VALUE followed by the preferred content
@@ -294,7 +299,8 @@ in control.
   multiple repositories are using the same special remote, and store
   different state, whichever one stored the state last will win. Also,
   it's best to avoid storing much state, since this will bloat the
-  git-annex branch. Most remotes will not need to store any state.
+  git-annex branch. Most remotes will not need to store any state.  
+  (git-annex does not send a reply to this message.)
 * `GETSTATE Key`  
   Gets any state that has been stored for the key.  
   (git-annex replies with VALUE followed by the state.)
@@ -305,17 +311,21 @@ in control.
   Keep in mind that this stores the url in the git-annex branch. This can
   result in bloat to the branch if the url is large and/or does not delta
   pack well with other information (such as the names of keys) already
-  stored in the branch.
+  stored in the branch.  
+  (git-annex does not send a reply to this message.)
 * `SETURLMISSING Key Url`  
   Records that the key can no longer be downloaded from the specified
-  URL.
+  URL.  
+  (git-annex does not send a reply to this message.)
 * `SETURIPRESENT Key Uri`  
   Records an URI where the Key can be downloaded from.  
   For example, "ipfs:ADDRESS" is used for the ipfs special remote;
-  its CLAIMURL handler checks for such URIS and claims them.
+  its CLAIMURL handler checks for such URIS and claims them.  
+  (git-annex does not send a reply to this message.)
 * `SETURIMISSING Key Uri`  
   Records that the key can no longer be downloaded from the specified
-  URI.
+  URI.  
+  (git-annex does not send a reply to this message.)
 * `GETURLS Key Prefix`  
   Gets the recorded urls where a Key can be downloaded from.
   Only urls that start with the Prefix will be returned. The Prefix

note version for recently added command
diff --git a/doc/design/external_special_remote_protocol.mdwn b/doc/design/external_special_remote_protocol.mdwn
index 81feda1..06d00b5 100644
--- a/doc/design/external_special_remote_protocol.mdwn
+++ b/doc/design/external_special_remote_protocol.mdwn
@@ -239,7 +239,8 @@ in control.
   This is always the same for any given Key, so can be used for eg,
   creating hash directory structures to store Keys in. This is the same
   directory hash that is used by eg, the directory special remote.  
-  (git-annex replies with VALUE followed by the value.)
+  (git-annex replies with VALUE followed by the value.)  
+  (First supported by git-annex version 6.20160511.)
 * `SETCONFIG Setting Value`  
   Sets one of the special remote's configuration settings.  
   Normally this is sent during INITREMOTE, which allows these settings
@@ -323,6 +324,7 @@ in control.
   The final VALUE has an empty value, indicating the end of the url list.)
 * `DEBUG message`
   Tells git-annex to display the message if --debug is enabled.
+  (git-annex does not send a reply to this message.)
 
 ## general messages
 

comment, reopen
diff --git a/doc/bugs/annex.gnupg-options_not_used_by_assistant.mdwn b/doc/bugs/annex.gnupg-options_not_used_by_assistant.mdwn
index 9ad3f53..09ff1ab 100644
--- a/doc/bugs/annex.gnupg-options_not_used_by_assistant.mdwn
+++ b/doc/bugs/annex.gnupg-options_not_used_by_assistant.mdwn
@@ -78,4 +78,6 @@ gpg: cannot open `/dev/tty': Device not configured
 ### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
 
 
-> added annex.gnupg-decrypt-options; [[done]] --[[Joey]]
+> added annex.gnupg-decrypt-options; done --[[Joey]]
+
+>> Reopening, see comment. --[[Joey]]
diff --git a/doc/bugs/annex.gnupg-options_not_used_by_assistant/comment_3_4bb4bed22dc8dcc0308a557d3dae76e4._comment b/doc/bugs/annex.gnupg-options_not_used_by_assistant/comment_3_4bb4bed22dc8dcc0308a557d3dae76e4._comment
new file mode 100644
index 0000000..13684cb
--- /dev/null
+++ b/doc/bugs/annex.gnupg-options_not_used_by_assistant/comment_3_4bb4bed22dc8dcc0308a557d3dae76e4._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2016-05-23T18:21:16Z"
+ content="""
+The gpg calls in that log are being done by git-annex, not by
+git-remote-gcrypt.
+
+I think this is decryptCipher, which can run gpg --decrypt and didn't
+get annex.gnupg-decrypt-options wired up to it. Although normally the
+creds would be cached when the special remote is set up or the first time
+it's used and should not need to be decrypted again.
+
+Threading gnupg-decrypt-options through to decryptCipher looks likely to
+involve nearly a full day's work.
+"""]]

comment
diff --git a/doc/bugs/Continual_space_exhaustion_from_syncing_metadata/comment_1_93e3deab54b34e9ad608fd549119e221._comment b/doc/bugs/Continual_space_exhaustion_from_syncing_metadata/comment_1_93e3deab54b34e9ad608fd549119e221._comment
new file mode 100644
index 0000000..df07a2a
--- /dev/null
+++ b/doc/bugs/Continual_space_exhaustion_from_syncing_metadata/comment_1_93e3deab54b34e9ad608fd549119e221._comment
@@ -0,0 +1,26 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-05-23T18:02:11Z"
+ content="""
+It would be nice if git checked disk space before writing object
+files. However, it unfortunatly does not do so currently, and not checking
+disk space is typical of unix tools so it might be hard to convince the git
+devs to add that.
+
+git-annex has annex.diskreserve because it's dealing with so much data and
+such large files that it's best to not let it fill the disk and instead
+abort before it downloads too much data.
+
+I don't see any way that git-annex can avoid git objects taking up too much
+disk space, without re-implementing all of git + space checking. 
+
+Sure, `git annex sync` could avoid pulling if annex.diskreserve was not
+free, but this would not help with manual `git pull`, or `git commit`, or
+`git receive-pack`, or any of the other ways objects can be added to a git
+repository.
+
+What you can do though, is set annex.diskreserve to a reasonably
+large amount, so that git-annex tries to keep that much space free.
+Eg, set it to at least half the current size of `du -hs .git/objects`
+"""]]

initial pass
diff --git a/doc/bugs/Assistant_keeps_deleting_all_the_files_in_my_repo/comment_2_c3408c31cf1c58b6b1e34102127ba613._comment b/doc/bugs/Assistant_keeps_deleting_all_the_files_in_my_repo/comment_2_c3408c31cf1c58b6b1e34102127ba613._comment
new file mode 100644
index 0000000..b56f494
--- /dev/null
+++ b/doc/bugs/Assistant_keeps_deleting_all_the_files_in_my_repo/comment_2_c3408c31cf1c58b6b1e34102127ba613._comment
@@ -0,0 +1,56 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2016-05-23T17:30:07Z"
+ content="""
+I've now got a copy of the repo, in
+~/lib/big/git-annex-test-repos/ssl.zerodogg.org__zerodogg_private_tmp_privateDocs.zerodogg.tar.xz.gpg
+
+Looking at commit 77c7d149646655fb5851c3db584fe70d64707d04, it merges in
+0b4896bc205696630c81cf557959a4aaa24906f0 which has an empty tree. 
+
+0b4896bc205696630c81cf557959a4aaa24906f0 is itself a merge commit. 
+Both of the commits it merges themselves have empty trees.
+And so it goes down quite a way, with empty merge commits including
+418367b, 7bab5cf, b651554, cf5de84, c5905f7, 928040e, a590245, 5b53fc9, 
+6d9f5da, 5f2623d. The freqency of these might indeed indicate some kind
+of feedback loop, but I don't think whatever is causing that is the core problem.
+
+fc6670a37fd9d3984a112a80d9bbaec5c041c005 is the crucial merge it seems. Its
+parents are 71b6c8a and f8dfc21. Both of those parents have the same tree,
+5f18bed323c29fb77add3a84abcf8b1fb6b646d7, and that tree is populated with all
+the files. But somehow this merge deleted everything.
+
+	tree 4b825dc642cb6eb9a060e54bf8d69288fbee4904
+	parent 71b6c8ad3fc44926c9be2bbb1bd308592b6eb05c
+	parent f8dfc219a40b2871baed3192ea5806bb4ac551e7
+	author xxx 1463570165 +0200
+	committer xxx 1463570165 +0200
+	
+	Merge branch 'refs/heads/synced/master' into HEAD
+
+(There are empty trees earlier where the same thing happened that you
+reverted, but it seems best to focus on the most recent occurance.)
+
+So, can you find fc6670a in .git/annex/daemon.log* in any of the
+clones of this repository? It would be good to narrow down on which
+machine(s) the bad merge is happening. (Maybe you've already narrowed it down?)
+
+One of the two parent commits (71b6c8ad3fc44926c9be2bbb1bd308592b6eb05c)
+is a manual revert you did, the other commit looks to have been done by
+the assistant. 
+I'm guessing that refs/heads/synced/master was f8dfc219a40b2871baed3192ea5806bb4ac551e7
+when the bad merge was generated. So this bad merge probably happened in
+the repository where you did that manual reversion.
+
+As far as I can tell this was a regular git merge that somehow decided to empty
+the tree. It was not a case of git-annex auto-resolving a merge conflict.
+
+Are you using adjusted branches in any of the clones of this repository?
+
+What version(s) of git are being used?
+
+(I noticed that despite using v6 mode, every file in the repository
+seems to be locked, so the smudge filters etc should not be involved in the
+problem unless using an adjusted branch.)
+"""]]

comment
diff --git a/doc/bugs/__34__invalid_object__34___errors_cropping_up/comment_1_d146a64ef8d76c2a7e45bf85d8943456._comment b/doc/bugs/__34__invalid_object__34___errors_cropping_up/comment_1_d146a64ef8d76c2a7e45bf85d8943456._comment
new file mode 100644
index 0000000..6c7b8e2
--- /dev/null
+++ b/doc/bugs/__34__invalid_object__34___errors_cropping_up/comment_1_d146a64ef8d76c2a7e45bf85d8943456._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-05-23T16:52:23Z"
+ content="""
+Try running `git fsck` and see if it complains about a corrupt object file.
+You may then need to delete the object file and fix up the repository to
+not refer to it. `git annex repair` can probably handle that.
+
+> Some object in the broken repo seems to be causing this issue somehow.
+
+Maybe, but you also say that the object it complains about has varied.
+Perhaps you have multiple corrupt objects in the git repo..
+
+You mention "litelog". What is that and how is it relevant? Is Android
+involved somehow?
+"""]]

Added a comment
diff --git a/doc/bugs/ghc_8.0.1_build_fixes/comment_2_4b2c8620824dc625b3aecee9838a04c3._comment b/doc/bugs/ghc_8.0.1_build_fixes/comment_2_4b2c8620824dc625b3aecee9838a04c3._comment
new file mode 100644
index 0000000..1a2bb50
--- /dev/null
+++ b/doc/bugs/ghc_8.0.1_build_fixes/comment_2_4b2c8620824dc625b3aecee9838a04c3._comment
@@ -0,0 +1,33 @@
+[[!comment format=mdwn
+ username="ilovezfs"
+ subject="comment 2"
+ date="2016-05-23T16:26:35Z"
+ content="""
+> How does GHC complain about \"runner\"? 
+
+[[!format  text \"\"\"
+Remote/Bup.hs:137:30: error:
+    • Couldn't match expected type ‘t’
+                  with actual type ‘Utility.Process.CreateProcessRunner
+                                    -> CreateProcess -> (Handle -> IO a0) -> IO a0’
+      ‘t’ is a rigid type variable bound by
+        the inferred type of runner :: t at Remote/Bup.hs:136:13
+    • In the expression: feedWithQuietOutput
+      In the expression:
+        if quiet then feedWithQuietOutput else withHandle StdinHandle
+      In an equation for ‘runner’:
+          runner
+            = if quiet then feedWithQuietOutput else withHandle StdinHandle
+    • Relevant bindings include
+        runner :: t (bound at Remote/Bup.hs:136:13)
+\"\"\"]]
+
+>I've applied your change to Setup-Depends. Oddly, I seem to remember trying the Setup-Depends with the new cabal and thought it was working..
+
+
+It is working, until I run \"cabal configure\". Then it breaks unless I add those additional dependencies.
+
+I'll check on your other questions in a bit.
+
+
+"""]]

comment
diff --git a/doc/bugs/ghc_8.0.1_build_fixes/comment_1_bc5e868448fb0d45f2586d4ac24437fb._comment b/doc/bugs/ghc_8.0.1_build_fixes/comment_1_bc5e868448fb0d45f2586d4ac24437fb._comment
new file mode 100644
index 0000000..01657fe
--- /dev/null
+++ b/doc/bugs/ghc_8.0.1_build_fixes/comment_1_bc5e868448fb0d45f2586d4ac24437fb._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-05-23T14:50:25Z"
+ content="""
+How does GHC complain about "runner"? Would
+-XNoMonomorphismRestriction fix it? I don't like the suggested change
+because seeing that code, I'd naturally want to refactor it back to
+something like how it's currently written.. (Still, I've applied the patch
+for now.)
+
+I've relaxed the bounds on base. AFAICS there are no bounds on time and
+transformers, so what were you suggesting I change there?
+
+I've applied your change to Setup-Depends. Oddly, I seem to remember
+trying the Setup-Depends with the new cabal and thought it was working..
+"""]]

diff --git a/doc/bugs/__34__invalid_object__34___errors_cropping_up.mdwn b/doc/bugs/__34__invalid_object__34___errors_cropping_up.mdwn
index 35adfb2..5a06bf0 100644
--- a/doc/bugs/__34__invalid_object__34___errors_cropping_up.mdwn
+++ b/doc/bugs/__34__invalid_object__34___errors_cropping_up.mdwn
@@ -82,7 +82,8 @@ annex.4:
    $ git annex sync gitlab
     both commands ran without issue
     delta also fsck'd fine
-
+ 11. 2016-05-23 07:01 EDT
+    local repo fsck'd fine
 """]]
 
 ### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)

diff --git a/doc/bugs/__34__invalid_object__34___errors_cropping_up.mdwn b/doc/bugs/__34__invalid_object__34___errors_cropping_up.mdwn
new file mode 100644
index 0000000..35adfb2
--- /dev/null
+++ b/doc/bugs/__34__invalid_object__34___errors_cropping_up.mdwn
@@ -0,0 +1,90 @@
+### Please describe the problem.
+In my repo network, multiple repos are cropping up with an "invalid object" error.  The object in question changes and appears to be from git-annex's hidden branch.
+
+### What steps will reproduce the problem?
+This is happening after I add a mess of new files and sync, within a couple times of doing this, after a day or so.
+
+### What version of git-annex are you using? On what operating system?
+6.20160518-g766728c on linux
+
+### Please provide any additional information below.
+
+[[!format sh """
+# Example error, file in question will change
+    (recording state in git...)
+    error: invalid object 100644 d547f60ac6c53f8bf38999d93ce954e3dfca1656 for
+    '051/0b4/SHA3_512-s12447441634--b84ff2ead694b9d355d8deb4eae620b5979f0127f127718d53d02cd32f1020fba45f1e63723484462beb10110328dab29d875ea1788f949ce541640603fa73c0.log'
+    fatal: git-write-tree: error building trees
+    git-annex: failed to read sha from git write-tree
+# End of transcript or log.
+
+# log of attempting to determine the issue yesterday
+2016-05-22
+
+Issue history:
+Original annex started being unable to finish commit.
+Second annex, I cloned and copied objects folder over.  Soon, same issue.
+Third annex, cloned from elsewhere, use git annex get to get objects from
+broken repo.  Same issue developed.
+Fourth annex, cloned from elsewhere, was able to commit successfully
+prior to adding objects from broken repo.
+Some object in the broken repo seems to be causing this issue somehow.
+
+Plan to resolve:
+- copy all objects over again.  verify that issue immediately develops.
+  
+  I expect the issue will trigger when I add a set of objects with litelog.
+  So I could narrow it either by narrowing the objects I add with litelog,
+  or by narrowing the object I copy from the broken repo.
+
+  I'll narrow the issue between the two, first.
+
+annex: used to be annex.2, busted
+annex.3: third repository, busted, holds objects
+annex.4:
+  1. cloned from delta
+  2. added logs, no issue
+  3. 10:24:24 EDT rsync --delete-during'd objects in from annex.3
+  4. 10:25:10 EDT added small test file, sync'd with delta fine
+  5. 2016-05-22 10:27:38
+      I ran fetchall but ran by root by mistake.
+      files were added with wrong permissions
+      fixed permissions.  only two files were cpied, voicerecorder and muse.
+      sync works fine.'
+  6. ran fetchall (as root) again, got 4 sensorium files
+  7. add and sync seems to work fine.
+  So now this repository is functioning with additional objects copied into
+  its annex folder.  It must have been something else which caused the issue
+  on the other repo I initialized this way.
+  8. I foolishly tried to git annex add the alphabetically first object from
+  the annex/objects folder to get it annex's logs.  It failed when trying to
+  _delete_ it to replace it with a link to itself, luckily it was not writable.
+
+  I'll try using this repo - 2016-05-22 10:36:24 EDT
+
+  I'll add the remotes one at a time and sync with them, adding litelog after
+  each one.
+
+  9. 2016-05-23 00:08 EDT
+    Issue reoccurred uploading data from phone. Was a larger block of data.
+    First fetched
+    then added
+    then copied to delta
+    issue showed at end of copy to delta
+
+    perhaps the issue resides on delta ??? but we synced to delta fine before
+    the issue must happen over time while I am away from the computer
+    or respond to a large amount of logs being uploaded
+    or it could have happened as a result of my work on the nested repo
+ 10. 2016-05-23 00:10:15 EDT
+   $ git annex copy --to=gitlab
+   06:55 EDT
+   $ git annex sync gitlab
+    both commands ran without issue
+    delta also fsck'd fine
+
+"""]]
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+Very stable.  Still excited.
+

diff --git a/doc/bugs/ghc_8.0.1_build_fixes.mdwn b/doc/bugs/ghc_8.0.1_build_fixes.mdwn
index daa9243..8770104 100644
--- a/doc/bugs/ghc_8.0.1_build_fixes.mdwn
+++ b/doc/bugs/ghc_8.0.1_build_fixes.mdwn
@@ -32,8 +32,10 @@ We run "cabal configure --flags=…" to verify the build will successfully enabl
 
 In order to run configure, I make the following change:
 
+[[!format  text """
 inreplace "git-annex.cabal",
   "Setup-Depends: base (>= 4.5), hslogger, MissingH",
   "Setup-Depends: base (>= 4.5), hslogger, MissingH, unix-compat, process, unix, filepath, exceptions, bytestring, directory, IfElse, data-default, Cabal"
 end
+"""]]
 

diff --git a/doc/bugs/ghc_8.0.1_build_fixes.mdwn b/doc/bugs/ghc_8.0.1_build_fixes.mdwn
index 6967421..daa9243 100644
--- a/doc/bugs/ghc_8.0.1_build_fixes.mdwn
+++ b/doc/bugs/ghc_8.0.1_build_fixes.mdwn
@@ -14,7 +14,7 @@ The second patch is a code change.
 
 GHC 8.0.1 complains about these lines: https://github.com/joeyh/git-annex/blob/08625c5a89b14415c1c7fef518f27b07b0899c24/Remote/Bup.hs#L136-L141
 
-The variable "runner" fails to monomorphic, so I'm using the following hack (though I'm sure there's a better way to fix this):
+The variable "runner" fails to be monomorphic, so I'm using the following hack (though I'm sure there's a better way to fix this):
 
 [[!format  haskell """
     if quiet

Patches for GHC 8 and for cabal configure
diff --git a/doc/bugs/ghc_8.0.1_build_fixes.mdwn b/doc/bugs/ghc_8.0.1_build_fixes.mdwn
new file mode 100644
index 0000000..6967421
--- /dev/null
+++ b/doc/bugs/ghc_8.0.1_build_fixes.mdwn
@@ -0,0 +1,39 @@
+git-annex needs tweaks to build with ghc 8.0.1 and to run "cabal configure"
+
+Homebrew core only supports the latest stable version of each formula, so the release of ghc 8.0.1, which is now the latest stable version of ghc, will render git-annex unbuildable without patching.
+
+This affects both HEAD and 6.20160511
+
+GHC 8 compatibility:
+I have two patches to get it working. 6.20160511 passes all the tests in the "git annex test" suite built against GHC 8.0.1 with the patches. HEAD fails several of the tests but that seems to have nothing to do with GHC 8.0.1 specifically, and I'm sure you're already aware of these test suite issues with current HEAD.
+
+The first patch for GHC 8 is a cabal change.
+(buildpath/"cabal.config").write("allow-newer: base,time,transformers\n")
+
+The second patch is a code change.
+
+GHC 8.0.1 complains about these lines: https://github.com/joeyh/git-annex/blob/08625c5a89b14415c1c7fef518f27b07b0899c24/Remote/Bup.hs#L136-L141
+
+The variable "runner" fails to monomorphic, so I'm using the following hack (though I'm sure there's a better way to fix this):
+
+[[!format  haskell """
+    if quiet
+      then liftIO $ feedWithQuietOutput createProcessSuccess cmd $ \h -> do
+        meteredWrite p h b
+        return True
+      else liftIO $ withHandle StdinHandle createProcessSuccess cmd $ \h -> do
+        meteredWrite p h b
+        return True
+"""]]
+
+Making cabal configure work:
+
+We run "cabal configure --flags=…" to verify the build will successfully enable the expected features, but this fails without addition custom setup dependencies. This affects the git-version of git  annex which has the custom setup section (both 6.20160511 and HEAD), but doesn't affect the Hackage 6.20160511 download because it has the custom-setup stanza removed.
+
+In order to run configure, I make the following change:
+
+inreplace "git-annex.cabal",
+  "Setup-Depends: base (>= 4.5), hslogger, MissingH",
+  "Setup-Depends: base (>= 4.5), hslogger, MissingH, unix-compat, process, unix, filepath, exceptions, bytestring, directory, IfElse, data-default, Cabal"
+end
+

Added a comment: Arrived in homebrew - Fix not working?
diff --git a/doc/bugs/annex.gnupg-options_not_used_by_assistant/comment_2_e5bc3c7cbe4af61868ac8163cd39c11a._comment b/doc/bugs/annex.gnupg-options_not_used_by_assistant/comment_2_e5bc3c7cbe4af61868ac8163cd39c11a._comment
new file mode 100644
index 0000000..d37bb99
--- /dev/null
+++ b/doc/bugs/annex.gnupg-options_not_used_by_assistant/comment_2_e5bc3c7cbe4af61868ac8163cd39c11a._comment
@@ -0,0 +1,40 @@
+[[!comment format=mdwn
+ username="rustikus@9db90d0c115a1825e2f1e5f15257ec1298a6c7b6"
+ nickname="rustikus"
+ subject="Arrived in homebrew - Fix not working?"
+ date="2016-05-22T19:58:32Z"
+ content="""
+The new version arrived in homebrew today. Thanks for adding the possibility to add GPG decrypt options. 
+I added --no-tty to annex.gnupg-decrypt-options but unfortunately it is not picked up by gpg. This is the log after removing --no-tty from .gnupg/gpg.conf and only adding it to .git/config.
+
+[2016-05-22 21:23:15.527812] Committer: Adding test.md  
+add /Users/xxx/annex/nvatom/test.md ok  
+[2016-05-22 21:23:15.72065] Committer: Committing changes to git  
+(recording state in git...)  
+[2016-05-22 21:23:15.808952] Pusher: Syncing with hidrive   
+gcrypt: Development version -- Repository format MAY CHANGE  
+gcrypt: Decrypting manifest  
+gpg: Signature made Sat May 21 21:12:40 2016 CEST using RSA key ID XXXXXXX  
+gpg: Good signature from \"Git Annex (Key for git annex encryption) <xxx@xxx.de>\" [ultimate]  
+gcrypt: Encrypting to:  -r XXXXXXXXXXXXX  
+gcrypt: Requesting manifest signature  
+[2016-05-22 21:23:20.955819] Committer: Adding test.md  
+add /Users/xxx/annex/nvatom/test.md ok  
+[2016-05-22 21:23:20.973532] Committer: Committing changes to git  
+(recording state in git...)  
+gpg: cannot open `/dev/tty': Device not configured  
+
+  user error (gpg2 [\"--quiet\",\"--trust-model\",\"always\",\"--decrypt\"] exited 2)  
+gpg: cannot open `/dev/tty': Device not configured
+
+  user error (gpg2 [\"--quiet\",\"--trust-model\",\"always\",\"--decrypt\"] exited 2)  
+To gcrypt::rsync.hidrive.strato.com:/users/xxx/hidrive.git  
+   b50d4d1..eb9ef83  master -> synced/master  
+   9504de9..ed2332b  git-annex -> synced/git-annex  
+[2016-05-22 21:23:40.167619] Pusher: Syncing with hidrive 
+
+
+Unfortunately there is no upload happening but the status in the webapp is showing no error (everything green). Not sure if the error is actually coming from gcrypt and not git-annex? 
+
+
+"""]]

diff --git a/doc/bugs/Continual_space_exhaustion_from_syncing_metadata.mdwn b/doc/bugs/Continual_space_exhaustion_from_syncing_metadata.mdwn
new file mode 100644
index 0000000..ca826fb
--- /dev/null
+++ b/doc/bugs/Continual_space_exhaustion_from_syncing_metadata.mdwn
@@ -0,0 +1,26 @@
+### Please describe the problem.
+When the preferred content for a repo is greater than the free space on the drive for me, the space becomes exhausted due to upload that occurs during syncing -- the git history ends up exhausting the space.  The result for me has been corrupted repos with broken refs and heads.
+
+I think it would be better if the git syncing process respected the same space limitations that the content syncing does, and did not push if space was exhausted on the destination, nor pull if space exhausted locally.
+
+### What steps will reproduce the problem?
+Make enough git commits that it exhausts the free space on some repo.
+
+### What version of git-annex are you using? On what operating system?
+I've been using a few different versions; right now I am using 6.2016-0511 and 6.2016-0517-g766728c
+but I have not tested this issue with these most recent versions.  I am still trying to get my smaller repos back together.
+
+### Please provide any additional information below.
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+
+
+# End of transcript or log.
+"""]]
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+Yes !!! I'm moving all my files into my annex.  It is very robust; whenever something is wrong there is always some other copy somewhere that can be used.
+

removed
diff --git a/doc/bugs/Low_disk_space_corrupts_state/comment_3_d31841c77aef8ef7c9cd8a061c66eca8._comment b/doc/bugs/Low_disk_space_corrupts_state/comment_3_d31841c77aef8ef7c9cd8a061c66eca8._comment
deleted file mode 100644
index eed705f..0000000
--- a/doc/bugs/Low_disk_space_corrupts_state/comment_3_d31841c77aef8ef7c9cd8a061c66eca8._comment
+++ /dev/null
@@ -1,7 +0,0 @@
-[[!comment format=mdwn
- username="xloem"
- subject="This could be detected"
- date="2016-05-22T16:26:29Z"
- content="""
-Git-annex could detect this by attempting to write a 1-byte file.
-"""]]

Added a comment: This could be detected
diff --git a/doc/bugs/Low_disk_space_corrupts_state/comment_3_d31841c77aef8ef7c9cd8a061c66eca8._comment b/doc/bugs/Low_disk_space_corrupts_state/comment_3_d31841c77aef8ef7c9cd8a061c66eca8._comment
new file mode 100644
index 0000000..eed705f
--- /dev/null
+++ b/doc/bugs/Low_disk_space_corrupts_state/comment_3_d31841c77aef8ef7c9cd8a061c66eca8._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="xloem"
+ subject="This could be detected"
+ date="2016-05-22T16:26:29Z"
+ content="""
+Git-annex could detect this by attempting to write a 1-byte file.
+"""]]

Added a comment
diff --git a/doc/devblog/day_392__v6_fixes/comment_3_74e696f147f80162a941a5a5435327ce._comment b/doc/devblog/day_392__v6_fixes/comment_3_74e696f147f80162a941a5a5435327ce._comment
new file mode 100644
index 0000000..e331dd8
--- /dev/null
+++ b/doc/devblog/day_392__v6_fixes/comment_3_74e696f147f80162a941a5a5435327ce._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="xloem"
+ subject="comment 3"
+ date="2016-05-22T15:58:22Z"
+ content="""
+Thanks.
+"""]]

comment
diff --git a/doc/devblog/day_392__v6_fixes/comment_2_15434848be1951e93a1e5b9fcbccedb0._comment b/doc/devblog/day_392__v6_fixes/comment_2_15434848be1951e93a1e5b9fcbccedb0._comment
new file mode 100644
index 0000000..129f88e
--- /dev/null
+++ b/doc/devblog/day_392__v6_fixes/comment_2_15434848be1951e93a1e5b9fcbccedb0._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2016-05-21T13:55:01Z"
+ content="""
+Dangling objects are not related to the v6 syncing problems mentioned in
+this post.
+
+You can generally safely delete dangling objects from a git repository;
+git gc does it automatically after 30 days or so. git-annex does not
+normally create dangling objects but several git operations can.
+"""]]

comment
diff --git a/doc/todo/make_copy_--fast__faster/comment_1_24a9ca652007a18f18b368232cf549da._comment b/doc/todo/make_copy_--fast__faster/comment_1_24a9ca652007a18f18b368232cf549da._comment
new file mode 100644
index 0000000..b53e04f
--- /dev/null
+++ b/doc/todo/make_copy_--fast__faster/comment_1_24a9ca652007a18f18b368232cf549da._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-05-21T13:53:15Z"
+ content="""
+--to or --from? The latter is faster due to locality..
+"""]]

rename
diff --git a/doc/bugs/.mdwn b/doc/bugs/.mdwn
deleted file mode 100644
index 58ae5d9..0000000
--- a/doc/bugs/.mdwn
+++ /dev/null
@@ -1,15 +0,0 @@
-A default cabal install on OS X in a sandbox of git-annex 6.20160511 will result in no S3 support, as reported to Homebrew in the following two issues:
-https://github.com/Homebrew/homebrew-core/issues/1268
-https://github.com/Homebrew/legacy-homebrew/issues/47737
-
-The underlying cause is that aws-0.13.0 lacks commit https://github.com/aristidb/aws/commit/402bfe5aa9ef4bec84186880faafcbfdae1ad91d, which allows data-default 0.6.
-
-I attempted to mitigate the issue using --flags="s3", but that does not seem to help (nor does it force the build to fail): still no s3 support. I'd expect that either to constrain data-default to 0.5.3 and produce a build with s3 support, or fail the build, but for some reason it doesn't. Is this not working because we're in a sandbox or some other reason?
-
-Currently, I'm planning to just patch aws with https://github.com/aristidb/aws/commit/402bfe5aa9ef4bec84186880faafcbfdae1ad91d rather than resorting to a fixed configuration (e.g., lts-5.5 or whatever), as you can see here:
-https://github.com/Homebrew/homebrew-core/pull/1307
-
-It would be great if git-annex could work around the issue itself, though.
-
-Meanwhile, I have also pinged aws to request a 0.13.1 release, which would solve the problem "the right way":
-https://github.com/aristidb/aws/issues/202
diff --git a/doc/bugs/default_cabal_install_on_OSX_lacks_S3.mdwn b/doc/bugs/default_cabal_install_on_OSX_lacks_S3.mdwn
new file mode 100644
index 0000000..58ae5d9
--- /dev/null
+++ b/doc/bugs/default_cabal_install_on_OSX_lacks_S3.mdwn
@@ -0,0 +1,15 @@
+A default cabal install on OS X in a sandbox of git-annex 6.20160511 will result in no S3 support, as reported to Homebrew in the following two issues:
+https://github.com/Homebrew/homebrew-core/issues/1268
+https://github.com/Homebrew/legacy-homebrew/issues/47737
+
+The underlying cause is that aws-0.13.0 lacks commit https://github.com/aristidb/aws/commit/402bfe5aa9ef4bec84186880faafcbfdae1ad91d, which allows data-default 0.6.
+
+I attempted to mitigate the issue using --flags="s3", but that does not seem to help (nor does it force the build to fail): still no s3 support. I'd expect that either to constrain data-default to 0.5.3 and produce a build with s3 support, or fail the build, but for some reason it doesn't. Is this not working because we're in a sandbox or some other reason?
+
+Currently, I'm planning to just patch aws with https://github.com/aristidb/aws/commit/402bfe5aa9ef4bec84186880faafcbfdae1ad91d rather than resorting to a fixed configuration (e.g., lts-5.5 or whatever), as you can see here:
+https://github.com/Homebrew/homebrew-core/pull/1307
+
+It would be great if git-annex could work around the issue itself, though.
+
+Meanwhile, I have also pinged aws to request a 0.13.1 release, which would solve the problem "the right way":
+https://github.com/aristidb/aws/issues/202

Added a comment: Retrieval progress message helpers
diff --git a/doc/design/external_special_remote_protocol/comment_29_c1d97815386453c3e433fca9a44c4667._comment b/doc/design/external_special_remote_protocol/comment_29_c1d97815386453c3e433fca9a44c4667._comment
new file mode 100644
index 0000000..b714602
--- /dev/null
+++ b/doc/design/external_special_remote_protocol/comment_29_c1d97815386453c3e433fca9a44c4667._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="xloem"
+ subject="Retrieval progress message helpers"
+ date="2016-05-20T19:42:23Z"
+ content="""
+It would be nice if
+- progress could be provided in percentage rather than bytes, when that's all that's available
+- git-annex could inform the special remote how many bytes a file to be downloaded is, if that information is already available
+"""]]

S3 support lacking in a stock cabal install build in a sandbox on OS X
diff --git a/doc/bugs/.mdwn b/doc/bugs/.mdwn
new file mode 100644
index 0000000..58ae5d9
--- /dev/null
+++ b/doc/bugs/.mdwn
@@ -0,0 +1,15 @@
+A default cabal install on OS X in a sandbox of git-annex 6.20160511 will result in no S3 support, as reported to Homebrew in the following two issues:
+https://github.com/Homebrew/homebrew-core/issues/1268
+https://github.com/Homebrew/legacy-homebrew/issues/47737
+
+The underlying cause is that aws-0.13.0 lacks commit https://github.com/aristidb/aws/commit/402bfe5aa9ef4bec84186880faafcbfdae1ad91d, which allows data-default 0.6.
+
+I attempted to mitigate the issue using --flags="s3", but that does not seem to help (nor does it force the build to fail): still no s3 support. I'd expect that either to constrain data-default to 0.5.3 and produce a build with s3 support, or fail the build, but for some reason it doesn't. Is this not working because we're in a sandbox or some other reason?
+
+Currently, I'm planning to just patch aws with https://github.com/aristidb/aws/commit/402bfe5aa9ef4bec84186880faafcbfdae1ad91d rather than resorting to a fixed configuration (e.g., lts-5.5 or whatever), as you can see here:
+https://github.com/Homebrew/homebrew-core/pull/1307
+
+It would be great if git-annex could work around the issue itself, though.
+
+Meanwhile, I have also pinged aws to request a 0.13.1 release, which would solve the problem "the right way":
+https://github.com/aristidb/aws/issues/202

Added a comment
diff --git a/doc/bugs/Assistant_keeps_deleting_all_the_files_in_my_repo/comment_1_951d03de942c19f760e9ff01a3b61f33._comment b/doc/bugs/Assistant_keeps_deleting_all_the_files_in_my_repo/comment_1_951d03de942c19f760e9ff01a3b61f33._comment
new file mode 100644
index 0000000..a65054c
--- /dev/null
+++ b/doc/bugs/Assistant_keeps_deleting_all_the_files_in_my_repo/comment_1_951d03de942c19f760e9ff01a3b61f33._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="EskildHustvedt"
+ subject="comment 1"
+ date="2016-05-20T07:45:52Z"
+ content="""
+Right, so I forgot to mention, perhaps crucially. I'm using v6 for these repos.
+
+Here's the tig grap for master: [[https://ssl.zerodogg.org/~zerodogg/tmp/annexmerge1-2016-05-20.png]]
+
+Here's the merge commit itself for master: [[https://ssl.zerodogg.org/~zerodogg/tmp/annexmerge2-2016-05-20.png]]
+"""]]

diff --git a/doc/bugs/Assistant_keeps_deleting_all_the_files_in_my_repo.mdwn b/doc/bugs/Assistant_keeps_deleting_all_the_files_in_my_repo.mdwn
new file mode 100644
index 0000000..c9752f0
--- /dev/null
+++ b/doc/bugs/Assistant_keeps_deleting_all_the_files_in_my_repo.mdwn
@@ -0,0 +1,24 @@
+### Please describe the problem.
+The assistant keeps making merges that deletes all the files in the repository. I "git revert" the merge commit, but the next day it does it again. It also seems to have gone into a merge loop before this happens (will post a screenshot of tig). I can make the repo available privately if that will help.
+
+### What steps will reproduce the problem?
+Unknown. It does it on its own without me even interacting with files in the annex.
+
+### What version of git-annex are you using? On what operating system?
+The host that keeps deleting is running 6.20160428-g1f253e8 on ArchLinux (x86_64). A remote that it keeps syncing with is running 6.20160511-g4633f0b, also on ArchLinux x86_64.
+
+### Please provide any additional information below.
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+Updating 8cb69d3..c589c5e
+Fast-forward
+ .gitignore                                                             | 3 ---
+ Bilete/8mars-2013-1.jpg                                                | 1 -
+etc.
+# End of transcript or log.
+"""]]
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+I use git-annex for everything. I've got 10 repositories and around 2.5TB of data in those repos which in turn is synced all over the place. It's excellent.

diff --git a/doc/todo/make_copy_--fast__faster.mdwn b/doc/todo/make_copy_--fast__faster.mdwn
new file mode 100644
index 0000000..2aea946
--- /dev/null
+++ b/doc/todo/make_copy_--fast__faster.mdwn
@@ -0,0 +1,3 @@
+I was trying to copy files which failed to copy (3 out of 6,000) to remote host after copy -J4.  Succeeded.  But with subsequent runs, apparently even with copy --fast it takes annex 10 sec for annex to realize there is nothing to copy. git ls-files  which annex calls returns list immediately, so it is really some parsing/access to data under git-annex branch which takes awhile.  I think we had similar discussion before but couldn't find.  So I wondered to whine again to see if some optimization is possible to make --fast copies faster, especially whenever there is nothing to copy.
+
+[[!meta author=yoh]]

Added a comment: Thank you
diff --git a/doc/forum/What_am_I_doing_wrong_with_move__63__/comment_2_eeae2f172b4481fcb08745fc28aa4d4e._comment b/doc/forum/What_am_I_doing_wrong_with_move__63__/comment_2_eeae2f172b4481fcb08745fc28aa4d4e._comment
new file mode 100644
index 0000000..2ec3568
--- /dev/null
+++ b/doc/forum/What_am_I_doing_wrong_with_move__63__/comment_2_eeae2f172b4481fcb08745fc28aa4d4e._comment
@@ -0,0 +1,42 @@
+[[!comment format=mdwn
+ username="Gus"
+ subject="Thank you"
+ date="2016-05-19T11:27:15Z"
+ content="""
+The external unit seems to hold a NTFS. Here is the `git-annex info` output:
+
+    repository mode: direct
+    trusted repositories: 0
+    semitrusted repositories: 4
+    	00000000-0000-0000-0000-000000000001 -- web
+     	00000000-0000-0000-0000-000000000002 -- bittorrent
+     	069de9a2-dc53-4c0a-82e0-a61a1f29e6b3 -- stratus PC [stratus]
+     	49b5b3a4-56ac-4cf2-aed9-1c23d3181c97 -- Toshiba USB HDD [here]
+    untrusted repositories: 0
+    transfers in progress: none
+    available local disk space: 4.42 gigabytes (+1 megabyte reserved)
+    local annex keys: 5556
+    local annex size: 1.66 terabytes
+    annexed files in working tree: 6618
+    size of annexed files in working tree: 1.1 terabytes
+    bloom filter size: 32 mebibytes (1.1% full)
+    backend usage: 
+    	SHA256E: 6618
+
+However, `git status` says:
+
+    fatal: This operation must be run in a work tree
+
+Which is not the same message as \"no git found here\", but is also not what I expected to see. `git log` seems to work but says nothing about the file at hand.
+
+On the PC side, however, I can see three commits on the file (I wish the commit message contained the command line with arguments, rather than the less descriptive \"git-annex in Toshiba USB HDD\").
+Using `git show` and `git cat-file` I managed to determine the following:
+
+March 4: the initial version of the file was committed.
+
+May 17 11:51: the file's content changed to `../../../../../../../../../media/TOSHIBA EXT/annex/.git/annex/objects/kx/3W/SHA256E-s96418--c6164e17d88914b2e6781e2cb8e7b91e9669ddf2d9ee6f5cbb17f3212bccfba4.jpg/SHA256E-s96418--c6164e17d88914b2e6781e2cb8e7b91e9669ddf2d9ee6f5cbb17f3212bccfba4.jpg`. This is blob `../.git/annex/objects/4z/gf/SHA256E-s245--ae647e7ad31089255413a9290ca9344542f3cd15ecef66884613bf776387633d.jpg/SHA256E-s245--ae647e7ad31089255413a9290ca9344542f3cd15ecef66884613bf776387633d.jpg`.
+
+May 17 12:22 the file's content changed again to `../../../../../../../../../media/TOSHIBA EXT/annex/.git/annex/objects/4z/gf/SHA256E-s245--ae647e7ad31089255413a9290ca9344542f3cd15ecef66884613bf776387633d.jpg/SHA256E-s245--ae647e7ad31089255413a9290ca9344542f3cd15ecef66884613bf776387633d.jpg`, i.e., a reference to the previous object. This is blob `../.git/annex/objects/ZQ/WF/SHA256E-s241--f3d7e5d1f788235b8eec0af58cc0c526b112b9e834a47ba7a475876c49dce343.jpg/SHA256E-s241--f3d7e5d1f788235b8eec0af58cc0c526b112b9e834a47ba7a475876c49dce343.jpg`.
+
+What else can I do in order to work out what went wrong? Is having concurrent commands manipulating the same repository a bad idea?
+"""]]

Added a comment: Freenet Special Remote
diff --git a/doc/todo/wishlist__58___spec.remotes_for_other_peer_network_data_stores___40__gnunet__44___freenet__41__/comment_5_0c40bb64126957a25ec1b20dc856529c._comment b/doc/todo/wishlist__58___spec.remotes_for_other_peer_network_data_stores___40__gnunet__44___freenet__41__/comment_5_0c40bb64126957a25ec1b20dc856529c._comment
new file mode 100644
index 0000000..f345043
--- /dev/null
+++ b/doc/todo/wishlist__58___spec.remotes_for_other_peer_network_data_stores___40__gnunet__44___freenet__41__/comment_5_0c40bb64126957a25ec1b20dc856529c._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="xloem"
+ subject="Freenet Special Remote"
+ date="2016-05-19T03:02:18Z"
+ content="""
+The freenet external special remote at https://github.com/xloem/gitlakepy is working now.
+
+No bells and whistles, but you can install it and start git-annex copy --to=freenet and git-annex get --from=freenet .
+"""]]

Added a comment
diff --git a/doc/bugs/broken_repo_when_inodes_exhausted/comment_2_4c6ced0d3163735c7f4bd5a4a7053159._comment b/doc/bugs/broken_repo_when_inodes_exhausted/comment_2_4c6ced0d3163735c7f4bd5a4a7053159._comment
new file mode 100644
index 0000000..270968b
--- /dev/null
+++ b/doc/bugs/broken_repo_when_inodes_exhausted/comment_2_4c6ced0d3163735c7f4bd5a4a7053159._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="xloem"
+ subject="comment 2"
+ date="2016-05-18T09:43:13Z"
+ content="""
+Thanks.  It turns out I'd deleted that repo in order to free the inodes up.  Next time I will see if I can repair.
+
+But it would be nice if git-annex tracked inodes the way it tracks free space, so that it could refrain from causing the inode exhaustion.  This also would have alerted me to how few inodes I had remaining.
+"""]]

Added a comment: dangling objects
diff --git a/doc/devblog/day_392__v6_fixes/comment_1_6da0787fa9749ee2d1f91842f10a5d3c._comment b/doc/devblog/day_392__v6_fixes/comment_1_6da0787fa9749ee2d1f91842f10a5d3c._comment
new file mode 100644
index 0000000..a123937
--- /dev/null
+++ b/doc/devblog/day_392__v6_fixes/comment_1_6da0787fa9749ee2d1f91842f10a5d3c._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="xloem"
+ subject="dangling objects"
+ date="2016-05-18T01:49:11Z"
+ content="""
+My repos have accumulated thousands of dangling objects recently (every one).  I'm wondering, would this issue be resolved with the syncing fix?  If so, should the objects just be deleted?
+"""]]

response
diff --git a/doc/forum/What_am_I_doing_wrong_with_move__63__/comment_1_a49d98426ef8dd17e6cca6b5fba5c9bf._comment b/doc/forum/What_am_I_doing_wrong_with_move__63__/comment_1_a49d98426ef8dd17e6cca6b5fba5c9bf._comment
new file mode 100644
index 0000000..d1c96f4
--- /dev/null
+++ b/doc/forum/What_am_I_doing_wrong_with_move__63__/comment_1_a49d98426ef8dd17e6cca6b5fba5c9bf._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-05-17T18:04:53Z"
+ content="""
+It sounds like the symlink in the git repository has been changed to point
+to some other content that the content it had originally. Since git tracks
+past versions of files, you should be able to use `git log` on the file to
+find out when this hapened and you can use `git checkout` to check out the
+original version of the file, or `git revert` the commit that changed it to
+point to the wrong content. The content of the file should still be stored
+in the git annex, so you should be able to access it this way.
+
+Now, it kind of sounds like something added the git-annex link for a
+file, as it would appear on the FAT filesytem, to git-annex as the new 
+content of the file. It would certianly be a bug if a git-annex command
+did that.
+
+What does `git annex info` (with no other parameters) report when you run it in the repository on
+the USB drive? What filesystem is in use on the USB drive?
+"""]]

followup
diff --git a/doc/bugs/Whereis_reports_same_UUID_multiple_times/comment_1_4af19e393212aa5cd5b64c3bb81e8268._comment b/doc/bugs/Whereis_reports_same_UUID_multiple_times/comment_1_4af19e393212aa5cd5b64c3bb81e8268._comment
new file mode 100644
index 0000000..6113323
--- /dev/null
+++ b/doc/bugs/Whereis_reports_same_UUID_multiple_times/comment_1_4af19e393212aa5cd5b64c3bb81e8268._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-05-17T17:51:11Z"
+ content="""
+This is quite odd. Normally, multiple instances of the same UUID can occur
+but will get compacted down to 1.
+
+That it only lists the remote name/description for one instance of the UUID
+is probably a clue to whatever the problem is.
+
+Can you paste the output of this command: `git show git-annex:uuid.log`
+
+(It would be very helpful if I could get access to a clone of the git-annex
+branch of your repository.)
+"""]]

diff --git a/doc/forum/What_am_I_doing_wrong_with_move__63__.mdwn b/doc/forum/What_am_I_doing_wrong_with_move__63__.mdwn
new file mode 100644
index 0000000..0bf0980
--- /dev/null
+++ b/doc/forum/What_am_I_doing_wrong_with_move__63__.mdwn
@@ -0,0 +1,48 @@
+I still have little experience with git-annex, so I may be missing something fairly obvious.
+
+I have been moving files between two repositories. Things *seemed* to be going well, but today I noticed that I was missing some content that I have just moved. I would like some help to figure out where I went wrong to avoid doing worse mistakes in the future.
+
+What I did was to run the command `git-annex move --from=toshiba` to move a bunch of files from my USB unit to my current repository and then I ran `git-annex sync` on both ends. Afterwards I noticed that the content of the files was not available, so I tried to track one of them.
+What I could see in my local indirect repository was a broken symbolic link pointing to `../.git/annex/objects/ZQ/WF/SHA256E-s241--f3d7e5d1f788235b8eec0af58cc0c526b112b9e834a47ba7a475876c49dce343.jpg/SHA256E-s241--f3d7e5d1f788235b8eec0af58cc0c526b112b9e834a47ba7a475876c49dce343.jpg`.
+
+`git-annex info` gave me similar information:
+
+    file: Heavy Metal 1981.jpg
+    size: 241 bytes
+    key: SHA256E-s241--f3d7e5d1f788235b8eec0af58cc0c526b112b9e834a47ba7a475876c49dce343.jpg
+
+`git-annex whereis` locates the file still on its origin:
+
+    whereis Heavy Metal 1981.jpg (1 copy) 
+  	    49b5b3a4-56ac-4cf2-aed9-1c23d3181c97 -- Toshiba USB HDD [toshiba]
+    ok
+
+On my external HDD drive, where I have an indirect mode repository, the file has already been replaced by a reference (241 bytes).
+
+    $ cat "Heavy Metal 1981.jpg"
+    ../../../../../../../../../media/TOSHIBA EXT/annex/.git/annex/objects/4z/gf/SHA256E-s245--ae647e7ad31089255413a9290ca9344542f3cd15ecef66884613bf776387633d.jpg/SHA256E-s245--ae647e7ad31089255413a9290ca9344542f3cd15ecef66884613bf776387633d.jpg
+
+`git-annex log` remembers something about the operation:
+
+    + Tue, 17 May 2016 12:22:43 WEST Heavy Metal 1981.jpg | 49b5b3a4-56ac-4cf2-aed9-1c23d3181c97 -- Toshiba USB HDD [toshiba]
+
+I tried to `git-annex get "Heavy Metal 1981.jpg"`, and now I have a working symlink on my PC. However it does not point to the image, but to the same 241 bytes reference file that I have on my external HDD.
+
+`git-annex whereis` now mentions 2 locations to my file, but none of the working dirs holds its contents. So, where are the contents of the file? Lost somewhere? It appears that git-annex took the indirect mode reference file and took it for the real file contents -- and that is not good.
+
+I looked at the output of `git-annex unused`, cross-referenced with `git log --stat -S` and I managed to find it somewhere in the list of unused files in my PC's repository, but not on the external drive.
+
+Still, at this point I'm a little worried. I would like to understand what I could have done to cause this mess. Also, how I can clean it up (the rest of the files remain as broken links at the moment).
+
+I have a couple more drives I wanted to add to this setup, but you can understand that I hesitate a little bit at the moment. Maybe I have "lost" more data than I realize.
+
+The version details:
+
+    git-annex version: 6.20160511
+    build flags: Assistant Webapp Pairing Testsuite S3(multipartupload)(storageclasses) WebDAV Inotify DBus DesktopNotify XMPP ConcurrentOutput TorrentParser MagicMime Feeds Quvi
+    key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 SHA1E SHA1 MD5E 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 versions: 5 6
+    upgrade supported from repository versions: 0 1 2 4 5
+    operating system: linux x86_64

diff --git a/doc/bugs/Whereis_reports_same_UUID_multiple_times.mdwn b/doc/bugs/Whereis_reports_same_UUID_multiple_times.mdwn
index 87c8865..baeea5e 100644
--- a/doc/bugs/Whereis_reports_same_UUID_multiple_times.mdwn
+++ b/doc/bugs/Whereis_reports_same_UUID_multiple_times.mdwn
@@ -29,7 +29,7 @@ ok
 For another file:
 
 ```
-whereis FerieKonto_privat_Ansoegning+om+uhaevede+feriepenge_ferieaar2010_2011.ps                                                                                                                                                              (44 copies)
+whereis file2 (44 copies)
         0866153a-19e5-4382-aeb6-30e8210706cc
         0866153a-19e5-4382-aeb6-30e8210706cc
         0866153a-19e5-4382-aeb6-30e8210706cc

diff --git a/doc/bugs/Whereis_reports_same_UUID_multiple_times.mdwn b/doc/bugs/Whereis_reports_same_UUID_multiple_times.mdwn
new file mode 100644
index 0000000..87c8865
--- /dev/null
+++ b/doc/bugs/Whereis_reports_same_UUID_multiple_times.mdwn
@@ -0,0 +1,94 @@
+### Please describe the problem.
+`git annex whereis` reports the same UUID multiple times, for example for one file:
+
+```
+whereis file1 (20 copies)
+        0866153a-19e5-4382-aeb6-30e8210706cc
+        0866153a-19e5-4382-aeb6-30e8210706cc
+        0866153a-19e5-4382-aeb6-30e8210706cc
+        0866153a-19e5-4382-aeb6-30e8210706cc
+        0dc538bf-5015-474a-965b-f59a678c2606
+        0dc538bf-5015-474a-965b-f59a678c2606
+        0dc538bf-5015-474a-965b-f59a678c2606
+        0dc538bf-5015-474a-965b-f59a678c2606
+        42c9b8ae-7fe5-452c-8965-146077b567fc
+        42c9b8ae-7fe5-452c-8965-146077b567fc
+        42c9b8ae-7fe5-452c-8965-146077b567fc
+        42c9b8ae-7fe5-452c-8965-146077b567fc
+        99f82d90-85a1-498e-a149-b5d21a0c4540
+        99f82d90-85a1-498e-a149-b5d21a0c4540
+        99f82d90-85a1-498e-a149-b5d21a0c4540
+        99f82d90-85a1-498e-a149-b5d21a0c4540
+        9b4679b3-95dd-4e20-8349-7a9ed4d9ff6a
+        9b4679b3-95dd-4e20-8349-7a9ed4d9ff6a
+        9b4679b3-95dd-4e20-8349-7a9ed4d9ff6a
+        9b4679b3-95dd-4e20-8349-7a9ed4d9ff6a
+ok
+```
+
+For another file:
+
+```
+whereis FerieKonto_privat_Ansoegning+om+uhaevede+feriepenge_ferieaar2010_2011.ps                                                                                                                                                              (44 copies)
+        0866153a-19e5-4382-aeb6-30e8210706cc
+        0866153a-19e5-4382-aeb6-30e8210706cc
+        0866153a-19e5-4382-aeb6-30e8210706cc
+        0866153a-19e5-4382-aeb6-30e8210706cc
+        0dc538bf-5015-474a-965b-f59a678c2606
+        0dc538bf-5015-474a-965b-f59a678c2606
+        42c9b8ae-7fe5-452c-8965-146077b567fc
+        42c9b8ae-7fe5-452c-8965-146077b567fc
+        42c9b8ae-7fe5-452c-8965-146077b567fc
+        42c9b8ae-7fe5-452c-8965-146077b567fc
+        57c272a3-4146-4796-8c4d-349725e11153
+        57c272a3-4146-4796-8c4d-349725e11153
+        57c272a3-4146-4796-8c4d-349725e11153
+        57c272a3-4146-4796-8c4d-349725e11153
+        6edd8523-6321-4d60-ada1-364489093075
+        6edd8523-6321-4d60-ada1-364489093075
+        6edd8523-6321-4d60-ada1-364489093075
+        6edd8523-6321-4d60-ada1-364489093075
+        8ca47082-542f-4935-bd4d-71b3d8071f97
+        8ca47082-542f-4935-bd4d-71b3d8071f97
+        8ca47082-542f-4935-bd4d-71b3d8071f97
+        8ca47082-542f-4935-bd4d-71b3d8071f97
+        99c9cb4b-3d7d-406b-b68d-c30b62072d25
+        99c9cb4b-3d7d-406b-b68d-c30b62072d25
+        99c9cb4b-3d7d-406b-b68d-c30b62072d25
+        99c9cb4b-3d7d-406b-b68d-c30b62072d25
+        99f82d90-85a1-498e-a149-b5d21a0c4540
+        99f82d90-85a1-498e-a149-b5d21a0c4540
+        99f82d90-85a1-498e-a149-b5d21a0c4540
+        99f82d90-85a1-498e-a149-b5d21a0c4540
+        9b4679b3-95dd-4e20-8349-7a9ed4d9ff6a -- repo1
+        9b4679b3-95dd-4e20-8349-7a9ed4d9ff6a
+        9b4679b3-95dd-4e20-8349-7a9ed4d9ff6a
+        9b4679b3-95dd-4e20-8349-7a9ed4d9ff6a
+        9b4679b3-95dd-4e20-8349-7a9ed4d9ff6a
+        9e5cb42d-7a5a-4a99-b176-f0980d9b7265
+        9e5cb42d-7a5a-4a99-b176-f0980d9b7265
+        9e5cb42d-7a5a-4a99-b176-f0980d9b7265
+        9e5cb42d-7a5a-4a99-b176-f0980d9b7265
+        b1e180f9-3a47-4178-a360-043e731a4f5b -- local_repo [here]
+        b5472406-01a1-4cd8-a5b4-bb3d914264d2
+        b5472406-01a1-4cd8-a5b4-bb3d914264d2
+        b5472406-01a1-4cd8-a5b4-bb3d914264d2
+        b5472406-01a1-4cd8-a5b4-bb3d914264d2
+ok
+```
+
+Furthermore as can be seen it doesn't even recognise that I have added repo1 as a remote for file1, actually several other of the repositories are available as remotes but git annex doesn't recognise them.
+
+I have tried deleting the repository and cloning it again on windows, but that just seemed to create even more UUID repeats. So right now I am a bit vary of trying anything out on Windows on the repository.
+
+I have tried running `git annex repair` on Linux and it reported no problems, even though it also shows repeated UUIDs if I run `git annex whereis`.
+
+### What version of git-annex are you using? On what operating system?
+
+I am running "git-annex version: 6.20160511-g4633f0b" on Windows, but I have been having troubles with this for some time, though only on Windows.
+
+### Please provide any additional information below.
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+Yes it is working very nicely on all my linux computers, and right now I am mostly concerned that I might have messed up the repository by trying out Windows :-(.
+

Added a comment: Restarting
diff --git a/doc/forum/Simple_question_about_web_remote/comment_4_510abbb4deca924020b87f1eb7d61005._comment b/doc/forum/Simple_question_about_web_remote/comment_4_510abbb4deca924020b87f1eb7d61005._comment
new file mode 100644
index 0000000..a44d75d
--- /dev/null
+++ b/doc/forum/Simple_question_about_web_remote/comment_4_510abbb4deca924020b87f1eb7d61005._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="Gus"
+ subject="Restarting"
+ date="2016-05-17T10:36:55Z"
+ content="""
+My attempt to redo the podcast repository adding the `--fast` flag seems to be successful. Thank you.
+
+However, I would still like to ask you one thing about the delete operations.
+When would you use `git rm` instead of `git-annex drop` (in a repository that uses only git-annex to store the files)?
+
+Oh, and I'll also sneak in a small question that is unrelated to the above, since I don't think it deserves its own topic:
+Is git-annex safe to operate in parallel tasks? Can I be adding file A and move file B and rename file C from the same repository at the same time, without the integrity of the repository being compromised?
+
+
+"""]]

Added a comment
diff --git a/doc/forum/__34__git_annex_assistant_--stop__34___doesn__39__t_work_in_OSX_10.11.4/comment_6_46eb0f4dcbccea5140a26dca36c6f1d1._comment b/doc/forum/__34__git_annex_assistant_--stop__34___doesn__39__t_work_in_OSX_10.11.4/comment_6_46eb0f4dcbccea5140a26dca36c6f1d1._comment
new file mode 100644
index 0000000..97caaaf
--- /dev/null
+++ b/doc/forum/__34__git_annex_assistant_--stop__34___doesn__39__t_work_in_OSX_10.11.4/comment_6_46eb0f4dcbccea5140a26dca36c6f1d1._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="openmedi"
+ subject="comment 6"
+ date="2016-05-16T23:11:34Z"
+ content="""
+I did assume so, because b2s process seems to be running when the assistant fails to shut down. But a new, maybe related problem might have come to light: I have/had a gitlab remote, that grew so big (30 gig) that they shut it down, in the sense that I can't access it anymore (even reading from it seems to have stoped working). I believe that this gitlab remote has some objects that aren't available anymore and git annex seems to try to repair stuff that is not repairable. As always: This is all said with a big \"maybe\", since I wouldn't know how to test my repo against that hypothesis. I have now done `git annex untrust gitlab` and will try if that helps. All this seem very mysterious to me, since I can't believe that I failed remote should prevent the repo to find an acceptable state.
+
+- git annex fsck states that there are 60 failed files (\"Only 1 of 2 trustworthy copies exist of…\" for all of them as far as I can see in the log)
+- git annex version 6.20160418  installed through homebrew
+- git annex repo version is 6
+"""]]

comment
diff --git a/doc/special_remotes/directory/comment_16_32f6695042fe1f6e40a64a785fab59b9._comment b/doc/special_remotes/directory/comment_16_32f6695042fe1f6e40a64a785fab59b9._comment
new file mode 100644
index 0000000..0df6a87
--- /dev/null
+++ b/doc/special_remotes/directory/comment_16_32f6695042fe1f6e40a64a785fab59b9._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 16"""
+ date="2016-05-16T21:31:43Z"
+ content="""
+@aslkdjasd this layout is the same as used for .git/annex/objects
+in the local repository. 
+
+This allows the FILEKEY directory to have its write bit removed.
+This prevents an accidental rm -rf from losing the contents of 
+annexed files. Since that might be the only copy of a file,
+git-annex adds this extra protection.
+"""]]

comment
diff --git a/doc/devblog/day_392__v6_fixes.mdwn b/doc/devblog/day_392__v6_fixes.mdwn
new file mode 100644
index 0000000..10d2de2
--- /dev/null
+++ b/doc/devblog/day_392__v6_fixes.mdwn
@@ -0,0 +1,12 @@
+Fixed several problems with v6 mode today. The assistant was doing some
+pretty wrong things when changes were synced into v6 repos, and that
+behavior is fixed. Also dealt with a race that caused updates made to the
+keys database by one process to not be seen by another process.
+And, made `git annex add` of a unlocked pointer file not annex the pointer
+file's content, but just add it to git as-is.
+
+Also, Thowz pointed out that adjusted branches could be used to locally adjust
+where annex symlinks point to, when a repository's git directory is not in
+the usual location. I've added that, as `git annex adjust --fix`. It
+was quite easy to implement this, which makes me very happy with the
+adjusted branches code!
diff --git a/doc/forum/__34__git_annex_assistant_--stop__34___doesn__39__t_work_in_OSX_10.11.4/comment_5_5cb379490b0e85c24bff48db8201c7d4._comment b/doc/forum/__34__git_annex_assistant_--stop__34___doesn__39__t_work_in_OSX_10.11.4/comment_5_5cb379490b0e85c24bff48db8201c7d4._comment
new file mode 100644
index 0000000..2bf5237
--- /dev/null
+++ b/doc/forum/__34__git_annex_assistant_--stop__34___doesn__39__t_work_in_OSX_10.11.4/comment_5_5cb379490b0e85c24bff48db8201c7d4._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2016-05-16T21:23:09Z"
+ content="""
+Why do you think that the b2 special remote is causing the problem?
+
+(Seems unlikely to me..)
+"""]]

adjust: Add --fix adjustment, which is useful when the git directory is in a nonstandard place.
diff --git a/Annex/AdjustedBranch.hs b/Annex/AdjustedBranch.hs
index bebb5c7..a61df7d 100644
--- a/Annex/AdjustedBranch.hs
+++ b/Annex/AdjustedBranch.hs
@@ -57,6 +57,8 @@ import qualified Data.Map as M
 data Adjustment
 	= UnlockAdjustment
 	| LockAdjustment
+	| FixAdjustment
+	| UnFixAdjustment
 	| HideMissingAdjustment
 	| ShowMissingAdjustment
 	deriving (Show, Eq)
@@ -66,32 +68,16 @@ reverseAdjustment UnlockAdjustment = LockAdjustment
 reverseAdjustment LockAdjustment = UnlockAdjustment
 reverseAdjustment HideMissingAdjustment = ShowMissingAdjustment
 reverseAdjustment ShowMissingAdjustment = HideMissingAdjustment
+reverseAdjustment FixAdjustment = UnFixAdjustment
+reverseAdjustment UnFixAdjustment = FixAdjustment
 
 {- How to perform various adjustments to a TreeItem. -}
 adjustTreeItem :: Adjustment -> TreeItem -> Annex (Maybe TreeItem)
-adjustTreeItem UnlockAdjustment ti@(TreeItem f m s)
-	| toBlobType m == Just SymlinkBlob = do
-		mk <- catKey s
-		case mk of
-			Just k -> do
-				Database.Keys.addAssociatedFile k f
-				Just . TreeItem f (fromBlobType FileBlob)
-					<$> hashPointerFile k
-			Nothing -> return (Just ti)
-	| otherwise = return (Just ti)
-adjustTreeItem LockAdjustment ti@(TreeItem f m s)
-	| toBlobType m /= Just SymlinkBlob = do
-		mk <- catKey s
-		case mk of
-			Just k -> do
-				absf <- inRepo $ \r -> absPath $
-					fromTopFilePath f r
-				linktarget <- calcRepo $ gitAnnexLink absf k
-				Just . TreeItem f (fromBlobType SymlinkBlob)
-					<$> hashSymlink linktarget
-			Nothing -> return (Just ti)
-	| otherwise = return (Just ti)
-adjustTreeItem HideMissingAdjustment ti@(TreeItem _ _ s) = do
+adjustTreeItem UnlockAdjustment = ifSymlink adjustToPointer noAdjust
+adjustTreeItem LockAdjustment = ifSymlink noAdjust adjustToSymlink
+adjustTreeItem FixAdjustment = ifSymlink adjustToSymlink noAdjust
+adjustTreeItem UnFixAdjustment = ifSymlink (adjustToSymlink' gitAnnexLinkCanonical) noAdjust
+adjustTreeItem HideMissingAdjustment = \ti@(TreeItem _ _ s) -> do
 	mk <- catKey s
 	case mk of
 		Just k -> ifM (inAnnex k)
@@ -99,7 +85,40 @@ adjustTreeItem HideMissingAdjustment ti@(TreeItem _ _ s) = do
 			, return Nothing
 			)
 		Nothing -> return (Just ti)
-adjustTreeItem ShowMissingAdjustment ti = return (Just ti)
+adjustTreeItem ShowMissingAdjustment = noAdjust
+
+ifSymlink :: (TreeItem -> Annex a) -> (TreeItem -> Annex a) -> TreeItem -> Annex a
+ifSymlink issymlink notsymlink ti@(TreeItem _f m _s)
+	| toBlobType m == Just SymlinkBlob = issymlink ti
+	| otherwise = notsymlink ti
+
+noAdjust :: TreeItem -> Annex (Maybe TreeItem)
+noAdjust = return . Just
+
+adjustToPointer :: TreeItem -> Annex (Maybe TreeItem)
+adjustToPointer ti@(TreeItem f _m s) = do
+	mk <- catKey s
+	case mk of
+		Just k -> do
+			Database.Keys.addAssociatedFile k f
+			Just . TreeItem f (fromBlobType FileBlob)
+				<$> hashPointerFile k
+		Nothing -> return (Just ti)
+
+adjustToSymlink :: TreeItem -> Annex (Maybe TreeItem)
+adjustToSymlink = adjustToSymlink' gitAnnexLink
+
+adjustToSymlink' :: (FilePath -> Key -> Git.Repo -> GitConfig -> IO FilePath) -> TreeItem -> Annex (Maybe TreeItem)
+adjustToSymlink' gitannexlink ti@(TreeItem f _m s) = do
+	mk <- catKey s
+	case mk of
+		Just k -> do
+			absf <- inRepo $ \r -> absPath $
+				fromTopFilePath f r
+			linktarget <- calcRepo $ gitannexlink absf k
+			Just . TreeItem f (fromBlobType SymlinkBlob)
+				<$> hashSymlink linktarget
+		Nothing -> return (Just ti)
 
 type OrigBranch = Branch
 newtype AdjBranch = AdjBranch { adjBranch :: Branch }
@@ -123,11 +142,15 @@ serialize UnlockAdjustment = "unlocked"
 serialize LockAdjustment = "locked"
 serialize HideMissingAdjustment = "present"
 serialize ShowMissingAdjustment = "showmissing"
+serialize FixAdjustment = "fixed"
+serialize UnFixAdjustment = "unfixed"
 
 deserialize :: String -> Maybe Adjustment
 deserialize "unlocked" = Just UnlockAdjustment
 deserialize "locked" = Just UnlockAdjustment
 deserialize "present" = Just HideMissingAdjustment
+deserialize "fixed" = Just FixAdjustment
+deserialize "unfixed" = Just UnFixAdjustment
 deserialize _ = Nothing
 
 originalToAdjusted :: OrigBranch -> Adjustment -> AdjBranch
diff --git a/Annex/Locations.hs b/Annex/Locations.hs
index bdd603d..a195606 100644
--- a/Annex/Locations.hs
+++ b/Annex/Locations.hs
@@ -15,6 +15,7 @@ module Annex.Locations (
 	gitAnnexLocation,
 	gitAnnexLocationDepth,
 	gitAnnexLink,
+	gitAnnexLinkCanonical,
 	gitAnnexContentLock,
 	gitAnnexMapping,
 	gitAnnexInodeCache,
@@ -80,6 +81,7 @@ import Types.UUID
 import Types.GitConfig
 import Types.Difference
 import qualified Git
+import qualified Git.Types as Git
 import Git.FilePath
 import Annex.DirHashes
 import Annex.Fixup
@@ -182,6 +184,20 @@ gitAnnexLink file key r config = do
 		| otherwise = Git.localGitDir r
 	whoops = error $ "unable to normalize " ++ file
 
+{- Calculates a symlink target as would be used in a typical git
+ - repository, with .git in the top of the work tree. -}
+gitAnnexLinkCanonical :: FilePath -> Key -> Git.Repo -> GitConfig -> IO FilePath
+gitAnnexLinkCanonical file key r config = gitAnnexLink file key r' config'
+  where
+	r' = case r of
+		Git.Repo { Git.location = l@Git.Local { Git.worktree = Just wt } } ->
+			r { Git.location = l { Git.gitdir = wt </> ".git" } }
+		_ -> r
+	config' = config
+		{ annexCrippledFileSystem = False
+		, coreSymlinks = True
+		}
+
 {- File used to lock a key's content. -}
 gitAnnexContentLock :: Key -> Git.Repo -> GitConfig -> IO FilePath
 gitAnnexContentLock key r config = do
diff --git a/Command/Adjust.hs b/Command/Adjust.hs
index 8c62c14..204fd05 100644
--- a/Command/Adjust.hs
+++ b/Command/Adjust.hs
@@ -21,6 +21,10 @@ optParser _ =
 		( long "unlock"
 		<> help "unlock annexed files"
 		)
+	<|> flag' FixAdjustment
+		( long "fix"
+		<> help "fix symlinks to annnexed files"
+		)
 	{- Not ready yet
 	<|> flag' HideMissingAdjustment
 		( long "hide-missing"
diff --git a/debian/changelog b/debian/changelog
index 1002dd0..24c1105 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -13,6 +13,8 @@ git-annex (6.20160512) UNRELEASED; urgency=medium
   * add: Adding a v6 pointer file used to annex it; now the pointer file is
     added to git as-is. (git add of a pointer file already did the right
     thing)
+  * adjust: Add --fix adjustment, which is useful when the git directory
+    is in a nonstandard place.
 
  -- Joey Hess <id@joeyh.name>  Wed, 11 May 2016 16:08:38 -0400
 
diff --git a/doc/bugs/git-annex_confuses_Git_with_nested_submodules/comment_6_11528378e8c509940190cf84db7ed3d6._comment b/doc/bugs/git-annex_confuses_Git_with_nested_submodules/comment_6_11528378e8c509940190cf84db7ed3d6._comment
new file mode 100644
index 0000000..a636281
--- /dev/null
+++ b/doc/bugs/git-annex_confuses_Git_with_nested_submodules/comment_6_11528378e8c509940190cf84db7ed3d6._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 6"""
+ date="2016-05-16T20:14:57Z"
+ content="""
+I hope this will be fixed on the git side, but I don't know when it will
+be. Probably comes down to someone developing a patch.
+
+Occurs to me that git-annex could use adjusted branches to deal with this.
+When initializing in a submodule, it could enter an adjusted branch with
+`git annex adjust --fix`. This way, symlinks would be re-written to point
+to the submodule's git repository. The .git dotfile would not need to be
+converted to a symlink at all.
+"""]]

(Diff truncated)
assistant: Fix bug that caused v6 pointer files to be annexed by the assistant.
diff --git a/Assistant/Threads/Watcher.hs b/Assistant/Threads/Watcher.hs
index 1a3acbb..1f50065 100644
--- a/Assistant/Threads/Watcher.hs
+++ b/Assistant/Threads/Watcher.hs
@@ -221,7 +221,11 @@ shouldRestage :: DaemonStatus -> Bool
 shouldRestage ds = scanComplete ds || forceRestage ds
 
 onAddUnlocked :: Bool -> GetFileMatcher -> Handler
-onAddUnlocked = onAddUnlocked' False contentchanged addassociatedfile addlink samefilestatus
+onAddUnlocked symlinkssupported matcher f fs = do
+	mk <- liftIO $ isPointerFile f
+	case mk of
+		Nothing -> onAddUnlocked' False contentchanged addassociatedfile addlink samefilestatus symlinkssupported matcher f fs
+		Just k -> addlink f k
   where
 	addassociatedfile key file = 
 		Database.Keys.addAssociatedFile key
diff --git a/debian/changelog b/debian/changelog
index a653efd..af54ed5 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -6,6 +6,8 @@ git-annex (6.20160512) UNRELEASED; urgency=medium
   * adjust: If the adjusted branch already exists, avoid overwriting it,
     since it might contain changes that have not yet been propigated to the
     original branch.
+  * assistant: Fix bug that caused v6 pointer files to be annexed by the
+    assistant.
 
  -- Joey Hess <id@joeyh.name>  Wed, 11 May 2016 16:08:38 -0400
 
diff --git a/doc/bugs/Central_annex_+_assistant_+_v6___61___weirdness__63__.mdwn b/doc/bugs/Central_annex_+_assistant_+_v6___61___weirdness__63__.mdwn
index 5afd3d3..4acf81e 100644
--- a/doc/bugs/Central_annex_+_assistant_+_v6___61___weirdness__63__.mdwn
+++ b/doc/bugs/Central_annex_+_assistant_+_v6___61___weirdness__63__.mdwn
@@ -102,3 +102,5 @@ Everything up-to-date
 
 ### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
 It seems to work really well on v5, but the v6 file "corruption" is difficult to recover from.
+
+> [[fixed|done]] --[[Joey]]

Added a comment
diff --git a/doc/news/version_6.20160511/comment_1_c7ad57b324c94d0a3eb00b9d624f7b66._comment b/doc/news/version_6.20160511/comment_1_c7ad57b324c94d0a3eb00b9d624f7b66._comment
new file mode 100644
index 0000000..a48431d
--- /dev/null
+++ b/doc/news/version_6.20160511/comment_1_c7ad57b324c94d0a3eb00b9d624f7b66._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="CandyAngel"
+ subject="comment 1"
+ date="2016-05-16T11:41:08Z"
+ content="""
+I've very happy to report that the git-add, git-annex-fsck & 'git-annex-reinject --known' workflow is working great!
+
+Thank you for adding these :)
+"""]]

Added a comment: timings
diff --git a/doc/forum/performance_for_FTP_site_mirroring/comment_3_cb4d7b283f20b43283036f20ebc648ec._comment b/doc/forum/performance_for_FTP_site_mirroring/comment_3_cb4d7b283f20b43283036f20ebc648ec._comment
new file mode 100644
index 0000000..36b1595
--- /dev/null
+++ b/doc/forum/performance_for_FTP_site_mirroring/comment_3_cb4d7b283f20b43283036f20ebc648ec._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="midfield"
+ subject="timings"
+ date="2016-05-15T19:58:37Z"
+ content="""
+for what it's worth, even with your suggestions i was unable to make git commit work quickly (it takes over an hour for the initial commit.  it only takes 4 minutes to copy the files themselves.)  thank you for the help though.
+"""]]

Added a comment
diff --git a/doc/forum/__34__git_annex_assistant_--stop__34___doesn__39__t_work_in_OSX_10.11.4/comment_4_5bed42e467859d2310f3da35e55acd38._comment b/doc/forum/__34__git_annex_assistant_--stop__34___doesn__39__t_work_in_OSX_10.11.4/comment_4_5bed42e467859d2310f3da35e55acd38._comment
new file mode 100644
index 0000000..2036ad6
--- /dev/null
+++ b/doc/forum/__34__git_annex_assistant_--stop__34___doesn__39__t_work_in_OSX_10.11.4/comment_4_5bed42e467859d2310f3da35e55acd38._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="openmedi"
+ subject="comment 4"
+ date="2016-05-14T13:24:06Z"
+ content="""
+I assume now that the problem is related to the [b2 special remote](https://github.com/encryptio/git-annex-remote-b2) which might be preventing git annex from shutting down. I don't know. What should I do and post here to help you triage this problem?
+"""]]

Added a comment
diff --git a/doc/forum/Remote_in_webapp_shows_syncing_disabled_but_is_enabled___40__maybe__41__/comment_4_a8e68a41e069803d89f18d1645876298._comment b/doc/forum/Remote_in_webapp_shows_syncing_disabled_but_is_enabled___40__maybe__41__/comment_4_a8e68a41e069803d89f18d1645876298._comment
new file mode 100644
index 0000000..b303c3a
--- /dev/null
+++ b/doc/forum/Remote_in_webapp_shows_syncing_disabled_but_is_enabled___40__maybe__41__/comment_4_a8e68a41e069803d89f18d1645876298._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="openmedi"
+ subject="comment 4"
+ date="2016-05-14T13:21:04Z"
+ content="""
+Indeed it was a question of trust. Something that the assistant should notify me about. Maybe it should even be a setting in the assistant. No feedback here is just not a good idea.
+"""]]

Added a comment: The problem was path length
diff --git a/doc/forum/unable_to_clone_annex_repo_in_windows/comment_3_20aa8de2513fdb6b19a4b24f20983f0a._comment b/doc/forum/unable_to_clone_annex_repo_in_windows/comment_3_20aa8de2513fdb6b19a4b24f20983f0a._comment
new file mode 100644
index 0000000..e9e462b
--- /dev/null
+++ b/doc/forum/unable_to_clone_annex_repo_in_windows/comment_3_20aa8de2513fdb6b19a4b24f20983f0a._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="drunken_sapo"
+ subject="The problem was path length"
+ date="2016-05-14T13:11:35Z"
+ content="""
+After fixing my ssh key problem I was able to test it appropiately.
+The path to the .git directory of my repo is 41 characters long (/d/juan/develop/git/xxxxxx_xxxxx_xxxxxxxx), if we add the offending file name: .git\annex\objects\fca\de3\SHA256E-s1312136--a79e30c5121f7843f023abbd36b211a245385b952926760d55a07baf8da1b24d.png\
+which is 114 characters long, it adds up to 155 characters.
+Moving the repo to /d/xxxxxx_xxxxx_xxxxxxxx solved the problem.
+However, I need it to be on that path, because some other projects use this on a relative path.
+Is there any way to circumvent this issue?
+"""]]

Added a comment: layout reasoning
diff --git a/doc/special_remotes/directory/comment_15_3d091c87c1e4d1c086fb88ae21137a57._comment b/doc/special_remotes/directory/comment_15_3d091c87c1e4d1c086fb88ae21137a57._comment
new file mode 100644
index 0000000..7e4a082
--- /dev/null
+++ b/doc/special_remotes/directory/comment_15_3d091c87c1e4d1c086fb88ae21137a57._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="aslkdjasd@656d48eb766881455ee14c8cd4adabdd14aad892"
+ nickname="aslkdjasd"
+ subject="layout reasoning"
+ date="2016-05-14T01:23:42Z"
+ content="""
+@joeyh - trying to understand the purpose behind the layout for the directory and rsync remotes
+
+Format appears to be /BASE_DIR/xxx/yyy/FILEKEY/FILEKEY
+
+What's the purpose of the filekey directory? I.e. why have FILEKEY as both a directory and then a file of the same name inside that directory?
+"""]]