Recent changes to this wiki:

Added a comment
diff --git a/doc/forum/Fails_to_get_file_from_s3._How_to_recover__63__/comment_1_c769dcbb9d5f082d54b8a091a44c9de4._comment b/doc/forum/Fails_to_get_file_from_s3._How_to_recover__63__/comment_1_c769dcbb9d5f082d54b8a091a44c9de4._comment
new file mode 100644
index 0000000..51348f4
--- /dev/null
+++ b/doc/forum/Fails_to_get_file_from_s3._How_to_recover__63__/comment_1_c769dcbb9d5f082d54b8a091a44c9de4._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="annexuser"
+ subject="comment 1"
+ date="2016-04-30T17:30:18Z"
+ content="""
+This also happens with a second file in the same repo, although the download seems to complete on this one before the error. The file is about the same size.
+
+    gxg otherfile.tgz.gpg
+    get otherfile.tgz.gpg (from s3...)
+    100%         10.7MB/s 0sgpg: WARNING: encrypted message has been manipulated!
+
+      Unable to access these remotes: s3
+
+      Try making some of these repositories available:
+            15ac19e4-223a-4c81-b7f7-797b9b026b86 -- [s3]
+
+      (Note that these git remotes have annex-ignore set: origin)
+    failed
+    git-annex: get: 1 failed
+
+"""]]

diff --git a/doc/forum/Fails_to_get_file_from_s3._How_to_recover__63__.mdwn b/doc/forum/Fails_to_get_file_from_s3._How_to_recover__63__.mdwn
new file mode 100644
index 0000000..e6bfd4a
--- /dev/null
+++ b/doc/forum/Fails_to_get_file_from_s3._How_to_recover__63__.mdwn
@@ -0,0 +1,16 @@
+I have an annex that has an s3 special remote. The s3 remote has been configured with shared encryption and it uses partsize (not chunking). Currently when I try to get a file from the s3 remote, it fails:
+
+    $ git annex get mybigfile.tbz.gpg
+    get mybigfile.tbz.gpg (from s3...)
+    76%         10.6MB/s 57sgpg: WARNING: encrypted message has been manipulated!
+
+      Unable to access these remotes: s3
+
+      Try making some of these repositories available:
+            15ac19e4-223a-4c81-b7f7-797b9b026b86 -- [s3]
+
+      (Note that these git remotes have annex-ignore set: origin)
+    failed
+    git-annex: get: 1 failed
+
+The file is about 3GB. This happens consistently at 76%. No other copy of the file exists. Is there some way I can get the file from s3, either without git annex or just have git annex ignore the error, so that I can inspect the file locally and see if there is anything wrong with it?

Added a comment
diff --git a/doc/forum/Is_it_possible_to_create_a_view_on_files_that___42__dont__42___have_a_field_set__63__/comment_2_7373ec002ca78f4f382ef9297f39639e._comment b/doc/forum/Is_it_possible_to_create_a_view_on_files_that___42__dont__42___have_a_field_set__63__/comment_2_7373ec002ca78f4f382ef9297f39639e._comment
new file mode 100644
index 0000000..e8b2f29
--- /dev/null
+++ b/doc/forum/Is_it_possible_to_create_a_view_on_files_that___42__dont__42___have_a_field_set__63__/comment_2_7373ec002ca78f4f382ef9297f39639e._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="ollie@6d66b5a4b0992998efe3e4c244a66708bf5d96f3"
+ nickname="ollie"
+ subject="comment 2"
+ date="2016-04-29T15:04:17Z"
+ content="""
+Thanks! That will do the job :)
+"""]]

diff --git a/doc/bugs/dropkey_--batch_--json_--force_is_always_succesfull.mdwn b/doc/bugs/dropkey_--batch_--json_--force_is_always_succesfull.mdwn
new file mode 100644
index 0000000..01153fa
--- /dev/null
+++ b/doc/bugs/dropkey_--batch_--json_--force_is_always_succesfull.mdwn
@@ -0,0 +1,34 @@
+### Please describe the problem.
+
+just want to check if that is "by design"... --force was demanded seem operation is dangerous, but I expected that it would still report success false if key was not actually dropped, at least if a key is a completely wrong key
+
+so is that "by design" and I shouldn't care to check success field...?
+
+### What version of git-annex are you using? On what operating system?
+6.20160425+gitgffe2ea2-1~ndall+1
+
+### Please provide any additional information below.
+
+[[!format sh """
+
+$> echo MD5E-s11--74d80f7d99b835e5189948c8d4297efd | git annex dropkey --batch --json --force
+{"command":"dropkey","key":"MD5E-s11--74d80f7d99b835e5189948c8d4297efd","success":true}
+
+$> ls -l
+total 0
+0 lrwxrwxrwx 1 yoh yoh 110 Apr 29 09:21 124 -> .git/annex/objects/MV/Jw/MD5E-s11--74d80f7d99b835e5189948c8d4297efd/MD5E-s11--74d80f7d99b835e5189948c8d4297efd
+
+$> echo MD5E-s11--74d80f7d99b835e5189948c8d4297efd | git annex dropkey --batch --json --force
+{"command":"dropkey","key":"MD5E-s11--74d80f7d99b835e5189948c8d4297efd","success":true}
+
+$> echo MD5E-s11--74d80f7dsd99b835e5189948c8d4297efd | git annex dropkey --batch --json --force 
+{"command":"dropkey","key":"MD5E-s11--74d80f7dsd99b835e5189948c8d4297efd","success":true}
+
+$> echo MD5E-s11--74d80f7dsd99b835e5189948c8d4297efdsdfsdf | git annex dropkey --batch --json --force 
+{"command":"dropkey","key":"MD5E-s11--74d80f7dsd99b835e5189948c8d4297efdsdfsdf","success":true}
+
+
+"""]]
+
+[[!meta author=yoh]]
+

Added a comment
diff --git a/doc/bugs/annex_drop_is_not___34__in_effect__34___for_load_which_was___34__addurl_--batch__34__ed_but_not_yet_committed/comment_2_c6fa80900ca1683a78b5dbdf4affcc80._comment b/doc/bugs/annex_drop_is_not___34__in_effect__34___for_load_which_was___34__addurl_--batch__34__ed_but_not_yet_committed/comment_2_c6fa80900ca1683a78b5dbdf4affcc80._comment
new file mode 100644
index 0000000..30bdec4
--- /dev/null
+++ b/doc/bugs/annex_drop_is_not___34__in_effect__34___for_load_which_was___34__addurl_--batch__34__ed_but_not_yet_committed/comment_2_c6fa80900ca1683a78b5dbdf4affcc80._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://me.yahoo.com/a/EbvxpTI_xP9Aod7Mg4cwGhgjrCrdM5s-#7c0f4"
+ subject="comment 2"
+ date="2016-04-29T13:21:04Z"
+ content="""
+ok, so it is non-fixable reality due to having separate 'annex COMMAND --batch' processes (instead of a single annex --batch process which could accept/carry different COMMANDs with their parameters... I think we had discussion somewhere before).
+Ok -- I will workaround (actually for now I have worked around by collecting all files to be dropped and doing that after annex addurl process finishes, but dropkey --batch sounds better for this usecase)
+"""]]

Added a comment: Branching questions
diff --git a/doc/forum/Simple_question_about_web_remote/comment_2_274810bdc176984c056304e17668c63b._comment b/doc/forum/Simple_question_about_web_remote/comment_2_274810bdc176984c056304e17668c63b._comment
new file mode 100644
index 0000000..2e6db09
--- /dev/null
+++ b/doc/forum/Simple_question_about_web_remote/comment_2_274810bdc176984c056304e17668c63b._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="Gus"
+ subject="Branching questions"
+ date="2016-04-29T12:11:35Z"
+ content="""
+Thank you for your help. I would still like to ask a few related questions.
+
+1. I was unaware that RSS feeds provide a form of checksum. Are they stored as the filename? I still find it unlikely that the old file was changed in the few minutes between git-annex importing the feed and me asking for the file. However, maybe the file was changed, the feed was not updated and podcast downloading software are not as strict as git-annex.
+
+2. How should I proceed in order to update my podcasts. This is something I do not understand and I should play a bit with git-annex to figure out: there are multiple ways to remove files. As I understand it:
+  - I could `rm` the file. This removes the link. git still remembers the file and keeps it.
+  - I could `git rm` the file and commit. This could keep the file or remove it. git remembers the file's history and keeps its last state. However, in git-annex I am not sure what is kept in .git/. Can I re-add the file?
+  - I could `git-annex drop` the file. git-annex ensures the minimum number of copies, so this makes me believe that git totally forgets about the file (no last state copy). However, in the podcast tips you say that dropped files are not redownloaded. So this leaves me confused.
+
+I tried to `git rm -r` the podcast directory, and now I cannot importfeed it again. :-S Hmm... It is nothing important, but could you explain me what is going on, please?
+"""]]

Added a comment
diff --git a/doc/devblog/day_387__release_day/comment_1_3e48e930616917f6db1fc351d0f7e6df._comment b/doc/devblog/day_387__release_day/comment_1_3e48e930616917f6db1fc351d0f7e6df._comment
new file mode 100644
index 0000000..f345e64
--- /dev/null
+++ b/doc/devblog/day_387__release_day/comment_1_3e48e930616917f6db1fc351d0f7e6df._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://svario.it/gioele"
+ nickname="gioele"
+ subject="comment 1"
+ date="2016-04-29T10:26:22Z"
+ content="""
+> A bug made encrypted special remotes that are configured to use chunks accidentially expose the checksums of content that is uploaded to the remote. Such information is supposed to be hidden from the remote's view by the encryption.
+
+What should the users do to repair this situation? How can the exposed checksums be removed from the remote? Is a `git annex sync` enough?
+
+Thank you for the timely release!
+"""]]

Added a comment
diff --git a/doc/forum/Is_it_possible_to_create_a_view_on_files_that___42__dont__42___have_a_field_set__63__/comment_1_f452c911b24ba40aef3be5bdaac9f9ee._comment b/doc/forum/Is_it_possible_to_create_a_view_on_files_that___42__dont__42___have_a_field_set__63__/comment_1_f452c911b24ba40aef3be5bdaac9f9ee._comment
new file mode 100644
index 0000000..032811d
--- /dev/null
+++ b/doc/forum/Is_it_possible_to_create_a_view_on_files_that___42__dont__42___have_a_field_set__63__/comment_1_f452c911b24ba40aef3be5bdaac9f9ee._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="CandyAngel"
+ subject="comment 1"
+ date="2016-04-29T10:04:55Z"
+ content="""
+You can do this, but it involves setting that field's value to something.
+
+    git annex metadata -s field?=untagged
+
+This will tag all files that don't have any 'field' values with 'untagged', so when you switch to the view, they will show up under 'untagged' (and you move/commit them to tag them).
+"""]]

diff --git a/doc/forum/Is_it_possible_to_create_a_view_on_files_that___42__dont__42___have_a_field_set__63__.mdwn b/doc/forum/Is_it_possible_to_create_a_view_on_files_that___42__dont__42___have_a_field_set__63__.mdwn
new file mode 100644
index 0000000..1d19bf2
--- /dev/null
+++ b/doc/forum/Is_it_possible_to_create_a_view_on_files_that___42__dont__42___have_a_field_set__63__.mdwn
@@ -0,0 +1,3 @@
+I'm slowly adding metadata to https://github.com/ocharles/papers. For now, I'm mainly interested in setting `year` and `author` fields on files. There are a lot of files here though, so it's difficult to to work out which need metadata and which don't.
+
+Would it be possible to have a `git annex metadata -s author='*'` also have all files in the top level if they don't have an author set at all, or something? Basically, I'm looking for a way to get a view where files don't have `author` set at all, so I can fix that.

devblog
diff --git a/doc/devblog/day_387__release_day.mdwn b/doc/devblog/day_387__release_day.mdwn
new file mode 100644
index 0000000..0a36a61
--- /dev/null
+++ b/doc/devblog/day_387__release_day.mdwn
@@ -0,0 +1,10 @@
+git-annex 6.20160419 has a rare security fix.
+A [bug](http://git-annex.branchable.com/bugs/External_special_remote_broken__63__/) made encrypted special
+remotes that are configured to use chunks accidentially expose the checksums
+of content that is uploaded to the remote. Such information is supposed to
+be hidden from the remote's view by the encryption. The same bug also made
+resuming interrupted uploads to such remotes start over from the beginning.
+
+After releasing that, I've been occupied today with fixing the Android
+autobuilder, which somehow got its build environment broken (unsure how),
+and fixing some other dependency issues.

correction of scope of security problem
AFAICS, it's not only affecting resumes, but any upload to a special remote
with chunking enabled.
diff --git a/debian/changelog b/debian/changelog
index f24c11d..d4c586b 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -8,8 +8,8 @@ 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 when
-    attempting to resume an upload, so it is a minor security issue.
+  * 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,
diff --git a/doc/bugs/External_special_remote_broken__63__/comment_1_904a186a6400506303cad772ac1a6751._comment b/doc/bugs/External_special_remote_broken__63__/comment_1_904a186a6400506303cad772ac1a6751._comment
index e50f00a..7fb3b08 100644
--- a/doc/bugs/External_special_remote_broken__63__/comment_1_904a186a6400506303cad772ac1a6751._comment
+++ b/doc/bugs/External_special_remote_broken__63__/comment_1_904a186a6400506303cad772ac1a6751._comment
@@ -10,9 +10,6 @@ non-chunked form, since a remote can be reconfigured to add chunking.
 So it's nothing to worry about.
 
 The lack of encryption of the key when checking to resume is definitely a
-bug. A bit of a security bug too, although it only happens when resuming
-uploads. (I double checked the other operations and they all encrypt keys)
-I suppose that if the server was hostile, it could randomly make
-uploads fail, in order to get git-annex to expose content keys via
-this bug when resuming.
+bug. A bit of a security bug too.
+(I double checked the other operations and they all encrypt keys)
 """]]

pin unix to already installed version
This prevents multiple versions of unix, from ghc and needed by newer
versions of some packages conflicting.
Had to update the bytestring and blaze-builder pins follow-on from this
change.
diff --git a/doc/bugs/Android_chroot_stuck_in_Cabal_hell.mdwn b/doc/bugs/Android_chroot_stuck_in_Cabal_hell.mdwn
index 1587d4a..1cca413 100644
--- a/doc/bugs/Android_chroot_stuck_in_Cabal_hell.mdwn
+++ b/doc/bugs/Android_chroot_stuck_in_Cabal_hell.mdwn
@@ -18,3 +18,5 @@ collect2: error: ld returned 1 exit status
 Makefile:225: recipe for target 'android' failed
 make: *** [android] Error 1
 """]]
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/bugs/Android_chroot_stuck_in_Cabal_hell/comment_4_3dd3b8005fef7a5dad69b7d1c1154235._comment b/doc/bugs/Android_chroot_stuck_in_Cabal_hell/comment_4_3dd3b8005fef7a5dad69b7d1c1154235._comment
new file mode 100644
index 0000000..abf801c
--- /dev/null
+++ b/doc/bugs/Android_chroot_stuck_in_Cabal_hell/comment_4_3dd3b8005fef7a5dad69b7d1c1154235._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2016-04-28T17:21:00Z"
+ content="""
+Reproduced, fixed.
+"""]]
diff --git a/standalone/android/cabal.config b/standalone/android/cabal.config
index 67e9852..a55d85b 100644
--- a/standalone/android/cabal.config
+++ b/standalone/android/cabal.config
@@ -1,4 +1,5 @@
-constraints: Crypto ==4.2.5.1,
+constraints: unix installed,
+             Crypto ==4.2.5.1,
              binary ==0.7.6.1,
              DAV ==1.0.3,
              HTTP ==4000.2.17,
@@ -85,6 +86,7 @@ constraints: Crypto ==4.2.5.1,
              http-conduit ==2.1.5,
              http-date ==0.0.2,
              http-types ==0.8.5,
+	     blaze-builder ==0.3.3.2,
              hxt ==9.3.1.4,
              hxt-charproperties ==9.1.1.1,
              hxt-regex-xmlschema ==9.0.4,
@@ -195,6 +197,6 @@ constraints: Crypto ==4.2.5.1,
              yesod-routes ==1.2.0.7,
              yesod-static ==1.2.4,
              zlib ==0.5.4.1,
-             bytestring ==0.10.4.0,
+             bytestring installed,
              scientific ==0.3.3.1,
              clock ==0.4.6.0

add news item for git-annex 6.20160419
diff --git a/doc/news/version_6.20160217.mdwn b/doc/news/version_6.20160217.mdwn
deleted file mode 100644
index 598f11f..0000000
--- a/doc/news/version_6.20160217.mdwn
+++ /dev/null
@@ -1,22 +0,0 @@
-git-annex 6.20160217 released with [[!toggle text="these changes"]]
-[[!toggleable text="""
-   * Support getting files from read-only repositories.
-   * checkpresentkey: Allow to be run without an explicit remote.
-   * checkpresentkey: Added --batch.
-   * Work around problem with concurrent-output when in a non-unicode locale
-     by avoiding use of it in such a locale. Instead -J will behave as if
-     it was built without concurrent-output support in this situation.
-   * Fix storing of filenames of v6 unlocked files when the filename is not
-     representable in the current locale.
-   * fsck: Detect and fix missing associated file mappings in v6 repositories.
-   * fsck: Populate unlocked files in v6 repositories whose content is
-     present in annex/objects but didn't reach the work tree.
-   * When initializing a v6 repo on a crippled filesystem, don't force it
-     into direct mode.
-   * Windows: Fix v6 unlocked files to actually work.
-   * add, addurl, import, importfeed: When in a v6 repository on a crippled
-     filesystem, add files unlocked.
-   * annex.addunlocked: New configuration setting, makes files always be
-     added unlocked. (v6 only)
-   * Improve format of v6 unlocked pointer files to support keys containing
-     slashes."""]]
\ No newline at end of file
diff --git a/doc/news/version_6.20160419.mdwn b/doc/news/version_6.20160419.mdwn
new file mode 100644
index 0000000..8979d82
--- /dev/null
+++ b/doc/news/version_6.20160419.mdwn
@@ -0,0 +1,29 @@
+git-annex 6.20160419 released with [[!toggle text="these changes"]]
+[[!toggleable text="""
+   * 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 when
+     attempting to resume an upload, 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."""]]
\ No newline at end of file

comment
diff --git a/doc/bugs/standalone_builds_shouldn__39__t_pollute___126____47__.ssh_with_helpers_merely_upon_annex_init/comment_8_f1081a8683286bdf3ccd2d5e47a786f9._comment b/doc/bugs/standalone_builds_shouldn__39__t_pollute___126____47__.ssh_with_helpers_merely_upon_annex_init/comment_8_f1081a8683286bdf3ccd2d5e47a786f9._comment
new file mode 100644
index 0000000..df92017
--- /dev/null
+++ b/doc/bugs/standalone_builds_shouldn__39__t_pollute___126____47__.ssh_with_helpers_merely_upon_annex_init/comment_8_f1081a8683286bdf3ccd2d5e47a786f9._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 8"""
+ date="2016-04-27T17:57:49Z"
+ content="""
+Yeah, the assistant has a separate code path that writes those wrappers.
+
+I've made it also honor the GIT_ANNEX_PACKAGE_INSTALL setting.
+"""]]

todo
diff --git a/doc/todo/upload_large_chunks_without_buffering_in_memory.mdwn b/doc/todo/upload_large_chunks_without_buffering_in_memory.mdwn
new file mode 100644
index 0000000..2c5c96c
--- /dev/null
+++ b/doc/todo/upload_large_chunks_without_buffering_in_memory.mdwn
@@ -0,0 +1,26 @@
+Currently, when chunk=100MiB is used with a special remote, git-annex will
+use 100 mb ram when uploading a large file to it. The current chunk is
+buffered in ram.
+
+See comment in Remote.Helper.Chunked:
+
+	- More optimal versions of this can be written, that rely
+	- on L.toChunks to split the lazy bytestring into chunks (typically
+	- smaller than the ChunkSize), and eg, write those chunks to a Handle.
+	- But this is the best that can be done with the storer interface that
+	- writes a whole L.ByteString at a time.
+
+The buffering is probably fine for smaller chunks, in the < 10 mb or
+whatever range. Reading such a chunk from gpg and converting it into a http
+request will generally need to buffer it all in memory anyway. But, for
+eg external special remotes, the content is going to be written to a file
+anyway, so there's no point in buffering the content in memory first.
+
+So, need something like:
+
+	prefersFileContent :: Storer -> Bool
+
+And then when storeChunks is given such a Storer, it can then avoid buffering
+and write chunk data to a temp file to pass it to the Storer.
+
+--[[Joey]]

Added a comment
diff --git a/doc/bugs/standalone_builds_shouldn__39__t_pollute___126____47__.ssh_with_helpers_merely_upon_annex_init/comment_7_a9a125d4b494b5e25d7c524b49a696c5._comment b/doc/bugs/standalone_builds_shouldn__39__t_pollute___126____47__.ssh_with_helpers_merely_upon_annex_init/comment_7_a9a125d4b494b5e25d7c524b49a696c5._comment
new file mode 100644
index 0000000..4fe93ee
--- /dev/null
+++ b/doc/bugs/standalone_builds_shouldn__39__t_pollute___126____47__.ssh_with_helpers_merely_upon_annex_init/comment_7_a9a125d4b494b5e25d7c524b49a696c5._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="https://me.yahoo.com/a/EbvxpTI_xP9Aod7Mg4cwGhgjrCrdM5s-#7c0f4"
+ subject="comment 7"
+ date="2016-04-27T17:42:24Z"
+ content="""
+indeed though seems to not happen merely on 'git annex init'
+"""]]

Added a comment
diff --git a/doc/bugs/standalone_builds_shouldn__39__t_pollute___126____47__.ssh_with_helpers_merely_upon_annex_init/comment_6_5f897708dd936fc739f714691d4d2aa2._comment b/doc/bugs/standalone_builds_shouldn__39__t_pollute___126____47__.ssh_with_helpers_merely_upon_annex_init/comment_6_5f897708dd936fc739f714691d4d2aa2._comment
new file mode 100644
index 0000000..6861932
--- /dev/null
+++ b/doc/bugs/standalone_builds_shouldn__39__t_pollute___126____47__.ssh_with_helpers_merely_upon_annex_init/comment_6_5f897708dd936fc739f714691d4d2aa2._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="https://me.yahoo.com/a/EbvxpTI_xP9Aod7Mg4cwGhgjrCrdM5s-#7c0f4"
+ subject="comment 6"
+ date="2016-04-27T17:41:01Z"
+ content="""
+then I guess it is not fully effective... I have removed the copies I had, and when I started 'git annex webapp' 6.20160425+gitgffe2ea2-1~ndall+1 version recreated them
+
+[[!format sh \"\"\"
+
+$> which git-annex
+/usr/bin/git-annex
+
+$> git annex version
+git-annex version: 6.20160425+gitgffe2ea2-1~ndall+1
+...
+
+$> ls -l .ssh/git-annex-*
+-rwx------ 1 yoh yoh 215 Apr 27 13:38 .ssh/git-annex-shell*
+-rwx------ 1 yoh yoh  61 Apr 27 13:38 .ssh/git-annex-wrapper*
+\"\"\"]]
+"""]]

response
diff --git a/doc/bugs/annex_drop_is_not___34__in_effect__34___for_load_which_was___34__addurl_--batch__34__ed_but_not_yet_committed/comment_1_925a6333ed6d19e4446c02829dae3aa2._comment b/doc/bugs/annex_drop_is_not___34__in_effect__34___for_load_which_was___34__addurl_--batch__34__ed_but_not_yet_committed/comment_1_925a6333ed6d19e4446c02829dae3aa2._comment
new file mode 100644
index 0000000..0383633
--- /dev/null
+++ b/doc/bugs/annex_drop_is_not___34__in_effect__34___for_load_which_was___34__addurl_--batch__34__ed_but_not_yet_committed/comment_1_925a6333ed6d19e4446c02829dae3aa2._comment
@@ -0,0 +1,26 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-04-27T17:22:03Z"
+ content="""
+git-annex commands only operate on files that are checked into the git
+repsitory, which is why drop skips this file that has not been staged yet.
+I do not think it makes sense to change that.
+
+git-annex addurl batches changes to the index, which can speed up its
+performance significantly when adding a lot of files. So until it's done
+you can't operate on the files it adds. That speedup is really the only
+reason to use addurl --batch, so it doesn't make sense to change it to not
+have that optiomisation, otherwise you could just use it in non-batch mode
+and drop after it's done.
+
+So, if you want to drop files as soon as addurl adds them, you need to
+either not batch addurl, or you need to drop not by the name of the file
+that has not need checked into git yet, but by the key.
+
+So, I think it would make sense for you to use dropkey in this case.
+`git annex addurl --json --batch` already includes the key,
+so you can just pass that along to `git annex dropkey --batch`
+
+(Do note though that dropkey doesn't verify that other copies exist..)
+"""]]

comment
diff --git a/doc/bugs/standalone_builds_shouldn__39__t_pollute___126____47__.ssh_with_helpers_merely_upon_annex_init/comment_5_f427a3ac3e553c73a9ff3c8894d8f6fb._comment b/doc/bugs/standalone_builds_shouldn__39__t_pollute___126____47__.ssh_with_helpers_merely_upon_annex_init/comment_5_f427a3ac3e553c73a9ff3c8894d8f6fb._comment
new file mode 100644
index 0000000..c95d187
--- /dev/null
+++ b/doc/bugs/standalone_builds_shouldn__39__t_pollute___126____47__.ssh_with_helpers_merely_upon_annex_init/comment_5_f427a3ac3e553c73a9ff3c8894d8f6fb._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2016-04-27T17:14:49Z"
+ content="""
+There's no reason for git-annex-standalone.deb's git-annex to
+set up any of these wrappers, anywhere. That deb installs git-annex onto
+the system PATH, so none of these workarounds for it not being installed on
+the system path are needed.
+
+The `GIT_ANNEX_PACKAGE_INSTALL` variable is supposed to prevent that. It's
+set by debian/rules, since 5.20151116.
+"""]]

comment
diff --git a/doc/bugs/encfs_support_--_shouldn__39__t_it_be_treated_as_crippled_already__63__/comment_1_a3111068628efcfe8c5dbbe653805481._comment b/doc/bugs/encfs_support_--_shouldn__39__t_it_be_treated_as_crippled_already__63__/comment_1_a3111068628efcfe8c5dbbe653805481._comment
new file mode 100644
index 0000000..98455e1
--- /dev/null
+++ b/doc/bugs/encfs_support_--_shouldn__39__t_it_be_treated_as_crippled_already__63__/comment_1_a3111068628efcfe8c5dbbe653805481._comment
@@ -0,0 +1,26 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-04-27T16:59:51Z"
+ content="""
+git-annex does not these days treat lack of of hard link support as a crippled
+filesystem. It just falls back to copying files where it would make hard
+links.
+
+encfs is coming up crippled because it ignores lack of write bits on files;
+writing to a mode 444 file on an encfs filesystem by the owner of the file
+is allowed. 
+
+That breaks an important safeguard that git-annex relies on;
+for example this would work in a non-direct mode repository on an encfs
+filesystem, even though file permissions don't allow writing to annexed
+file contents:
+
+	joey@darkstar:/tmp/encfs/d> echo corrupt > bar
+
+So, you're really better off using direct mode on encfs.
+
+encfs has tons of other problems that make it not work well with
+git-annex, and generally insecure. I heartily recommend you reconsider
+using it.
+"""]]

comment
diff --git a/doc/bugs/broken_repo_when_inodes_exhausted/comment_1_8ccfac4cea4c54029b96b436ac2114ed._comment b/doc/bugs/broken_repo_when_inodes_exhausted/comment_1_8ccfac4cea4c54029b96b436ac2114ed._comment
new file mode 100644
index 0000000..c71e59f
--- /dev/null
+++ b/doc/bugs/broken_repo_when_inodes_exhausted/comment_1_8ccfac4cea4c54029b96b436ac2114ed._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-04-27T16:55:36Z"
+ content="""
+Pretty much anything is going to break when you run out of inodes; 
+all the errors shown here are due to the git repository getting
+inconsistent because of it. I don't see any part that's git-annex specific.
+
+Is `git annex repair` able to repair it at all? I'd expect it would be able
+to, as long as `git fsck` reports that there are problems.
+"""]]

Fix bug that prevented resuming of uploads to encrypted special remotes that used chunking. This bug could also expose the names of keys to such remotes.
This is a low-severity security hole.
diff --git a/Remote/Helper/Chunked.hs b/Remote/Helper/Chunked.hs
index 8098abc..e3cf0d2 100644
--- a/Remote/Helper/Chunked.hs
+++ b/Remote/Helper/Chunked.hs
@@ -99,13 +99,14 @@ numChunks = pred . fromJust . keyChunkNum . fst . nextChunkKeyStream
 storeChunks
 	:: UUID
 	-> ChunkConfig
+	-> EncKey
 	-> Key
 	-> FilePath
 	-> MeterUpdate
 	-> Storer
 	-> CheckPresent
 	-> Annex Bool
-storeChunks u chunkconfig k f p storer checker = 
+storeChunks u chunkconfig encryptor k f p storer checker = 
 	case chunkconfig of
 		(UnpaddedChunks chunksize) | isStableKey k -> 
 			bracketIO open close (go chunksize)
@@ -121,7 +122,7 @@ storeChunks u chunkconfig k f p storer checker =
 		return False
 	go chunksize (Right h) = do
 		let chunkkeys = chunkKeyStream k chunksize
-		(chunkkeys', startpos) <- seekResume h chunkkeys checker
+		(chunkkeys', startpos) <- seekResume h encryptor chunkkeys checker
 		b <- liftIO $ L.hGetContents h
 		gochunks p startpos chunksize b chunkkeys'
 
@@ -165,10 +166,11 @@ storeChunks u chunkconfig k f p storer checker =
  -}
 seekResume
 	:: Handle
+	-> EncKey
 	-> ChunkKeyStream
 	-> CheckPresent
 	-> Annex (ChunkKeyStream, BytesProcessed)
-seekResume h chunkkeys checker = do
+seekResume h encryptor chunkkeys checker = do
 	sz <- liftIO (hFileSize h)
 	if sz <= fromMaybe 0 (keyChunkSize $ fst $ nextChunkKeyStream chunkkeys)
 		then return (chunkkeys, zeroBytesProcessed)
@@ -180,7 +182,7 @@ seekResume h chunkkeys checker = do
 			liftIO $ hSeek h AbsoluteSeek sz
 			return (cks, toBytesProcessed sz)
 		| otherwise = do
-			v <- tryNonAsync (checker k)
+			v <- tryNonAsync (checker (encryptor k))
 			case v of
 				Right True ->
 					check pos' cks' sz
diff --git a/Remote/Helper/Special.hs b/Remote/Helper/Special.hs
index fdadc97..f9b5dea 100644
--- a/Remote/Helper/Special.hs
+++ b/Remote/Helper/Special.hs
@@ -189,11 +189,12 @@ specialRemote' cfg c preparestorer prepareretriever prepareremover preparecheckp
 		go Nothing = return False
 		go' storer (Just checker) = sendAnnex k rollback $ \src ->
 			displayprogress p k $ \p' ->
-				storeChunks (uuid baser) chunkconfig k src p'
+				storeChunks (uuid baser) chunkconfig enck k src p'
 					(storechunk enc storer)
 					checker
 		go' _ Nothing = return False
 		rollback = void $ removeKey encr k
+		enck = maybe id snd enc
 
 	storechunk Nothing storer k content p = storer k content p
 	storechunk (Just (cipher, enck)) storer k content p = do
diff --git a/debian/changelog b/debian/changelog
index 938ed35..f1a54ea 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -22,6 +22,9 @@ git-annex (6.20160419) UNRELEASED; urgency=medium
     this behavior change when the assistant merges. Note though that this is
     not done for git annex sync's merges, so it will follow git's default or
     configured behavior.
+  * Fix bug that prevented resuming of uploads to encrypted special remotes
+    that used chunking. This bug could also expose the names of keys to
+    such remotes.
 
  -- Joey Hess <id@joeyh.name>  Tue, 19 Apr 2016 12:57:15 -0400
 
diff --git a/doc/bugs/External_special_remote_broken__63__.mdwn b/doc/bugs/External_special_remote_broken__63__.mdwn
index ac7627d..b217e14 100644
--- a/doc/bugs/External_special_remote_broken__63__.mdwn
+++ b/doc/bugs/External_special_remote_broken__63__.mdwn
@@ -61,4 +61,4 @@ upgrade supported from repository versions: 0 1 2 4 5
 
 ### 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)
 
-
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/bugs/External_special_remote_broken__63__/comment_1_904a186a6400506303cad772ac1a6751._comment b/doc/bugs/External_special_remote_broken__63__/comment_1_904a186a6400506303cad772ac1a6751._comment
new file mode 100644
index 0000000..e50f00a
--- /dev/null
+++ b/doc/bugs/External_special_remote_broken__63__/comment_1_904a186a6400506303cad772ac1a6751._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-04-27T16:23:43Z"
+ content="""
+Reproduced this using a directory special remote.
+
+The first checkpresent is because a file can be present on a remote in
+non-chunked form, since a remote can be reconfigured to add chunking.
+So it's nothing to worry about.
+
+The lack of encryption of the key when checking to resume is definitely a
+bug. A bit of a security bug too, although it only happens when resuming
+uploads. (I double checked the other operations and they all encrypt keys)
+I suppose that if the server was hostile, it could randomly make
+uploads fail, in order to get git-annex to expose content keys via
+this bug when resuming.
+"""]]

give this bug a sane title
diff --git a/doc/bugs/External_special_remote_broken__63__.mdwn b/doc/bugs/External_special_remote_broken__63__.mdwn
index 5cf36c1..ac7627d 100644
--- a/doc/bugs/External_special_remote_broken__63__.mdwn
+++ b/doc/bugs/External_special_remote_broken__63__.mdwn
@@ -1,3 +1,5 @@
+[[!meta title="encrypted key not checked when resuming upload to chunked encrypted special remote"]]
+
 ### Please describe the problem.
 
 Resuming an upload seems not to work when used with chunking. Here is some sample conservation:

diff --git a/doc/bugs/encfs_support_--_shouldn__39__t_it_be_treated_as_crippled_already__63__.mdwn b/doc/bugs/encfs_support_--_shouldn__39__t_it_be_treated_as_crippled_already__63__.mdwn
new file mode 100644
index 0000000..a4b4ffa
--- /dev/null
+++ b/doc/bugs/encfs_support_--_shouldn__39__t_it_be_treated_as_crippled_already__63__.mdwn
@@ -0,0 +1,92 @@
+### Please describe the problem.
+
+In the past archived issue ([[https://webcache.googleusercontent.com/search?q=cache:t2N25kWAWEsJ:https://git-annex.branchable.com/bugs/encfs_accused_of_being_crippled/+&cd=1&hl=en&ct=clnk&gl=us]]) you have left a comment 
+
+    So, it seems worthwhile to break out lack of hard links support from the other limitations currently lumped into "cripped file system". I've done so.
+
+did it mean that encfs should be supported without assuming it crippled any longer?
+
+I have just tried with annex 6.20160425+gitgffe2ea2-1~ndall+1  and it still considers it crippled (FWIW and for the record encfs is 1.8.1-3+b2) 
+
+
+[[!format sh """
+$> git annex init --debug
+init  [2016-04-27 11:55:41.20934] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","--hash","refs/heads/git-annex"]
+[2016-04-27 11:55:41.214794] process done ExitFailure 1
+[2016-04-27 11:55:41.21487] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","--verify","-q","origin/git-annex"]
+[2016-04-27 11:55:41.218775] process done ExitFailure 1
+[2016-04-27 11:55:41.219362] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","write-tree"]
+[2016-04-27 11:55:41.225289] process done ExitSuccess
+[2016-04-27 11:55:41.225379] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","commit-tree","4b825dc642cb6eb9a060e54bf8d69288fbee4904","--no-gpg-sign"]
+[2016-04-27 11:55:41.232881] process done ExitSuccess
+[2016-04-27 11:55:41.233028] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","update-ref","refs/heads/git-annex","243e083b39dbf3ae84014dfd9be82d93ab57feb1"]
+[2016-04-27 11:55:41.240395] process done ExitSuccess
+[2016-04-27 11:55:41.252322] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","config","annex.uuid","75f66b80-d877-4f33-8b32-53dff9ac7da8"]
+[2016-04-27 11:55:41.25768] process done ExitSuccess
+[2016-04-27 11:55:41.257822] read: git ["config","--null","--list"]
+[2016-04-27 11:55:41.263729] process done ExitSuccess
+
+  Detected a crippled filesystem.
+[2016-04-27 11:55:41.283605] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","config","annex.crippledfilesystem","true"]
+[2016-04-27 11:55:41.288741] process done ExitSuccess
+[2016-04-27 11:55:41.289113] read: git ["config","--null","--list"]
+[2016-04-27 11:55:41.294897] process done ExitSuccess
+
+  Disabling core.symlinks.
+[2016-04-27 11:55:41.295002] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","config","core.symlinks","false"]
+[2016-04-27 11:55:41.29995] process done ExitSuccess
+[2016-04-27 11:55:41.300036] read: git ["config","--null","--list"]
+[2016-04-27 11:55:41.305809] process done ExitSuccess
+[2016-04-27 11:55:41.30591] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","git-annex"]
+[2016-04-27 11:55:41.310985] process done ExitSuccess
+[2016-04-27 11:55:41.311082] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","--hash","refs/heads/git-annex"]
+[2016-04-27 11:55:41.316091] process done ExitSuccess
+[2016-04-27 11:55:41.316284] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","log","refs/heads/git-annex..243e083b39dbf3ae84014dfd9be82d93ab57feb1","--pretty=%H","-n1"]
+[2016-04-27 11:55:41.322238] process done ExitSuccess
+[2016-04-27 11:55:41.323989] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch"]
+[2016-04-27 11:55:41.330709] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","config","annex.version","5"]
+[2016-04-27 11:55:41.335578] process done ExitSuccess
+[2016-04-27 11:55:41.335656] read: git ["config","--null","--list"]
+[2016-04-27 11:55:41.340418] process done ExitSuccess
+
+  Enabling direct mode.
+[2016-04-27 11:55:41.340519] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","ls-files","--cached","-z","--","."]
+[2016-04-27 11:55:41.34474] process done ExitSuccess
+[2016-04-27 11:55:41.344828] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","symbolic-ref","-q","HEAD"]
+[2016-04-27 11:55:41.349993] process done ExitSuccess
+[2016-04-27 11:55:41.352705] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","--hash","refs/heads/master"]
+[2016-04-27 11:55:41.357245] process done ExitFailure 1
+[2016-04-27 11:55:41.357309] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","checkout","-q","-B","annex/direct/master"]
+[2016-04-27 11:55:41.362052] process done ExitSuccess
+[2016-04-27 11:55:41.362117] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","config","core.bare","true"]
+[2016-04-27 11:55:41.368411] process done ExitSuccess
+[2016-04-27 11:55:41.368536] read: git ["config","--null","--list"]
+[2016-04-27 11:55:41.373468] process done ExitSuccess
+[2016-04-27 11:55:41.373556] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","config","annex.direct","true"]
+[2016-04-27 11:55:41.378578] process done ExitSuccess
+[2016-04-27 11:55:41.379147] read: git ["config","--null","--list"]
+[2016-04-27 11:55:41.38818] process done ExitSuccess
+[2016-04-27 11:55:41.388271] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","symbolic-ref","-q","HEAD"]
+[2016-04-27 11:55:41.39251] process done ExitSuccess
+[2016-04-27 11:55:41.392591] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","refs/heads/annex/direct/master"]
+[2016-04-27 11:55:41.397179] process done ExitFailure 1
+[2016-04-27 11:55:41.416782] read: uname ["-n"]
+[2016-04-27 11:55:41.419832] process done ExitSuccess
+ok
+[2016-04-27 11:55:41.434629] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","hash-object","-w","--stdin-paths","--no-filters"]
+[2016-04-27 11:55:41.435418] feed: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","update-index","-z","--index-info"]
+[2016-04-27 11:55:41.443936] process done ExitSuccess
+[2016-04-27 11:55:41.444038] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","--hash","refs/heads/git-annex"]
+[2016-04-27 11:55:41.449543] process done ExitSuccess
+(recording state in git...)
+[2016-04-27 11:55:41.450041] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","write-tree"]
+[2016-04-27 11:55:41.460223] process done ExitSuccess
+[2016-04-27 11:55:41.46035] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","commit-tree","a8504dac0ddbd154fff36b704b6d49c6eb573d6c","--no-gpg-sign","-p","refs/heads/git-annex"]
+[2016-04-27 11:55:41.467958] process done ExitSuccess
+[2016-04-27 11:55:41.468059] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","update-ref","refs/heads/git-annex","c163e24c747d665d51bfa3f13026193956ef1313"]
+[2016-04-27 11:55:41.475227] process done ExitSuccess
+
+"""]]
+
+[[!meta author=yoh]]
+

diff --git a/doc/bugs/broken_repo_when_inodes_exhausted.mdwn b/doc/bugs/broken_repo_when_inodes_exhausted.mdwn
new file mode 100644
index 0000000..3c03478
--- /dev/null
+++ b/doc/bugs/broken_repo_when_inodes_exhausted.mdwn
@@ -0,0 +1,62 @@
+### Please describe the problem.
+I found one of my repos damaged after letting the webapp sync with it for a while.  The filesystem inodes were exhausted and all the refs pointed to objects that do not exist.
+
+### What steps will reproduce the problem?
+I expect this issue to be reproduced by syncing to a filesystem without enough free inodes to hold the incoming files.
+
+### What version of git-annex are you using? On what operating system?
+This repo is using git-annex 6.20160229-g37a89cc
+
+### 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
+
+$ git status
+fatal: bad object HEAD
+$ git pull
+error: refs/heads/master does not point to a valid object!
+error: refs/heads/synced/git-annex does not point to a valid object!
+error: refs/heads/synced/master does not point to a valid object!
+error: refs/heads/master does not point to a valid object!
+error: refs/heads/synced/git-annex does not point to a valid object!
+error: refs/heads/synced/master does not point to a valid object!
+error: refs/heads/master does not point to a valid object!
+error: refs/heads/synced/git-annex does not point to a valid object!
+error: refs/heads/synced/master does not point to a valid object!
+error: refs/heads/master does not point to a valid object!
+error: refs/heads/synced/git-annex does not point to a valid object!
+error: refs/heads/synced/master does not point to a valid object!
+remote: Counting objects: 3, done.
+remote: Compressing objects: 100% (3/3), done.
+remote: Total 3 (delta 0), reused 0 (delta 0)
+Unpacking objects: 100% (3/3), done.
+error: refs/heads/master does not point to a valid object!
+error: refs/heads/synced/git-annex does not point to a valid object!
+error: refs/heads/synced/master does not point to a valid object!
+fatal: bad object HEAD
+error: /home/olpc/annex-ext4 did not send all necessary objects
+
+Auto packing the repository in background for optimum performance.
+See "git help gc" for manual housekeeping.
+error: The last gc run reported the following. Please correct the root cause
+and remove .git/gc.log.
+Automatic cleanup will not be performed until the file is removed.
+
+error: refs/heads/master does not point to a valid object!
+error: refs/heads/synced/git-annex does not point to a valid object!
+error: refs/heads/synced/master does not point to a valid object!
+error: refs/remotes/beta/master does not point to a valid object!
+error: refs/remotes/beta/synced/master does not point to a valid object!
+error: refs/remotes/halloween/master does not point to a valid object!
+error: refs/remotes/halloween/synced/master does not point to a valid object!
+fatal: bad object HEAD
+error: failed to run repack
+
+# 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'm running into a few issues but I intend to work through them.  

Added a comment: create symlinks inside .git/annex/objects
diff --git a/doc/bugs/OSX_case_insensitive_filesystem/comment_7_45e0178ce9598d086f34a89701536eb5._comment b/doc/bugs/OSX_case_insensitive_filesystem/comment_7_45e0178ce9598d086f34a89701536eb5._comment
new file mode 100644
index 0000000..e1a5fec
--- /dev/null
+++ b/doc/bugs/OSX_case_insensitive_filesystem/comment_7_45e0178ce9598d086f34a89701536eb5._comment
@@ -0,0 +1,43 @@
+[[!comment format=mdwn
+ username="thowz"
+ subject="create symlinks inside .git/annex/objects"
+ date="2016-04-27T00:36:57Z"
+ content="""
+I also ran into this problem when copying a folder from Mac to Linux. Because the HFS+ filesystem is case-insensitive, directories that should be multiple directories are instead collapsed into one. For example, if there are four different files that are supposed to go into folders FG, fG, Fg, and fg, they will all end up in just one folder (whichever of the four was created first). But the symlinks will still point to different cases, so when everything gets moved to a case-sensitive filesystem, the symlinks break.
+
+I did a quick fix on the Linux side by making symlinks within .git/annex/objects to account for all the case variations (if folder FG exists and has more than one sub-folder, create symlinks  fG --> FG,  Fg --> FG,  fg --> FG).
+
+To do this for the whole set of directories and sub-directories, I made a perl script:
+
+    #!/usr/bin/perl 
+    
+    $dir=$ARGV[0];
+    $dir=substr($dir,2,2);
+    $link=$dir;
+    
+    if($dir =~ /[a-zA-Z]\d/){
+        substr($link,0,1) ^= \" \";
+        system(\"ln\", \"-s\", $dir, $link);
+    }
+    
+    if($dir =~ /\d[a-zA-Z]/){
+        substr($link,1,1) ^= \" \";
+        system(\"ln\", \"-s\", $dir, $link);
+    }
+    
+    if($dir =~ /[a-zA-Z]{2}/){
+        substr($link,0,1) ^= \" \";
+        system(\"ln\", \"-s\", $dir, $link);
+        substr($link,1,1) ^= \" \";
+        system(\"ln\", \"-s\", $dir, $link);
+        substr($link,0,1) ^= \" \";
+        system(\"ln\", \"-s\", $dir, $link);
+    }
+
+
+And ran it this way (with script made executable and placed in $PATH):
+
+    find .git/annex/objects -mindepth 1 -maxdepth 2 -links +3 -type d -execdir makelinks.pl {} \;
+
+It might be nice if git-annex-fsck could check whether a file was \"misfiled\" into the wrong directory due to case-insensitivity (before concluding that the file is missing). Although it also makes sense just to recommend cloning instead of copying when moving to a different filesystem (or remembering to set `annex.tune.objecthashlower true` when initiating a repo on a case-insensitive system).
+"""]]

diff --git a/doc/bugs/External_special_remote_broken__63__.mdwn b/doc/bugs/External_special_remote_broken__63__.mdwn
index 29b5120..5cf36c1 100644
--- a/doc/bugs/External_special_remote_broken__63__.mdwn
+++ b/doc/bugs/External_special_remote_broken__63__.mdwn
@@ -32,9 +32,9 @@ Resuming an upload seems not to work when used with chunking. Here is some sampl
 
 There are some steps that do not get in my mind:
 
-1) What is the first "CHECKPRESENT GPGHMACSHA1" good for? The full file including all chunks?
-2) Second: Why is git-annex looking for "CHECKPRESENT SHA256E", the plain file (not encrypted)?
-3) And now the 'real' problem: git-annex does a "TRANSFER STORE" of some key, but does not first check with CHECKPRESENT if it's there. And indeed, this file is already in the repo, so a "CHECKPRESENT GPGHMACSHA1--48e285fd650dac05eefa328bfbe8efd8a0ca2100" would return true in my case. Therefore it reuploads all my data, which is not so great ;P.
+1. What is the first "CHECKPRESENT GPGHMACSHA1" good for? The full file including all chunks?
+2. Second: Why is git-annex looking for "CHECKPRESENT SHA256E", the plain file (not encrypted)?
+3. And now the 'real' problem: git-annex does a "TRANSFER STORE" of some key, but does not first check with CHECKPRESENT if it's there. And indeed, this file is already in the repo, so a "CHECKPRESENT GPGHMACSHA1--48e285fd650dac05eefa328bfbe8efd8a0ca2100" would return true in my case. Therefore it reuploads all my data, which is not so great ;P.
 
 ### What version of git-annex are you using? On what operating system?
 

diff --git a/doc/bugs/External_special_remote_broken__63__.mdwn b/doc/bugs/External_special_remote_broken__63__.mdwn
index 68351fb..29b5120 100644
--- a/doc/bugs/External_special_remote_broken__63__.mdwn
+++ b/doc/bugs/External_special_remote_broken__63__.mdwn
@@ -5,27 +5,26 @@ Resuming an upload seems not to work when used with chunking. Here is some sampl
 
 
 
-[2016-04-26 21:26:14.465287] chat: git-annex-remote-rclone []
-[2016-04-26 21:26:14.468527] git-annex-remote-rclone --> VERSION 1
-[2016-04-26 21:26:14.468726] git-annex-remote-rclone <-- PREPARE
-[2016-04-26 21:26:14.469533] git-annex-remote-rclone --> GETCONFIG prefix
-[2016-04-26 21:26:14.469741] git-annex-remote-rclone <-- VALUE annex.datengrotte
-[2016-04-26 21:26:14.475725] git-annex-remote-rclone --> GETCONFIG target
-[2016-04-26 21:26:14.47597] git-annex-remote-rclone <-- VALUE hubic
-[2016-04-26 21:26:14.481164] git-annex-remote-rclone --> PREPARE-SUCCESS
-[2016-04-26 21:26:14.485361] git-annex-remote-rclone <-- CHECKPRESENT GPGHMACSHA1--2a63df425e9d018adbc9a6e508817c727e414d55
-[2016-04-26 21:26:14.485831] git-annex-remote-rclone --> DIRHASH GPGHMACSHA1--2a63df425e9d018adbc9a6e508817c727e414d55
-[2016-04-26 21:26:14.485937] git-annex-remote-rclone <-- VALUE GM/2k/
-[2016-04-26 21:26:25.571228] git-annex-remote-rclone --> CHECKPRESENT-FAILURE GPGHMACSHA1--2a63df425e9d018adbc9a6e508817c727e414d55
-(to hubic3...) 
-[2016-04-26 21:26:25.5726] git-annex-remote-rclone <-- CHECKPRESENT SHA256E-s2885269915-S104857600-C1--186620a13bc048d4c9d75ec3a504f9569e5a43047342be5e5279b14b0c445fa6.mp4
-[2016-04-26 21:26:25.57296] git-annex-remote-rclone --> DIRHASH SHA256E-s2885269915-S104857600-C1--186620a13bc048d4c9d75ec3a504f9569e5a43047342be5e5279b14b0c445fa6.mp4
-[2016-04-26 21:26:25.573207] git-annex-remote-rclone <-- VALUE 1v/zK/
-[2016-04-26 21:26:27.392524] git-annex-remote-rclone --> CHECKPRESENT-FAILURE SHA256E-s2885269915-S104857600-C1--186620a13bc048d4c9d75ec3a504f9569e5a43047342be5e5279b14b0c445fa6.mp4
-[2016-04-26 21:26:27.393076] chat: gpg ["--quiet","--trust-model","always","--batch","--passphrase-fd","23","--symmetric","--force-mdc","--no-textmode"]
-[2016-04-26 21:26:31.103132] git-annex-remote-rclone <-- TRANSFER STORE GPGHMACSHA1--48e285fd650dac05eefa328bfbe8efd8a0ca2100 ../.git/annex/tmp/GPGHMACSHA1--48e285fd650dac05eefa328bfbe8efd8a0ca2100
-[2016-04-26 21:26:31.103773] git-annex-remote-rclone --> DIRHASH GPGHMACSHA1--48e285fd650dac05eefa328bfbe8efd8a0ca2100
-[2016-04-26 21:26:31.103888] git-annex-remote-rclone <-- VALUE 8Q/Z9/
+    [2016-04-26 21:26:14.465287] chat: git-annex-remote-rclone []
+    [2016-04-26 21:26:14.468527] git-annex-remote-rclone --> VERSION 1
+    [2016-04-26 21:26:14.468726] git-annex-remote-rclone <-- PREPARE
+    [2016-04-26 21:26:14.469533] git-annex-remote-rclone --> GETCONFIG prefix
+    [2016-04-26 21:26:14.469741] git-annex-remote-rclone <-- VALUE annex.datengrotte
+    [2016-04-26 21:26:14.475725] git-annex-remote-rclone --> GETCONFIG target
+    [2016-04-26 21:26:14.47597] git-annex-remote-rclone <-- VALUE hubic
+    [2016-04-26 21:26:14.481164] git-annex-remote-rclone --> PREPARE-SUCCESS
+    [2016-04-26 21:26:14.485361] git-annex-remote-rclone <-- CHECKPRESENT GPGHMACSHA1--2a63df425e9d018adbc9a6e508817c727e414d55
+    [2016-04-26 21:26:14.485831] git-annex-remote-rclone --> DIRHASH GPGHMACSHA1--2a63df425e9d018adbc9a6e508817c727e414d55
+    [2016-04-26 21:26:14.485937] git-annex-remote-rclone <-- VALUE GM/2k/
+    [2016-04-26 21:26:25.571228] git-annex-remote-rclone --> CHECKPRESENT-FAILURE GPGHMACSHA1--2a63df425e9d018adbc9a6e508817c727e414d55
+    [2016-04-26 21:26:25.5726] git-annex-remote-rclone <-- CHECKPRESENT SHA256E-s2885269915-S104857600-C1--186620a13bc048d4c9d75ec3a504f9569e5a43047342be5e5279b14b0c445fa6.mp4
+    [2016-04-26 21:26:25.57296] git-annex-remote-rclone --> DIRHASH SHA256E-s2885269915-S104857600-C1--186620a13bc048d4c9d75ec3a504f9569e5a43047342be5e5279b14b0c445fa6.mp4
+    [2016-04-26 21:26:25.573207] git-annex-remote-rclone <-- VALUE 1v/zK/
+    [2016-04-26 21:26:27.392524] git-annex-remote-rclone --> CHECKPRESENT-FAILURE SHA256E-s2885269915-S104857600-C1--186620a13bc048d4c9d75ec3a504f9569e5a43047342be5e5279b14b0c445fa6.mp4
+    [2016-04-26 21:26:27.393076] chat: gpg ["--quiet","--trust-model","always","--batch","--passphrase-fd","23","--symmetric","--force-mdc","--no-textmode"]
+    [2016-04-26 21:26:31.103132] git-annex-remote-rclone <-- TRANSFER STORE GPGHMACSHA1--48e285fd650dac05eefa328bfbe8efd8a0ca2100 ../.git/annex/tmp/GPGHMACSHA1--48e285fd650dac05eefa328bfbe8efd8a0ca2100
+    [2016-04-26 21:26:31.103773] git-annex-remote-rclone --> DIRHASH GPGHMACSHA1--48e285fd650dac05eefa328bfbe8efd8a0ca2100
+    [2016-04-26 21:26:31.103888] git-annex-remote-rclone <-- VALUE 8Q/Z9/
 
 
 

diff --git a/doc/bugs/External_special_remote_broken__63__.mdwn b/doc/bugs/External_special_remote_broken__63__.mdwn
new file mode 100644
index 0000000..68351fb
--- /dev/null
+++ b/doc/bugs/External_special_remote_broken__63__.mdwn
@@ -0,0 +1,63 @@
+### Please describe the problem.
+
+Resuming an upload seems not to work when used with chunking. Here is some sample conservation:
+
+
+
+
+[2016-04-26 21:26:14.465287] chat: git-annex-remote-rclone []
+[2016-04-26 21:26:14.468527] git-annex-remote-rclone --> VERSION 1
+[2016-04-26 21:26:14.468726] git-annex-remote-rclone <-- PREPARE
+[2016-04-26 21:26:14.469533] git-annex-remote-rclone --> GETCONFIG prefix
+[2016-04-26 21:26:14.469741] git-annex-remote-rclone <-- VALUE annex.datengrotte
+[2016-04-26 21:26:14.475725] git-annex-remote-rclone --> GETCONFIG target
+[2016-04-26 21:26:14.47597] git-annex-remote-rclone <-- VALUE hubic
+[2016-04-26 21:26:14.481164] git-annex-remote-rclone --> PREPARE-SUCCESS
+[2016-04-26 21:26:14.485361] git-annex-remote-rclone <-- CHECKPRESENT GPGHMACSHA1--2a63df425e9d018adbc9a6e508817c727e414d55
+[2016-04-26 21:26:14.485831] git-annex-remote-rclone --> DIRHASH GPGHMACSHA1--2a63df425e9d018adbc9a6e508817c727e414d55
+[2016-04-26 21:26:14.485937] git-annex-remote-rclone <-- VALUE GM/2k/
+[2016-04-26 21:26:25.571228] git-annex-remote-rclone --> CHECKPRESENT-FAILURE GPGHMACSHA1--2a63df425e9d018adbc9a6e508817c727e414d55
+(to hubic3...) 
+[2016-04-26 21:26:25.5726] git-annex-remote-rclone <-- CHECKPRESENT SHA256E-s2885269915-S104857600-C1--186620a13bc048d4c9d75ec3a504f9569e5a43047342be5e5279b14b0c445fa6.mp4
+[2016-04-26 21:26:25.57296] git-annex-remote-rclone --> DIRHASH SHA256E-s2885269915-S104857600-C1--186620a13bc048d4c9d75ec3a504f9569e5a43047342be5e5279b14b0c445fa6.mp4
+[2016-04-26 21:26:25.573207] git-annex-remote-rclone <-- VALUE 1v/zK/
+[2016-04-26 21:26:27.392524] git-annex-remote-rclone --> CHECKPRESENT-FAILURE SHA256E-s2885269915-S104857600-C1--186620a13bc048d4c9d75ec3a504f9569e5a43047342be5e5279b14b0c445fa6.mp4
+[2016-04-26 21:26:27.393076] chat: gpg ["--quiet","--trust-model","always","--batch","--passphrase-fd","23","--symmetric","--force-mdc","--no-textmode"]
+[2016-04-26 21:26:31.103132] git-annex-remote-rclone <-- TRANSFER STORE GPGHMACSHA1--48e285fd650dac05eefa328bfbe8efd8a0ca2100 ../.git/annex/tmp/GPGHMACSHA1--48e285fd650dac05eefa328bfbe8efd8a0ca2100
+[2016-04-26 21:26:31.103773] git-annex-remote-rclone --> DIRHASH GPGHMACSHA1--48e285fd650dac05eefa328bfbe8efd8a0ca2100
+[2016-04-26 21:26:31.103888] git-annex-remote-rclone <-- VALUE 8Q/Z9/
+
+
+
+
+
+There are some steps that do not get in my mind:
+
+1) What is the first "CHECKPRESENT GPGHMACSHA1" good for? The full file including all chunks?
+2) Second: Why is git-annex looking for "CHECKPRESENT SHA256E", the plain file (not encrypted)?
+3) And now the 'real' problem: git-annex does a "TRANSFER STORE" of some key, but does not first check with CHECKPRESENT if it's there. And indeed, this file is already in the repo, so a "CHECKPRESENT GPGHMACSHA1--48e285fd650dac05eefa328bfbe8efd8a0ca2100" would return true in my case. Therefore it reuploads all my data, which is not so great ;P.
+
+### What version of git-annex are you using? On what operating system?
+
+it-annex version: 6.20160418-geff8673
+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: 6
+supported repository versions: 5 6
+upgrade supported from repository versions: 0 1 2 4 5
+
+
+### 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)
+
+

initial report
diff --git a/doc/bugs/annex_drop_is_not___34__in_effect__34___for_load_which_was___34__addurl_--batch__34__ed_but_not_yet_committed.mdwn b/doc/bugs/annex_drop_is_not___34__in_effect__34___for_load_which_was___34__addurl_--batch__34__ed_but_not_yet_committed.mdwn
new file mode 100644
index 0000000..5c9f47e
--- /dev/null
+++ b/doc/bugs/annex_drop_is_not___34__in_effect__34___for_load_which_was___34__addurl_--batch__34__ed_but_not_yet_committed.mdwn
@@ -0,0 +1,64 @@
+### Please describe the problem.
+
+Usecase (you might suggest a better way) is to 'annex' the content of files (via addurl) without actually committing symlinks to git (git-annex branch obviously should progress forward).  So the sequence is akin 'annex addurl', 'annex drop' both ran with annex.alwayscommit=false .  The issue is that it seems that if addurl is --batched, then symlink is not 'git add'ed until batched process finishes, and thus subsequent to 'addurl' 'drop' does nothing, leaving key behind not dropped.
+
+Related recent TODO wishlist is [[http://git-annex.branchable.com/todo/drop_--batch/]]
+
+### What steps will reproduce the problem?
+
+FWIW below is a somewhat noisy output from datalad's unittest (which addurl into the archive's content, so custom special remote is involved).  At the end of the run content is not dropped, symlink is not dangling.
+
+### What version of git-annex are you using? On what operating system?
+
+originally was a version from March but tried also with fresh  6.20160425+gitgffe2ea2-1~ndall+1
+
+### Please provide any additional information below.
+
+[[!format sh """
+
+2016-04-26 14:13:05,545 [DEBUG  ] Initiating a new process for BatchedAnnex(annex_cmd='addurl', annex_options=['--with-files', '--json'], git_options=[], output_proc=<function>, path=<<'/home/yoh/.tmp/datala...>>) (annexrepo.py:1145)
+2016-04-26 14:13:05,545 [Level 5] Command: ['git', '-c', 'receive.autogc=0', '-c', 'gc.auto=0', 'annex', 'addurl', '--with-files', '--json', '--batch'] (annexrepo.py:1148)
+2016-04-26 14:13:05,548 [Level 5] Sending 'dl+archive:SHA256E-s10240--0d52ce580b5ea9324dfc2ac7c714130f02499439e6b990282adb6580a97fe1d0.tar/1/file.txt#size=4 .dataladMCsP4y/file.txt\n' to batched annex BatchedAnnex(annex_cmd='addurl', annex_options=['--with-files', '--json'], git_options=[], output_proc=<function>, path=<<'/home/yoh/.tmp/datala...>>) (annexrepo.py:1202)
+2016-04-26 14:13:05,548 [Level 5] Done sending. (annexrepo.py:1210)
+2016-04-26 14:13:05,869 [DEBUG] Importing the rest of datalad.__init__ (__init__.py:15)
+2016-04-26 14:13:05,870 [DEBUG] Reading files: ['/etc/datalad/datalad.cfg', '/etc/xdg/datalad/config', '/home/yoh/.config/datalad/datalad.cfg', '.datalad/config'] (configparserinc.py:144)
+2016-04-26 14:13:05,959 [DEBUG] UI set to ConsoleLog(out=<file>) (__init__.py:48)
+2016-04-26 14:13:05,960 [DEBUG] UI set to UnderAnnexUI(out=<file>) (__init__.py:48)
+2016-04-26 14:13:05,962 [DEBUG] Not initiating existing cache for the archives under /tmp/datalad_temp_tree_setupmRy8cc/.git/datalad/tmp/archives (archives.py:262)
+2016-04-26 14:13:05,962 [Level 4] Sending 'VERSION 1' (base.py:312)
+2016-04-26 14:13:05,962 [Level 4] Received ['PREPARE'] (base.py:312)
+2016-04-26 14:13:05,962 [Level 4] Sending 'PREPARE-SUCCESS' (base.py:312)
+2016-04-26 14:13:05,962 [Level 4] Received ['CLAIMURL', 'dl+archive:SHA256E-s10240--0d52ce580b5ea9324dfc2ac7c714130f02499439e6b990282adb6580a97fe1d0.tar/1/file.txt#size=4'] (base.py:312)
+2016-04-26 14:13:05,963 [DEBUG] Claiming url 'dl+archive:SHA256E-s10240--0d52ce580b5ea9324dfc2ac7c714130f02499439e6b990282adb6580a97fe1d0.tar/1/file.txt#size=4' (base.py:316)
+2016-04-26 14:13:05,963 [Level 4] Sending "DEBUG Claiming url 'dl+archive:SHA256E-s10240--0d52ce580b5ea9324dfc2ac7c714130f02499439e6b990282adb6580a97fe1d0.tar/1/file.txt#size=4'" (base.py:312)
+2016-04-26 14:13:05,963 [Level 4] Sending 'CLAIMURL-SUCCESS' (base.py:312)
+2016-04-26 14:13:05,963 [Level 4] Received ['CHECKURL', 'dl+archive:SHA256E-s10240--0d52ce580b5ea9324dfc2ac7c714130f02499439e6b990282adb6580a97fe1d0.tar/1/file.txt#size=4'] (base.py:312)
+2016-04-26 14:13:05,964 [DEBUG] Current directory: /tmp/datalad_temp_tree_setupmRy8cc, url: dl+archive:SHA256E-s10240--0d52ce580b5ea9324dfc2ac7c714130f02499439e6b990282adb6580a97fe1d0.tar/1/file.txt#size=4 (archives.py:163)
+2016-04-26 14:13:05,964 [DEBUG] Initiating a new process for BatchedAnnex(annex_cmd='contentlocation', annex_options=[], git_options=[], output_proc=<function>, path=<<'/tmp/datalad_temp_tre...>>) (annexrepo.py:1145)
+2016-04-26 14:13:05,964 [Level 5] Command: ['git', '-c', 'receive.autogc=0', '-c', 'gc.auto=0', 'annex', 'contentlocation', '--batch'] (annexrepo.py:1148)
+2016-04-26 14:13:05,967 [Level 5] Sending 'SHA256E-s10240--0d52ce580b5ea9324dfc2ac7c714130f02499439e6b990282adb6580a97fe1d0.tar\n' to batched annex BatchedAnnex(annex_cmd='contentlocation', annex_options=[], git_options=[], output_proc=<function>, path=<<'/tmp/datalad_temp_tre...>>) (annexrepo.py:1202)
+2016-04-26 14:13:05,967 [Level 5] Done sending. (annexrepo.py:1210)
+2016-04-26 14:13:06,007 [Level 5] Received output: '.git/annex/objects/7p/mj/SHA256E-s10240--0d52ce580b5ea9324dfc2ac7c714130f02499439e6b990282adb6580a97fe1d0.tar/SHA256E-s10240--0d52ce580b5ea9324dfc2ac7c714130f02499439e6b990282adb6580a97fe1d0.tar' (annexrepo.py:1220)
+2016-04-26 14:13:06,008 [Level 4] Sending 'CHECKURL-CONTENTS 4' (base.py:312)
+2016-04-26 14:13:06,009 [Level 4] Received ['TRANSFER', 'RETRIEVE', 'URL-s4--dl,43archive:SHA256E-s10240--0d-d5401228f11172416c78bab2f3f31f61', '.git/annex/tmp/URL-s4--dl,43archive&cSHA256E-s10240--0d-d5401228f11172416c78bab2f3f31f61'] (base.py:312)
+2016-04-26 14:13:06,009 [INFO] RETRIEVE key URL-s4--dl,43archive:SHA256E-s10240--0d-d5401228f11172416c78bab2f3f31f61 into/from .git/annex/tmp/URL-s4--dl,43archive&cSHA256E-s10240--0d-d5401228f11172416c78bab2f3f31f61 (base.py:429)
+2016-04-26 14:13:06,009 [Level 4] Sending 'GETURLS URL-s4--dl,43archive:SHA256E-s10240--0d-d5401228f11172416c78bab2f3f31f61 dl+archive:' (base.py:312)
+2016-04-26 14:13:06,011 [Level 4] Received ['VALUE', 'dl+archive:SHA256E-s10240--0d52ce580b5ea9324dfc2ac7c714130f02499439e6b990282adb6580a97fe1d0.tar/1/file.txt#size=4'] (base.py:312)
+2016-04-26 14:13:06,011 [Level 4] Received ['VALUE'] (base.py:312)
+2016-04-26 14:13:06,011 [Level 4] Received URLS: ['dl+archive:SHA256E-s10240--0d52ce580b5ea9324dfc2ac7c714130f02499439e6b990282adb6580a97fe1d0.tar/1/file.txt#size=4'] (base.py:312)
+2016-04-26 14:13:06,011 [DEBUG] Getting file 1/file.txt from /tmp/datalad_temp_tree_setupmRy8cc/.git/annex/objects/7p/mj/SHA256E-s10240--0d52ce580b5ea9324dfc2ac7c714130f02499439e6b990282adb6580a97fe1d0.tar/SHA256E-s10240--0d52ce580b5ea9324dfc2ac7c714130f02499439e6b990282adb6580a97fe1d0.tar while PWD=/tmp/datalad_temp_tree_setupmRy8cc (archives.py:299)
+2016-04-26 14:13:06,011 [DEBUG] Requested file 1/file.txt from archive /tmp/datalad_temp_tree_setupmRy8cc/.git/annex/objects/7p/mj/SHA256E-s10240--0d52ce580b5ea9324dfc2ac7c714130f02499439e6b990282adb6580a97fe1d0.tar/SHA256E-s10240--0d52ce580b5ea9324dfc2ac7c714130f02499439e6b990282adb6580a97fe1d0.tar (archives.py:454)
+2016-04-26 14:13:06,012 [Level 2] Verifying that /tmp/datalad_temp_tree_setupmRy8cc/.git/datalad/tmp/archives/60e44d2ccc/1/file.txt exists (archives.py:462)
+2016-04-26 14:13:06,012 [DEBUG] Hardlinking /tmp/datalad_temp_tree_setupmRy8cc/.git/datalad/tmp/archives/60e44d2ccc/1/file.txt under .git/annex/tmp/URL-s4--dl,43archive&cSHA256E-s10240--0d-d5401228f11172416c78bab2f3f31f61 (cmd.py:372)
+2016-04-26 14:13:06,012 [Level 2] Hardlinking finished (cmd.py:382)
+2016-04-26 14:13:06,012 [Level 4] Sending 'TRANSFER-SUCCESS RETRIEVE URL-s4--dl,43archive:SHA256E-s10240--0d-d5401228f11172416c78bab2f3f31f61' (base.py:312)
+2016-04-26 14:13:06,022 [Level 5] Received output: {u'note': u'from datalad-archives', u'success': True, u'command': u'addurl', u'key': u'SHA256E-s4--0cf67fc72b3c86c7a454f6d86b43ed245a8e491d0e5288d4da8c7ff43a7bcdb0.txt', u'file': u'.dataladMCsP4y/file.txt'} (annexrepo.py:1220)
+2016-04-26 14:13:06,023 [DEBUG  ] Running: ['git', '-c', 'receive.autogc=0', '-c', 'gc.auto=0', '-c', 'annex.alwayscommit=false', 'annex', 'drop', '--debug', '.dataladMCsP4y/file.txt'] (cmd.py:351)
+2016-04-26 14:13:06,075 [ERROR  ] stderr| [2016-04-26 14:13:06.069266] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","ls-files","--cached","-z","--",".dataladMCsP4y/file.txt"] (cmd.py:351)
+2016-04-26 14:13:06,075 [Level 8] Finished running ['git', '-c', 'receive.autogc=0', '-c', 'gc.auto=0', '-c', 'annex.alwayscommit=false', 'annex', 'drop', '--debug', '.dataladMCsP4y/file.txt'] with status 0 (cmd.py:351)
+t sh
+
+"""]]
+
+
+[[!meta author=yoh]]

Added a comment
diff --git a/doc/bugs/Non-annexed_files_being_annexed_and_not_stored/comment_2_6d73b11c55e7b2ed4003e1908558426d._comment b/doc/bugs/Non-annexed_files_being_annexed_and_not_stored/comment_2_6d73b11c55e7b2ed4003e1908558426d._comment
new file mode 100644
index 0000000..a71e380
--- /dev/null
+++ b/doc/bugs/Non-annexed_files_being_annexed_and_not_stored/comment_2_6d73b11c55e7b2ed4003e1908558426d._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="xloem"
+ subject="comment 2"
+ date="2016-04-25T21:25:58Z"
+ content="""
+The checksum of a file is the same as the generated symlink name.  
+For a file which had the issue, `git annex log` appears empty.
+I used `git checkout [revision] [filename]` to get the old version of the file in the newly versioned repo, not sure if that would confuse `git annex log`.
+
+"""]]

Added a comment: did this today
diff --git a/doc/forum/n00b_question._Can_I_use_git-annex_to_manage_a_tree_that_contains_git_repos__63__/comment_4_9c6386710387f7334ea44c1de7cc8729._comment b/doc/forum/n00b_question._Can_I_use_git-annex_to_manage_a_tree_that_contains_git_repos__63__/comment_4_9c6386710387f7334ea44c1de7cc8729._comment
new file mode 100644
index 0000000..a411d8d
--- /dev/null
+++ b/doc/forum/n00b_question._Can_I_use_git-annex_to_manage_a_tree_that_contains_git_repos__63__/comment_4_9c6386710387f7334ea44c1de7cc8729._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="xloem"
+ subject="did this today"
+ date="2016-04-25T20:40:02Z"
+ content="""
+it's interesting to find this discussion, I just finished implementing this on my system.
+
+I've been storing bare repos in annex in order to back them up with the same system.  I have really huge files in some of my git repos and I wanted to get those files into the annex system but still keep a record of their changes (the git history).
+
+Today I removed the core.bare = true setting on the repos and instead set core.worktree = projectdir, and ran git checkout in projectdir.  I have the index file in .gitignore, so there won't be that weird unresolvable conflict.  Now all my bloated git history is stored in the annex, and I can still work with it in the annexed checkout.
+
+I was thinking I'd do this again with the root of the repository when the annex grows too large, to back up the old history in a connected way.
+"""]]

Added a comment
diff --git a/doc/todo/add_option_to_whereis_to_avoid_network_interactions/comment_2_a11a283ca2f3b37502bece27a84ab71b._comment b/doc/todo/add_option_to_whereis_to_avoid_network_interactions/comment_2_a11a283ca2f3b37502bece27a84ab71b._comment
new file mode 100644
index 0000000..041b590
--- /dev/null
+++ b/doc/todo/add_option_to_whereis_to_avoid_network_interactions/comment_2_a11a283ca2f3b37502bece27a84ab71b._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://me.yahoo.com/a/EbvxpTI_xP9Aod7Mg4cwGhgjrCrdM5s-#7c0f4"
+ subject="comment 2"
+ date="2016-04-25T18:28:14Z"
+ content="""
+gotcha... indeed, after allowing annex to fetch uuid for it and adjust .git/config it doesn't go over ssh during whereis.
+I don't have a strong use case yet to further support --no-network or alike for whereis ATM so feel free  to close, but I am afraid it might bite me again later whenever I wouldn't expect any demand from annex/ssh for interactive prompts while running some command which doesn't usually require interaction (e.g. whereis) due to querying remote locations.
+"""]]

comment
diff --git a/doc/todo/add_option_to_whereis_to_avoid_network_interactions/comment_1_19442ed153aafb025065ede3a8fe94c6._comment b/doc/todo/add_option_to_whereis_to_avoid_network_interactions/comment_1_19442ed153aafb025065ede3a8fe94c6._comment
new file mode 100644
index 0000000..1066455
--- /dev/null
+++ b/doc/todo/add_option_to_whereis_to_avoid_network_interactions/comment_1_19442ed153aafb025065ede3a8fe94c6._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-04-25T17:44:59Z"
+ content="""
+This is not specific to whereis at all. You have added a new git remote and
+git-annex does not know what the uuid of it is. Until it can find out, it
+won't be able to use that remote (including referring to it in whereis
+output). So, git-annex always tries to get the uuid for such remotes
+at startup time.
+
+If you don't want git-annex to use this remote, you can set
+remote.name.annex-ignore.
+"""]]

devblog
diff --git a/doc/devblog/day_386__day_off.mdwn b/doc/devblog/day_386__day_off.mdwn
new file mode 100644
index 0000000..ae73307
--- /dev/null
+++ b/doc/devblog/day_386__day_off.mdwn
@@ -0,0 +1,12 @@
+I'm on a long weekend. This did not prevent git-annex from getting an
+impressive lot of features though, as Daniel Dent contributed
+<https://github.com/DanielDent/git-annex-remote-rclone> which uses
+[rclone](http://rclone.org/) to add support for a ton of additional cloud
+storage things, including: 
+
+Google Drive, Openstack Swift, Rackspace cloud files, Memset Memstore, Dropbox,
+Google Cloud Storage, Amazon Cloud Drive, Microsoft One Drive, Hubic, Backblaze
+B2, Yandex Disk
+
+Wow! I hope that rclone will end up packaged in more distributions (eg Debian)
+so this will be easier to set up.

close todos covered by rclone
diff --git a/doc/todo/Amazon_Cloud_Drive.mdwn b/doc/todo/Amazon_Cloud_Drive.mdwn
index 4bef053..7ec91b4 100644
--- a/doc/todo/Amazon_Cloud_Drive.mdwn
+++ b/doc/todo/Amazon_Cloud_Drive.mdwn
@@ -16,3 +16,8 @@ http://techcrunch.com/2015/03/26/amazon-goes-after-dropbox-google-microsoft-with
 > > Don't know if there's such a thing... there seems to be SDKs for android and IOS, but nothing more. It seems like it's a REST API: https://developer.amazon.com/public/apis/experience/cloud-drive/... --[[anarcat]]
 
 >> requested it be added to amazonka <https://github.com/brendanhay/amazonka/issues/168> --[[Joey]]
+
+>>> In the meantime, <https://github.com/DanielDent/git-annex-remote-rclone> supports Amazon Cloud drive.
+>>> I may revisit adding support for it directly to git-annex if amazonka
+>>> does get support, but for now, that seems good enough, so [[done]]
+>>> --[[Joey]]
diff --git a/doc/todo/wishlist__58___swift_backend.mdwn b/doc/todo/wishlist__58___swift_backend.mdwn
index 28bd265..6c1cef5 100644
--- a/doc/todo/wishlist__58___swift_backend.mdwn
+++ b/doc/todo/wishlist__58___swift_backend.mdwn
@@ -3,3 +3,10 @@
 I can provide a test account soonish if need be, else rackspace.com if offering swift storage. Their API gateway lives at https://auth.api.rackspacecloud.com/v1.0
 
 Richard
+
+> Swift is supported by
+> <https://github.com/DanielDent/git-annex-remote-rclone>
+> 
+> While I am not opposed to adding support for swift directly to git-annex,
+> if a haskell library supporting it should appear, I think that's good
+> enough so am calling this [[done]] --[[Joey]]

clarify tha DIRHASH returns mixed case
Maybe not the best thing that it does, but it can't really be changed w/o
breaking existing remotes.
diff --git a/doc/design/external_special_remote_protocol.mdwn b/doc/design/external_special_remote_protocol.mdwn
index 0fe18f0..f9eca2a 100644
--- a/doc/design/external_special_remote_protocol.mdwn
+++ b/doc/design/external_special_remote_protocol.mdwn
@@ -228,7 +228,7 @@ in control.
   This is highly recommended for STORE. (It is optional but good for RETRIEVE.)  
   (git-annex does not send a reply to this message.)
 * `DIRHASH Key`  
-  Gets a two level hash associated with a Key. Something like "abc/def".
+  Gets a two level hash associated with a Key. Something like "aB/Cd".
   This is always the same for any given Key, so can be used for eg,
   creating hash directory structures to store Keys in.  
   (git-annex replies with VALUE followed by the value.)

initial whining
diff --git a/doc/todo/drop_--batch.mdwn b/doc/todo/drop_--batch.mdwn
new file mode 100644
index 0000000..68c7a5a
--- /dev/null
+++ b/doc/todo/drop_--batch.mdwn
@@ -0,0 +1,3 @@
+There is a dropkey --batch, so I guess I could workaround but probably would be nice for consistency to have --batch mode for drop itself as well
+
+[[!meta author=yoh]]

Added a comment
diff --git a/doc/bugs/standalone_builds_shouldn__39__t_pollute___126____47__.ssh_with_helpers_merely_upon_annex_init/comment_4_1b0fcf589429f6b36bf405bf9b1610b5._comment b/doc/bugs/standalone_builds_shouldn__39__t_pollute___126____47__.ssh_with_helpers_merely_upon_annex_init/comment_4_1b0fcf589429f6b36bf405bf9b1610b5._comment
new file mode 100644
index 0000000..d14d8c1
--- /dev/null
+++ b/doc/bugs/standalone_builds_shouldn__39__t_pollute___126____47__.ssh_with_helpers_merely_upon_annex_init/comment_4_1b0fcf589429f6b36bf405bf9b1610b5._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="https://me.yahoo.com/a/EbvxpTI_xP9Aod7Mg4cwGhgjrCrdM5s-#7c0f4"
+ subject="comment 4"
+ date="2016-04-25T17:21:26Z"
+ content="""
+ok -- getting back to this issue.  What about at least the debian standalone package patching (or option?) annex so it installs them under /usr/bin/ by the package?
+"""]]

diff --git a/doc/bugs/adjusted_branches_on_windows__58___file_paths_get_messed_up_when_commiting_to_an_adjusted_branch.mdwn b/doc/bugs/adjusted_branches_on_windows__58___file_paths_get_messed_up_when_commiting_to_an_adjusted_branch.mdwn
new file mode 100644
index 0000000..261293f
--- /dev/null
+++ b/doc/bugs/adjusted_branches_on_windows__58___file_paths_get_messed_up_when_commiting_to_an_adjusted_branch.mdwn
@@ -0,0 +1,67 @@
+### Please describe the problem.
+
+I'm testing whether I can use git-annex to sync binary files to a windows vm (used for development) with v6 adjusted branches.
+
+For testing I use git-annex precompiled binaries for windows, together with git from [msys2](https://sourceforge.net/projects/msys2/), an environment similar to cygwin (it does the usual hacks with path translation, etc).
+
+It seems to more or less work for syncing content from my linux box to the vm, apart from some unexplained clean/smudge errors, which I'll investigate later.
+
+However, when I commit to the adjusted branch in the windows vm, and afterwards do a `git annex sync` to propagate changes to the unadjusted `master`, a broken link for the annexed file `A/B` ends up at the root of the repository in the unadjusted branch.
+
+
+### What steps will reproduce the problem?
+
+On windows under msys2 do the following:
+
+* Create a v6 annex repo with an adjusted branch.
+* Annex a file in a subdirectory, for example `A/B`.
+* Commit to the adjusted branch.
+* Propagate changes to the original branch.
+
+A file `B` appears in the non-adjusted branch, instead of `A/B`, with broken link (as if it still were in A/B).
+
+### What version of git-annex are you using? On what operating system?
+
+git annex 6.20160418 windows precompiled binaries on windows 10 under msys2. msys2 git is 2.8.1. I haven't tested with other windows git distributions.
+
+
+### Please provide any additional information below.
+
+Here is a shell transcript while reproducing this
+
+[[!format sh """
+$ mkdir test; cd test
+$ git init
+$ git annex init --version=6
+# it automatically puts you in an adjusted master, because of crippled filesystem...
+$ git branch
+* adjusted/master(unlocked)
+  git-annex
+  master
+
+$ mkdir A
+$ echo "b" > A/B
+$ git annex add A/B
+$ git commit -m 'annexed A/B'
+$ git ls-tree -r --name-only 'adjusted/master(unlocked)'
+A/B
+$ git ls-tree -r --name-only 'master'
+
+$ git annex sync
+commit
+On branch adjusted/master(unlocked)
+nothing to commit, working directory clean
+ok
+
+$ git ls-files -r --name-only 'adjusted/master(unlocked)'
+A/B
+$ git ls-files -r --name-only 'master'
+B
+"""]]
+
+### 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)
+
+Well, git-annex is wonderful!
+
+I use it to sync binary files across linux boxes, I use it for binary distro packages I compile for myself, for my calibre books, pictures, movies...  and I'm very happy with it on linux.
+

Fixed broken link to standard groups page
diff --git a/doc/git-annex-preferred-content.mdwn b/doc/git-annex-preferred-content.mdwn
index 4dd484e..a8d2efe 100644
--- a/doc/git-annex-preferred-content.mdwn
+++ b/doc/git-annex-preferred-content.mdwn
@@ -154,7 +154,7 @@ elsewhere to allow removing it).
 * `standard`
 
   git-annex comes with some built-in preferred content expressions, that
-  can be used with repositories that are in some [[standard groups]].
+  can be used with repositories that are in some [[preferred content/standard groups/]].
 
   When a repository is in exactly one such group, you can use the "standard"
   keyword in its preferred content expression, to match whatever content

Added a comment
diff --git a/doc/bugs/startup_scan_extremely_slow/comment_5_4ee924e70d5a8e35e706eaaff4cc76e1._comment b/doc/bugs/startup_scan_extremely_slow/comment_5_4ee924e70d5a8e35e706eaaff4cc76e1._comment
new file mode 100644
index 0000000..d0fa072
--- /dev/null
+++ b/doc/bugs/startup_scan_extremely_slow/comment_5_4ee924e70d5a8e35e706eaaff4cc76e1._comment
@@ -0,0 +1,28 @@
+[[!comment format=mdwn
+ username="zarel"
+ subject="comment 5"
+ date="2016-04-24T15:31:05Z"
+ content="""
+I exported GIT_TRACE and discovered that the assistant is re-adding to git the small files everytime I run it.
+Below there's a link to the trace (with filenames removed). All the files are not matching the annex.largefiles expression (which is okay), there are no duplicates (i.e. it's not a \"I'm adding the same files in the same run\" problem) and all of them were already added the first time I ran the assistant and are not new to git and git-annex as they are not shown in \"git status\" or in \"git annex status\".
+
+The daemon.log is pretty brief:
+
+    [2016-04-24 12:49:31.129582] main: starting assistant version 6.20160418
+    
+      No known network monitor available through dbus; falling back to polling
+    (scanning...) [2016-04-24 12:49:55.098167] Watcher: Performing startup scan
+    [2016-04-24 12:58:51.667861] Committer: Committing changes to git
+    (recording state in git...)
+    [2016-04-24 13:08:25.154713] Committer: Committing changes to git
+    (recording state in git...)
+
+You can find the trace here: <https://gist.github.com/zarelit/815de89d972314f2e6495a2cdab91aca>
+
+As you can see it almost takes ten minutes before reaching the first git-add.
+
+My git-annex version is now 6.20160418 and the git one is 2.8.0, what version of git did you use when tracing? I can try to reproduce in a different environment (e.g. Debian stable with backports) if it can be useful.
+
+Cheers,
+David
+"""]]

Added a comment
diff --git a/doc/devblog/day_385__new_features/comment_1_f76ff85897f24692e96f88236b7f4b7d._comment b/doc/devblog/day_385__new_features/comment_1_f76ff85897f24692e96f88236b7f4b7d._comment
new file mode 100644
index 0000000..91d4b2d
--- /dev/null
+++ b/doc/devblog/day_385__new_features/comment_1_f76ff85897f24692e96f88236b7f4b7d._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="CandyAngel"
+ subject="comment 1"
+ date="2016-04-24T10:56:01Z"
+ content="""
+    git-annex reinject --known can be passed a list of files and it will reinject any that hash to known annexed contents and ignore the rest.
+
+I **so** can't wait for this to get released, it will save so much time for me!
+
+Thank you Joey ^_^
+"""]]

added rclone supported providers
diff --git a/doc/special_remotes.mdwn b/doc/special_remotes.mdwn
index 3e3ae21..2d99069 100644
--- a/doc/special_remotes.mdwn
+++ b/doc/special_remotes.mdwn
@@ -29,6 +29,7 @@ for using git-annex with various services:
 
 * [[Amazon_S3|tips/using_Amazon_S3]]
 * [[Amazon_Glacier|tips/using_Amazon_Glacier]]
+* [Amazon Cloud drive](https://github.com/DanielDent/git-annex-remote-rclone)
 * [[tips/Internet_Archive_via_S3]]
 * [[Box.com|tips/using_box.com_as_a_special_remote]]
 * [[Google drive|tips/googledriveannex]]
@@ -44,7 +45,11 @@ for using git-annex with various services:
 * [pCloud](https://github.com/tochev/git-annex-remote-pcloud)
 * [[ipfs]]
 * [Ceph](https://github.com/mhameed/git-annex-remote-ceph)
-* [Blackblaze's B2](https://github.com/encryptio/git-annex-remote-b2)
+* [Backblaze's B2](https://github.com/encryptio/git-annex-remote-b2)
+* [Dropbox](https://github.com/DanielDent/git-annex-remote-rclone)
+* [Openstack Swift / Rackspace cloud files / Memset Memstore](https://github.com/DanielDent/git-annex-remote-rclone)
+* [Microsoft One Drive](https://github.com/DanielDent/git-annex-remote-rclone)
+* [Yandex Disk](https://github.com/DanielDent/git-annex-remote-rclone)
 
 Want to add support for something else? [[Write your own!|external]]
 

made link a link
diff --git a/doc/todo/Amazon_Cloud_Drive.mdwn b/doc/todo/Amazon_Cloud_Drive.mdwn
index 759fb39..4bef053 100644
--- a/doc/todo/Amazon_Cloud_Drive.mdwn
+++ b/doc/todo/Amazon_Cloud_Drive.mdwn
@@ -1,4 +1,4 @@
-I've released a special remote which uses rclone to enable Amazon Cloud Drive: https://github.com/DanielDent/git-annex-remote-rclone -- [[DanielDent]]
+I've released a special remote which uses rclone to enable Amazon Cloud Drive: <https://github.com/DanielDent/git-annex-remote-rclone> -- [[DanielDent]]
 
 ---
 

mentioned git-annex-remote-rclone
diff --git a/doc/todo/Amazon_Cloud_Drive.mdwn b/doc/todo/Amazon_Cloud_Drive.mdwn
index 501c9fa..759fb39 100644
--- a/doc/todo/Amazon_Cloud_Drive.mdwn
+++ b/doc/todo/Amazon_Cloud_Drive.mdwn
@@ -1,3 +1,7 @@
+I've released a special remote which uses rclone to enable Amazon Cloud Drive: https://github.com/DanielDent/git-annex-remote-rclone -- [[DanielDent]]
+
+---
+
 Is there a special remote implementation for Amazon Cloud Drive?
 
 It's just became unlimited for a fair price: $60/year ( https://www.amazon.com/clouddrive/pricing ).

Added a comment: Further information
diff --git a/doc/bugs/Android_chroot_stuck_in_Cabal_hell/comment_3_6e13c53def5da8d903b220522bbd23ba._comment b/doc/bugs/Android_chroot_stuck_in_Cabal_hell/comment_3_6e13c53def5da8d903b220522bbd23ba._comment
new file mode 100644
index 0000000..7ebe536
--- /dev/null
+++ b/doc/bugs/Android_chroot_stuck_in_Cabal_hell/comment_3_6e13c53def5da8d903b220522bbd23ba._comment
@@ -0,0 +1,30 @@
+[[!comment format=mdwn
+ username="divergentdave@5c17d06f6d67c6f157b76a4cc95ca764b7d2f899"
+ nickname="divergentdave"
+ subject="Further information"
+ date="2016-04-23T18:31:23Z"
+ content="""
+I did some further testing, but I'm still stumped. If I run `cabal configure -O0 -fAndroidSplice --ghc-options=-v`, I get the following items in the resulting log file. (trimmed for space)
+
+```
+Glasgow Haskell Compiler, Version 7.6.3, stage 2 booted by GHC version 7.6.3
+Using binary package database: /usr/lib/ghc/package.conf.d/package.cache
+Using binary package database: /home/builder/.ghc/i386-linux-7.6.3/package.conf.d/package.cache
+...
+hiding package unix-2.6.0.1 to avoid conflict with later version unix-2.7.1.0
+...
+Chasing modules from: *dist/setup/setup.hs
+Created temporary directory: /tmp/ghc1639_0
+*** C pre-processor:
+'/usr/bin/gcc' '-E' '-undef' '-traditional' '-fno-stack-protector' '-Wl,--hash-size=31' '-Wl,--reduce-memory-overheads' ... '-I' '/usr/lib/ghc/unix-2.6.0.1/include' ... '-x' 'c' './Common.hs' '-o' '/tmp/ghc1639_0/ghc1639_0.hscpp'
+...
+*** Linker:
+'/usr/bin/gcc' ... '-L/home/builder/.cabal/lib/i386-linux-ghc-7.6.3/unix-2.7.1.0' ... '-L/usr/lib/ghc/unix-2.6.0.1' ... '-lHSunix-2.7.1.0' ... '-lHSunix-2.6.0.1' ...
+/usr/lib/ghc/unix-2.6.0.1/libHSunix-2.6.0.1.a(execvpe.o): In function `pPrPr_disableITimers':
+(.text+0x300): multiple definition of `pPrPr_disableITimers'
+/home/builder/.cabal/lib/i386-linux-ghc-7.6.3/unix-2.7.1.0/libHSunix-2.7.1.0.a(ghcrts.o):ghcrts.c:(.text+0x0): first defined here
+collect2: error: ld returned 1 exit status
+```
+
+I'm not sure what \"hiding\" means in the context of GHC, but clearly it isn't working.
+"""]]

diff --git a/doc/forum/Assistant_fails_to_authenticate_to_rsync_remote.mdwn b/doc/forum/Assistant_fails_to_authenticate_to_rsync_remote.mdwn
new file mode 100644
index 0000000..29a8515
--- /dev/null
+++ b/doc/forum/Assistant_fails_to_authenticate_to_rsync_remote.mdwn
@@ -0,0 +1,17 @@
+I have an rsync special remote for rsync.net. Recently I noticed that the assistant was not uploading files to this remote. When I look at the log in the webapp I see that it fails to authenticate:
+
+    [2016-04-22 13:28:49.145178] NetWatcherFallback: Syncing with rsync.net
+    Permission denied, please try again.
+    Permission denied, please try again.
+    Received disconnect from 1.1.1.1 port 22:2: Too many authentication failures for 12345
+    Connection to host.rsync.net closed by remote host.
+    rsync: connection unexpectedly closed (0 bytes received so far) [sender]
+    rsync error: unexplained error (code 255) at io.c(226) [sender=3.1.2]
+
+(For privacy I replaced the IP of the rsync.net host with 1.1.1.1 and the numerical user with 12345 and the hostname with host.rsync.net. In the actual log output those 3 things have real values that are correct!)
+
+If I change into this annex in the terminal I can `git annex copy . --to rsync.net` and everything uploads properly, so it is just the assistant which is failing to authenticate. I'm not sure how to go about troubleshooting this. I do use an ssh key to authenticate to the remote. Maybe the assistant doesn't know about this key?
+
+I did create this repo and add the remote manually, only later telling the assistant about the repo through the webapp.
+
+What should I look into to debug this?

Added a comment
diff --git a/doc/forum/Using_integer_ranges_with_metadata/comment_6_ead2b08bf4631547c34486ce58559017._comment b/doc/forum/Using_integer_ranges_with_metadata/comment_6_ead2b08bf4631547c34486ce58559017._comment
new file mode 100644
index 0000000..785b0e4
--- /dev/null
+++ b/doc/forum/Using_integer_ranges_with_metadata/comment_6_ead2b08bf4631547c34486ce58559017._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="cstork"
+ subject="comment 6"
+ date="2016-04-23T16:43:11Z"
+ content="""
+Thanks a lot!
+"""]]

Added a comment
diff --git a/doc/tips/what_to_do_when_you_lose_a_repository/comment_8_596bcfa25a4fa6e81bb6a0940c55a2f2._comment b/doc/tips/what_to_do_when_you_lose_a_repository/comment_8_596bcfa25a4fa6e81bb6a0940c55a2f2._comment
new file mode 100644
index 0000000..addeccb
--- /dev/null
+++ b/doc/tips/what_to_do_when_you_lose_a_repository/comment_8_596bcfa25a4fa6e81bb6a0940c55a2f2._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="fiatjaf"
+ subject="comment 8"
+ date="2016-04-23T15:01:23Z"
+ content="""
+I've issued `git annex dead` for a full git-annex repo (not a special remote) I had in a VPS, but my local machine keeps trying to sync with it on `git annex sync`, asking me to confirm the ssh public key and so on. Is that correct?
+"""]]

poll vote (Tahoe-LAFS)
diff --git a/doc/design/assistant/polls/prioritizing_special_remotes.mdwn b/doc/design/assistant/polls/prioritizing_special_remotes.mdwn
index eaf7d61..72e0e71 100644
--- a/doc/design/assistant/polls/prioritizing_special_remotes.mdwn
+++ b/doc/design/assistant/polls/prioritizing_special_remotes.mdwn
@@ -6,7 +6,7 @@ locally paired systems, and remote servers with rsync.
 Help me prioritize my work: What special remote would you most like
 to use with the git-annex assistant?
 
-[[!poll open=yes 18 "Amazon S3 (done)" 13 "Amazon Glacier (done)" 10 "Box.com (done)" 77 "My phone (or MP3 player)" 28 "Tahoe-LAFS" 16 "OpenStack SWIFT" 37 "Google Drive"]]
+[[!poll open=yes 18 "Amazon S3 (done)" 13 "Amazon Glacier (done)" 10 "Box.com (done)" 77 "My phone (or MP3 player)" 29 "Tahoe-LAFS" 16 "OpenStack SWIFT" 37 "Google Drive"]]
 
 This poll is ordered with the options I consider easiest to build
 listed first. Mostly because git-annex already supports them and they

poll vote (My phone (or MP3 player))
diff --git a/doc/design/assistant/polls/prioritizing_special_remotes.mdwn b/doc/design/assistant/polls/prioritizing_special_remotes.mdwn
index 2e7cc07..eaf7d61 100644
--- a/doc/design/assistant/polls/prioritizing_special_remotes.mdwn
+++ b/doc/design/assistant/polls/prioritizing_special_remotes.mdwn
@@ -6,7 +6,7 @@ locally paired systems, and remote servers with rsync.
 Help me prioritize my work: What special remote would you most like
 to use with the git-annex assistant?
 
-[[!poll open=yes 18 "Amazon S3 (done)" 13 "Amazon Glacier (done)" 10 "Box.com (done)" 76 "My phone (or MP3 player)" 28 "Tahoe-LAFS" 16 "OpenStack SWIFT" 37 "Google Drive"]]
+[[!poll open=yes 18 "Amazon S3 (done)" 13 "Amazon Glacier (done)" 10 "Box.com (done)" 77 "My phone (or MP3 player)" 28 "Tahoe-LAFS" 16 "OpenStack SWIFT" 37 "Google Drive"]]
 
 This poll is ordered with the options I consider easiest to build
 listed first. Mostly because git-annex already supports them and they

diff --git a/doc/forum/difference_between_uninit_and_unlock.mdwn b/doc/forum/difference_between_uninit_and_unlock.mdwn
new file mode 100644
index 0000000..6f4d6de
--- /dev/null
+++ b/doc/forum/difference_between_uninit_and_unlock.mdwn
@@ -0,0 +1,10 @@
+What's the difference between
+
+    git annex uninit
+
+and 
+
+    git annex unlock *
+    rm -rf .git
+
+?

This reverts commit f7ced591d3fff090b1347f3971d70a5b146d5eda
diff --git a/doc/forum.mdwn b/doc/forum.mdwn
index 22944c9..e8a208d 100644
--- a/doc/forum.mdwn
+++ b/doc/forum.mdwn
@@ -1,10 +1,8 @@
-What's the difference between doing 
+This is a place to discuss using git-annex.
+If you need help, advice, or anything, post about it here.
 
-    git annex uninit
+But, please don't post bug reports here. Put them in [[bugs]].  
+And please don't make wishlist requests here. Put them in [[todo]].  
+(If you post bugs/todo here, it'll just get moved.)
 
-and 
-
-    git annex unlock *
-    rm -rf .git
-
-?
+[[!inline pages="forum/* and !*/Discussion" archive=yes rootpage=forum postformtext="Add a new thread titled:"]]

difference between uninit and unlock
diff --git a/doc/forum.mdwn b/doc/forum.mdwn
index e8a208d..22944c9 100644
--- a/doc/forum.mdwn
+++ b/doc/forum.mdwn
@@ -1,8 +1,10 @@
-This is a place to discuss using git-annex.
-If you need help, advice, or anything, post about it here.
+What's the difference between doing 
 
-But, please don't post bug reports here. Put them in [[bugs]].  
-And please don't make wishlist requests here. Put them in [[todo]].  
-(If you post bugs/todo here, it'll just get moved.)
+    git annex uninit
 
-[[!inline pages="forum/* and !*/Discussion" archive=yes rootpage=forum postformtext="Add a new thread titled:"]]
+and 
+
+    git annex unlock *
+    rm -rf .git
+
+?

mention jessie backports, use apt, and clarify neurodebian
diff --git a/doc/install/Debian.mdwn b/doc/install/Debian.mdwn
index ce928e5..55bbe3e 100644
--- a/doc/install/Debian.mdwn
+++ b/doc/install/Debian.mdwn
@@ -1,10 +1,18 @@
 ## Debian testing or unstable
 
-	sudo apt-get install git-annex
+Debian unstable and testing are usually fairly up to date, so this should be enough:
+
+	sudo apt install git-annex
 
 ## Debian 8.0 "jessie"
 
-	sudo apt-get install git-annex
+	sudo apt install git-annex
+
+There is also a backport for jessie, even though it is [often out of date](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=760787).
+
+Follow the instructions to [enable backports](http://backports.debian.org/Instructions/).
+
+	sudo apt -t jessie-backports install git-annex
 
 ## Debian 7.0 "wheezy":
 
@@ -23,7 +31,7 @@ Follow the instructions to [enable backports](http://backports.debian.org/Instru
 
 	sudo apt-get -t squeeze-backports install git-annex
 
-## backport
+## Standalone backports for all releases
 
 If the version shipped with Debian is too old, 
 the [NeuroDebian team](http://neuro.debian.net/) provides a

clarify the fix
diff --git a/doc/bugs/git_annex_get_fails_from_read-only_repository.mdwn b/doc/bugs/git_annex_get_fails_from_read-only_repository.mdwn
index 620005f..5440467 100644
--- a/doc/bugs/git_annex_get_fails_from_read-only_repository.mdwn
+++ b/doc/bugs/git_annex_get_fails_from_read-only_repository.mdwn
@@ -44,3 +44,5 @@ The remote repository is marked as read-only. The user on the remote has only re
 Yes! :-) Despite this, everything works like a charm with several repos on different OSs with lots of data. Thanks for this great tool!
 
 > [[fixed|done]] --[[Joey]]
+
+If others are in the same situation as me here, note that you only need to upgrade the server side of things to resolve this. The backports from neurodebian work it, you need something at least 6.201602XX. --[[anarcat]]

devblog
diff --git a/doc/devblog/day_385__new_features.mdwn b/doc/devblog/day_385__new_features.mdwn
new file mode 100644
index 0000000..a2ff3ed
--- /dev/null
+++ b/doc/devblog/day_385__new_features.mdwn
@@ -0,0 +1,16 @@
+Something that has come up repeatedly is that `git annex reinject` is
+too hard to use since you have to tell it which annexed file you're providing
+the content for. Now `git-annex reinject --known` can be passed a list of
+files and it will reinject any that hash to known annexed contents
+and ignore the rest. That works best when only one backend is used in a 
+repository; otherwise it would need to be run repeatedly with different
+`--backend` values.
+
+Turns out that the `GIT_COMMON_DIR` feature used by adjusted branches
+is only a couple years old, so don't let adjusted branches be used with
+a too old git.
+
+And, `git merge` is getting a new sanity check that prevents merging
+in a branch with a disconnected history. `git annex sync` will inherit that
+sanity check, but the assistant needs to let such merges happen when eg,
+pairing repositories, so more git version checking there.

response
diff --git a/doc/bugs/git-annex_smudge_fails_on_git_add/comment_6_237f8b3d8a8d2821a600aae5f5e05bef._comment b/doc/bugs/git-annex_smudge_fails_on_git_add/comment_6_237f8b3d8a8d2821a600aae5f5e05bef._comment
new file mode 100644
index 0000000..be806e8
--- /dev/null
+++ b/doc/bugs/git-annex_smudge_fails_on_git_add/comment_6_237f8b3d8a8d2821a600aae5f5e05bef._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 6"""
+ date="2016-04-22T20:02:27Z"
+ content="""
+Sure, email to id@joeyh.name or post a link to the file here.
+"""]]

move
diff --git a/doc/forum/n00b_question._Can_I_use_git-annex_to_manage_a_tree_that_contains_git_repos__63__/comment_2_f7416c26daca543ad08c11e187e1589e._comment b/doc/forum/n00b_question._Can_I_use_git-annex_to_manage_a_tree_that_contains_git_repos__63__/comment_2_f7416c26daca543ad08c11e187e1589e._comment
new file mode 100644
index 0000000..9ad9c73
--- /dev/null
+++ b/doc/forum/n00b_question._Can_I_use_git-annex_to_manage_a_tree_that_contains_git_repos__63__/comment_2_f7416c26daca543ad08c11e187e1589e._comment
@@ -0,0 +1,37 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""furthermore.."""
+ date="2016-04-22T18:52:09Z"
+ content="""
+You might also use <http://myrepos.branchable.com/> as a somewhat
+more flexible alternative to submodules.
+
+It's worth thinking about what would happen if you were able to check a git
+repository into a git (annex) repository. A git repository contains files
+like `.git/index` that are git internals, and binary files. Now what
+happens if you have two checkouts of that nested git-in-git repository, and
+git writes two different versions of the `.git/index` file? You'd get a
+merge conflict that you have no way of resolving, involving two versions of
+an internal use binary file. This is a lot worse than a merge conflict involving
+some regular binary file like a jpeg, because at least with jpegs you can
+look at the two versions of the file and pick the better one.
+
+While git prevents checking in `.git` directories, you could technically work
+around it, if you really wanted to, by eg using `GIT_DIR` to rename
+the `.git` directory to something else. But it's just setting yourself up for
+unresolvable merge conflicts and pain.
+
+It's likewise not good to check in other version control system
+directories, like `.svn`, `.bzr`, or `.hg` into git repositories or
+vice-versa.
+
+Sometimes people complain that the git-annex assistant should support
+syncing nested git repositories, because after all other directory syncing
+tools like dropbox support that. But, a little known fact about dropbox is
+that it too can end up with a conflicted merge type situation, and when
+this happens it will do *something* to auto-resolve it. That something
+almost certianly does not include leaving the git repository what was
+stored in dropbox in an ideal state. So, while people put git repos into
+dropbox and get away with it, they are just being lucky to not run into the
+edge cases where doing that blows up.
+"""]]
diff --git a/doc/forum/noob_question._VPS_web_assistant/comment_2_f7416c26daca543ad08c11e187e1589e._comment b/doc/forum/noob_question._VPS_web_assistant/comment_2_f7416c26daca543ad08c11e187e1589e._comment
deleted file mode 100644
index 8bb8633..0000000
--- a/doc/forum/noob_question._VPS_web_assistant/comment_2_f7416c26daca543ad08c11e187e1589e._comment
+++ /dev/null
@@ -1,37 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 2"""
- date="2016-04-22T18:52:09Z"
- content="""
-You might also use <http://myrepos.branchable.com/> as a somewhat
-more flexible alternative to submodules.
-
-It's worth thinking about what would happen if you were able to check a git
-repository into a git (annex) repository. A git repository contains files
-like `.git/index` that are git internals, and binary files. Now what
-happens if you have two checkouts of that nested git-in-git repository, and
-git writes two different versions of the `.git/index` file? You'd get a
-merge conflict that you have no way of resolving, involving two versions of
-an internal use binary file. This is a lot worse than a merge conflict involving
-some regular binary file like a jpeg, because at least with jpegs you can
-look at the two versions of the file and pick the better one.
-
-While git prevents checking in `.git` directories, you could technically work
-around it, if you really wanted to, by eg using `GIT_DIR` to rename
-the `.git` directory to something else. But it's just setting yourself up for
-unresolvable merge conflicts and pain.
-
-It's likewise not good to check in other version control system
-directories, like `.svn`, `.bzr`, or `.hg` into git repositories or
-vice-versa.
-
-Sometimes people complain that the git-annex assistant should support
-syncing nested git repositories, because after all other directory syncing
-tools like dropbox support that. But, a little known fact about dropbox is
-that it too can end up with a conflicted merge type situation, and when
-this happens it will do *something* to auto-resolve it. That something
-almost certianly does not include leaving the git repository what was
-stored in dropbox in an ideal state. So, while people put git repos into
-dropbox and get away with it, they are just being lucky to not run into the
-edge cases where doing that blows up.
-"""]]

comment
diff --git a/doc/forum/noob_question._VPS_web_assistant/comment_2_f7416c26daca543ad08c11e187e1589e._comment b/doc/forum/noob_question._VPS_web_assistant/comment_2_f7416c26daca543ad08c11e187e1589e._comment
new file mode 100644
index 0000000..8bb8633
--- /dev/null
+++ b/doc/forum/noob_question._VPS_web_assistant/comment_2_f7416c26daca543ad08c11e187e1589e._comment
@@ -0,0 +1,37 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2016-04-22T18:52:09Z"
+ content="""
+You might also use <http://myrepos.branchable.com/> as a somewhat
+more flexible alternative to submodules.
+
+It's worth thinking about what would happen if you were able to check a git
+repository into a git (annex) repository. A git repository contains files
+like `.git/index` that are git internals, and binary files. Now what
+happens if you have two checkouts of that nested git-in-git repository, and
+git writes two different versions of the `.git/index` file? You'd get a
+merge conflict that you have no way of resolving, involving two versions of
+an internal use binary file. This is a lot worse than a merge conflict involving
+some regular binary file like a jpeg, because at least with jpegs you can
+look at the two versions of the file and pick the better one.
+
+While git prevents checking in `.git` directories, you could technically work
+around it, if you really wanted to, by eg using `GIT_DIR` to rename
+the `.git` directory to something else. But it's just setting yourself up for
+unresolvable merge conflicts and pain.
+
+It's likewise not good to check in other version control system
+directories, like `.svn`, `.bzr`, or `.hg` into git repositories or
+vice-versa.
+
+Sometimes people complain that the git-annex assistant should support
+syncing nested git repositories, because after all other directory syncing
+tools like dropbox support that. But, a little known fact about dropbox is
+that it too can end up with a conflicted merge type situation, and when
+this happens it will do *something* to auto-resolve it. That something
+almost certianly does not include leaving the git repository what was
+stored in dropbox in an ideal state. So, while people put git repos into
+dropbox and get away with it, they are just being lucky to not run into the
+edge cases where doing that blows up.
+"""]]

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
new file mode 100644
index 0000000..f9516b5
--- /dev/null
+++ b/doc/todo/add_option_to_whereis_to_avoid_network_interactions.mdwn
@@ -0,0 +1,20 @@
+I thought that whereis command would report only based on the knowledge annex has locally in git-annex branch, but apparently it is trying to query for information even in --fast mode:
+
+[[!format sh """
+$> git annex whereis --fast bold.nii.gz
+yoh@dat....
+Permission denied (publickey,password).
+fatal: Could not read from remote repository.
+
+Please make sure you have the correct access rights
+and the repository exists.
+whereis bold.nii.gz 
+(2 copies) 
+  	899f0347-0888-48ef-91b6-bac213ca8cef -- [datalad-archives]
+   	c8bd3d05-33d4-4b59-9d53-ca7efbdcdd13 -- yoh@smaug:/mnt/btrfs/datasets/datalad/crawl/openfmri/ds000001 [here]
+
+  datalad-archives: dl+archive:MD5E-s2527262329--bd3ea399057c529b37b09dcecec1ca60.0raw.tgz/ds001_R1.1.0/sub001/BOLD/task001_run001/bold.nii.gz#size=47241449
+
+"""]]
+
+[[!meta author=yoh]]

Added a comment
diff --git a/doc/bugs/OSX_case_insensitive_filesystem/comment_6_f82c803d725829722842c6d54e388719._comment b/doc/bugs/OSX_case_insensitive_filesystem/comment_6_f82c803d725829722842c6d54e388719._comment
new file mode 100644
index 0000000..b65c078
--- /dev/null
+++ b/doc/bugs/OSX_case_insensitive_filesystem/comment_6_f82c803d725829722842c6d54e388719._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://id.clacke.se/"
+ nickname="clacke"
+ subject="comment 6"
+ date="2016-04-22T19:01:45Z"
+ content="""
+But it only checks the parameter at `annex init` time? What will the bad consequences be if it is set at other times?
+"""]]

response; improve docs
diff --git a/doc/bugs/OSX_case_insensitive_filesystem/comment_5_2123944418123c3aaf187d34df5c11e0._comment b/doc/bugs/OSX_case_insensitive_filesystem/comment_5_2123944418123c3aaf187d34df5c11e0._comment
new file mode 100644
index 0000000..e8c9c3e
--- /dev/null
+++ b/doc/bugs/OSX_case_insensitive_filesystem/comment_5_2123944418123c3aaf187d34df5c11e0._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2016-04-22T18:41:22Z"
+ content="""
+You should not set annex.tune.* globally. Only set it when
+initializing a new git-annex repo for the first time. Clones of the repo will
+automatically inherit the tunings.
+
+See [[tuning]].
+"""]]
diff --git a/doc/git-annex.mdwn b/doc/git-annex.mdwn
index 1b80fe0..236912d 100644
--- a/doc/git-annex.mdwn
+++ b/doc/git-annex.mdwn
@@ -1311,7 +1311,8 @@ Here are all the supported configuration settings.
 * `annex.tune.objecthash1`, `annex.tune.objecthashlower`, `annex.tune.branchhash1`
 
   These can be passed to `git annex init` to tune the repository.
-  They cannot be safely changed in a running repository.
+  They cannot be safely changed in a running repository and should never be
+  set in global git configuration.
   For details, see <https://git-annex.branchable.com/tuning/>.
 
 # CONFIGURATION VIA .gitattributes
diff --git a/doc/tuning.mdwn b/doc/tuning.mdwn
index ed3c90f..1860295 100644
--- a/doc/tuning.mdwn
+++ b/doc/tuning.mdwn
@@ -43,4 +43,5 @@ The following tuning parameters are available:
 
 Note that git-annex will automatically propagate these settings to
 `.git/config` for tuned repositories. You should never directly change
-these settings in `.git/config`
+these settings in `.git/config`, and should never set them in global
+gitconfig.

refactor
diff --git a/Command/Merge.hs b/Command/Merge.hs
index 908f3c1..4f19139 100644
--- a/Command/Merge.hs
+++ b/Command/Merge.hs
@@ -9,7 +9,7 @@ module Command.Merge where
 
 import Command
 import qualified Annex.Branch
-import Command.Sync (prepMerge, mergeLocal, getCurrBranch)
+import Command.Sync (prepMerge, mergeLocal, getCurrBranch, mergeConfig)
 
 cmd :: Command
 cmd = command "merge" SectionMaintenance
@@ -33,4 +33,4 @@ mergeBranch = do
 mergeSynced :: CommandStart
 mergeSynced = do
 	prepMerge
-	mergeLocal =<< join getCurrBranch
+	mergeLocal mergeConfig =<< join getCurrBranch
diff --git a/Command/Sync.hs b/Command/Sync.hs
index 3e68ad8..1169b95 100644
--- a/Command/Sync.hs
+++ b/Command/Sync.hs
@@ -10,6 +10,7 @@ module Command.Sync (
 	cmd,
 	CurrBranch,
 	getCurrBranch,
+	mergeConfig,
 	merge,
 	prepMerge,
 	mergeLocal,
@@ -112,8 +113,8 @@ seek o = allowConcurrentOutput $ do
 	-- These actions cannot be run concurrently.
 	mapM_ includeCommandAction $ concat
 		[ [ commit o ]
-		, [ withbranch mergeLocal ]
-		, map (withbranch . pullRemote o mergeconfig) gitremotes
+		, [ withbranch (mergeLocal mergeConfig) ]
+		, map (withbranch . pullRemote o mergeConfig) gitremotes
 		,  [ mergeAnnex ]
 		]
 	when (contentOption o) $
@@ -124,16 +125,14 @@ seek o = allowConcurrentOutput $ do
 			-- and merge again to avoid our push overwriting
 			-- those changes.
 			mapM_ includeCommandAction $ concat
-				[ map (withbranch . pullRemote o mergeconfig) gitremotes
+				[ map (withbranch . pullRemote o mergeConfig) gitremotes
 				, [ commitAnnex, mergeAnnex ]
 				]
 	
 	void $ includeCommandAction $ withbranch pushLocal
 	-- Pushes to remotes can run concurrently.
 	mapM_ (commandAction . withbranch . pushRemote o) gitremotes
-  where
-	mergeconfig = [Git.Merge.MergeNonInteractive]
-
+	
 type CurrBranch = (Maybe Git.Branch, Maybe Adjustment)
 
 {- There may not be a branch checked out until after the commit,
@@ -169,6 +168,9 @@ getCurrBranch = do
 prepMerge :: Annex ()
 prepMerge = Annex.changeDirectory =<< fromRepo Git.repoPath
 
+mergeConfig :: [Git.Merge.MergeConfig]	
+mergeConfig = [Git.Merge.MergeNonInteractive]
+
 merge :: CurrBranch -> [Git.Merge.MergeConfig] -> Git.Branch.CommitMode -> Git.Branch -> Annex Bool
 merge (Just b, Just adj) mergeconfig commitmode tomerge =
 	updateAdjustedBranch tomerge (b, adj) mergeconfig commitmode
@@ -246,8 +248,8 @@ commitStaged commitmode commitmessage = do
 	void $ inRepo $ Git.Branch.commit commitmode False commitmessage branch parents
 	return True
 
-mergeLocal :: CurrBranch -> CommandStart
-mergeLocal currbranch@(Just branch, madj) = go =<< needmerge
+mergeLocal :: [Git.Merge.MergeConfig] -> CurrBranch -> CommandStart
+mergeLocal mergeconfig currbranch@(Just branch, madj) = go =<< needmerge
   where
 	syncbranch = syncBranch branch
 	needmerge = ifM isBareRepo
@@ -260,9 +262,9 @@ mergeLocal currbranch@(Just branch, madj) = go =<< needmerge
 	go False = stop
 	go True = do
 		showStart "merge" $ Git.Ref.describe syncbranch
-		next $ next $ merge currbranch [Git.Merge.MergeNonInteractive] Git.Branch.ManualCommit syncbranch
+		next $ next $ merge currbranch mergeconfig Git.Branch.ManualCommit syncbranch
 	branch' = maybe branch (adjBranch . originalToAdjusted branch) madj
-mergeLocal (Nothing, _) = stop
+mergeLocal _ (Nothing, _) = stop
 
 pushLocal :: CurrBranch -> CommandStart
 pushLocal b = do
diff --git a/doc/todo/support_--allow-unrelated-histories_in_git_2.8.1pre.mdwn b/doc/todo/support_--allow-unrelated-histories_in_git_2.8.1pre.mdwn
index bcbc220..bb8cbd1 100644
--- a/doc/todo/support_--allow-unrelated-histories_in_git_2.8.1pre.mdwn
+++ b/doc/todo/support_--allow-unrelated-histories_in_git_2.8.1pre.mdwn
@@ -16,4 +16,5 @@ but AFAICS, git-annex never uses `git pull`)
 
 > [[done]]; used the environment variable
 > `GIT_MERGE_ALLOW_UNRELATED_HISTORIES` which will hopefully land in git
-> `next` (currently in `pu`) --[[Joey]]
+> `next` (currently Junio has posted a patch but not even landed it in `pu`
+> yet) --[[Joey]]

assistant: Deal with upcoming git's refusal to merge unrelated histories by default
git 2.8.1 (or perhaps 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 by setting GIT_MERGE_ALLOW_UNRELATED_HISTORIES when the assistant
merges.
Note though that this is not done for git annex sync's merges, so
it will follow git's default or configured behavior.
diff --git a/Annex/AdjustedBranch.hs b/Annex/AdjustedBranch.hs
index 26a24d8..2b014a1 100644
--- a/Annex/AdjustedBranch.hs
+++ b/Annex/AdjustedBranch.hs
@@ -260,8 +260,8 @@ adjustedBranchCommitMessage = "git-annex adjusted branch"
 {- Update the currently checked out adjusted branch, merging the provided
  - branch into it. Note that the provided branch should be a non-adjusted
  - branch. -}
-updateAdjustedBranch :: Branch -> (OrigBranch, Adjustment) -> Git.Branch.CommitMode -> Annex Bool
-updateAdjustedBranch tomerge (origbranch, adj) commitmode = catchBoolIO $
+updateAdjustedBranch :: Branch -> (OrigBranch, Adjustment) -> [Git.Merge.MergeConfig] -> Git.Branch.CommitMode -> Annex Bool
+updateAdjustedBranch tomerge (origbranch, adj) mergeconfig commitmode = catchBoolIO $
 	join $ preventCommits go
   where
 	adjbranch@(AdjBranch currbranch) = originalToAdjusted origbranch adj
@@ -304,7 +304,7 @@ updateAdjustedBranch tomerge (origbranch, adj) commitmode = catchBoolIO $
 				showAction $ "Merging into " ++ fromRef (Git.Ref.base origbranch)
 				-- The --no-ff is important; it makes git
 				-- merge not care that the work tree is empty.
-				merged <- inRepo (Git.Merge.mergeNonInteractive' [Param "--no-ff"] tomerge commitmode)
+				merged <- inRepo (Git.Merge.merge' [Param "--no-ff"] tomerge mergeconfig commitmode)
 					<||> (resolveMerge (Just updatedorig) tomerge True <&&> commitResolvedMerge commitmode)
 				if merged
 					then do
@@ -340,7 +340,7 @@ updateAdjustedBranch tomerge (origbranch, adj) commitmode = catchBoolIO $
 		-- this commit will be a fast-forward.
 		adjmergecommitff <- commitAdjustedTree' adjtree (BasisBranch mergecommit) [currbranch]
 		showAction "Merging into adjusted branch"
-		ifM (autoMergeFrom adjmergecommitff (Just currbranch) commitmode)
+		ifM (autoMergeFrom adjmergecommitff (Just currbranch) mergeconfig commitmode)
 			( reparent adjtree adjmergecommit =<< getcurrentcommit
 			, return False
 			)
diff --git a/Annex/AutoMerge.hs b/Annex/AutoMerge.hs
index e6f2be5..26f58a9 100644
--- a/Annex/AutoMerge.hs
+++ b/Annex/AutoMerge.hs
@@ -43,16 +43,16 @@ import qualified Data.ByteString.Lazy as L
  - Callers should use Git.Branch.changed first, to make sure that
  - there are changes from the current branch to the branch being merged in.
  -}
-autoMergeFrom :: Git.Ref -> Maybe Git.Ref -> Git.Branch.CommitMode -> Annex Bool
-autoMergeFrom branch currbranch commitmode = do
+autoMergeFrom :: Git.Ref -> Maybe Git.Ref -> [Git.Merge.MergeConfig] -> Git.Branch.CommitMode -> Annex Bool
+autoMergeFrom branch currbranch mergeconfig commitmode = do
 	showOutput
 	case currbranch of
 		Nothing -> go Nothing
 		Just b -> go =<< inRepo (Git.Ref.sha b)
   where
 	go old = ifM isDirect
-		( mergeDirect currbranch old branch (resolveMerge old branch False) commitmode
-		, inRepo (Git.Merge.mergeNonInteractive branch commitmode)
+		( mergeDirect currbranch old branch (resolveMerge old branch False) mergeconfig commitmode
+		, inRepo (Git.Merge.merge branch mergeconfig commitmode)
 			<||> (resolveMerge old branch False <&&> commitResolvedMerge commitmode)
 		)
 
diff --git a/Annex/Direct.hs b/Annex/Direct.hs
index 782803e..5724d11 100644
--- a/Annex/Direct.hs
+++ b/Annex/Direct.hs
@@ -162,8 +162,8 @@ addDirect file cache = do
  - file. This is the same as what git does when updating the index
  - normally.
  -}
-mergeDirect :: Maybe Git.Ref -> Maybe Git.Ref -> Git.Branch -> Annex Bool -> Git.Branch.CommitMode -> Annex Bool
-mergeDirect startbranch oldref branch resolvemerge commitmode = exclusively $ do
+mergeDirect :: Maybe Git.Ref -> Maybe Git.Ref -> Git.Branch -> Annex Bool -> [Git.Merge.MergeConfig] -> Git.Branch.CommitMode -> Annex Bool
+mergeDirect startbranch oldref branch resolvemerge mergeconfig commitmode = exclusively $ do
 	reali <- liftIO . absPath =<< fromRepo indexFile
 	tmpi <- liftIO . absPath =<< fromRepo indexFileLock
 	liftIO $ whenM (doesFileExist reali) $
@@ -176,7 +176,7 @@ mergeDirect startbranch oldref branch resolvemerge commitmode = exclusively $ do
 		createDirectoryIfMissing True d
 
 	withIndexFile tmpi $ do
-		merged <- stageMerge d branch commitmode
+		merged <- stageMerge d branch mergeconfig commitmode
 		ok <- if merged
 			then return True
 			else resolvemerge
@@ -195,19 +195,18 @@ mergeDirect startbranch oldref branch resolvemerge commitmode = exclusively $ do
 
 {- Stage a merge into the index, avoiding changing HEAD or the current
  - branch. -}
-stageMerge :: FilePath -> Git.Branch -> Git.Branch.CommitMode -> Annex Bool
-stageMerge d branch commitmode = do
+stageMerge :: FilePath -> Git.Branch -> [Git.Merge.MergeConfig] -> Git.Branch.CommitMode -> Annex Bool
+stageMerge d branch mergeconfig commitmode = do
 	-- XXX A bug in git makes stageMerge unsafe to use if the git repo
 	-- is configured with core.symlinks=false
-	-- Using mergeNonInteractive is not ideal though, since it will
+	-- Using merge is not ideal though, since it will
 	-- update the current branch immediately, before the work tree
 	-- has been updated, which would leave things in an inconsistent
 	-- state if mergeDirectCleanup is interrupted.
 	-- <http://marc.info/?l=git&m=140262402204212&w=2>
-	liftIO $ print ("stagemerge in", d)
 	merger <- ifM (coreSymlinks <$> Annex.getGitConfig)
-		( return Git.Merge.stageMerge
-		, return $ \ref -> Git.Merge.mergeNonInteractive ref commitmode
+		( return $ \ref -> Git.Merge.stageMerge ref mergeconfig
+		, return $ \ref -> Git.Merge.merge ref mergeconfig commitmode
 		)
 	inRepo $ \g -> do
 		wd <- liftIO $ absPath d
diff --git a/Assistant/Sync.hs b/Assistant/Sync.hs
index ebdead0..665394a 100644
--- a/Assistant/Sync.hs
+++ b/Assistant/Sync.hs
@@ -21,6 +21,7 @@ import Utility.Parallel
 import qualified Git
 import qualified Git.Command
 import qualified Git.Ref
+import qualified Git.Merge
 import qualified Remote
 import qualified Types.Remote as Remote
 import qualified Remote.List as Remote
@@ -238,12 +239,19 @@ manualPull currentbranch remotes = do
 			)
 	haddiverged <- liftAnnex Annex.Branch.forceUpdate
 	forM_ normalremotes $ \r ->
-		liftAnnex $ Command.Sync.mergeRemote r currentbranch
+		liftAnnex $ Command.Sync.mergeRemote r currentbranch mergeConfig
 	u <- liftAnnex getUUID
 	forM_ xmppremotes $ \r ->
 		sendNetMessage $ Pushing (getXMPPClientID r) (PushRequest u)
 	return (catMaybes failed, haddiverged)
 
+mergeConfig :: [Git.Merge.MergeConfig]
+mergeConfig = 
+	[ Git.Merge.MergeNonInteractive
+	-- Pairing involves merging unrelated histories
+	, Git.Merge.MergeUnrelatedHistories
+	]
+
 {- Start syncing a remote, using a background thread. -}
 syncRemote :: Remote -> Assistant ()
 syncRemote remote = do
diff --git a/Assistant/Threads/Merger.hs b/Assistant/Threads/Merger.hs
index 35d0232..521e5bd 100644
--- a/Assistant/Threads/Merger.hs
+++ b/Assistant/Threads/Merger.hs
@@ -12,6 +12,7 @@ import Assistant.TransferQueue
 import Assistant.BranchChange
 import Assistant.DaemonStatus
 import Assistant.ScanRemotes
+import Assistant.Sync
 import Utility.DirWatcher
 import Utility.DirWatcher.Types
 import qualified Annex.Branch
@@ -85,7 +86,8 @@ onChange file
 					, "into", Git.fromRef b
 					]
 				void $ liftAnnex $ Command.Sync.merge
-					currbranch Git.Branch.AutomaticCommit
+					currbranch mergeConfig
+					Git.Branch.AutomaticCommit
 					changedbranch
 	mergecurrent _ = noop
 
diff --git a/Command/Sync.hs b/Command/Sync.hs
index 5ec2f8b..3e68ad8 100644
--- a/Command/Sync.hs
+++ b/Command/Sync.hs
@@ -32,6 +32,7 @@ import Annex.Hook
 import qualified Git.Command
 import qualified Git.LsFiles as LsFiles
 import qualified Git.Branch
+import qualified Git.Merge
 import qualified Git.Types as Git
 import qualified Git.Ref
 import qualified Git
@@ -112,7 +113,7 @@ seek o = allowConcurrentOutput $ do
 	mapM_ includeCommandAction $ concat
 		[ [ commit o ]
 		, [ withbranch mergeLocal ]
-		, map (withbranch . pullRemote o) gitremotes
+		, map (withbranch . pullRemote o mergeconfig) gitremotes
 		,  [ mergeAnnex ]
 		]
 	when (contentOption o) $
@@ -123,13 +124,15 @@ seek o = allowConcurrentOutput $ do
 			-- and merge again to avoid our push overwriting
 			-- those changes.
 			mapM_ includeCommandAction $ concat
-				[ map (withbranch . pullRemote o) gitremotes
+				[ map (withbranch . pullRemote o mergeconfig) gitremotes
 				, [ commitAnnex, mergeAnnex ]
 				]
 	
 	void $ includeCommandAction $ withbranch pushLocal
 	-- Pushes to remotes can run concurrently.
 	mapM_ (commandAction . withbranch . pushRemote o) gitremotes
+  where
+	mergeconfig = [Git.Merge.MergeNonInteractive]
 
 type CurrBranch = (Maybe Git.Branch, Maybe Adjustment)
 

(Diff truncated)
reinject: Added new mode which can reinject known files into the annex.
For example: git-annex reinject --known /mnt/backup/*
diff --git a/CmdLine/Usage.hs b/CmdLine/Usage.hs
index f66eb91..c452278 100644
--- a/CmdLine/Usage.hs
+++ b/CmdLine/Usage.hs
@@ -104,3 +104,5 @@ paramOptional :: String -> String
 paramOptional s = s
 paramPair :: String -> String -> String
 paramPair a b = a ++ " " ++ b
+paramOr :: String -> String -> String
+paramOr a b = a ++ " | " ++ b
diff --git a/Command/Reinject.hs b/Command/Reinject.hs
index 0b1b0e2..ce18c7c 100644
--- a/Command/Reinject.hs
+++ b/Command/Reinject.hs
@@ -1,6 +1,6 @@
 {- git-annex command
  -
- - Copyright 2011 Joey Hess <id@joeyh.name>
+ - Copyright 2011-2016 Joey Hess <id@joeyh.name>
  -
  - Licensed under the GNU GPL version 3 or higher.
  -}
@@ -10,30 +10,63 @@ module Command.Reinject where
 import Command
 import Logs.Location
 import Annex.Content
+import Backend
+import Types.KeySource
 
 cmd :: Command
 cmd = command "reinject" SectionUtility 
-	"sets content of annexed file"
-	(paramPair "SRC" "DEST") (withParams seek)
+	"inject content of file back into annex"
+	(paramRepeating (paramPair "SRC" "DEST")
+		`paramOr` "--known " ++ paramRepeating "SRC")
+	(seek <$$> optParser)
 
-seek :: CmdParams -> CommandSeek
-seek = withWords start
+data ReinjectOptions = ReinjectOptions
+	{ params :: CmdParams
+	, knownOpt :: Bool
+	}
 
-start :: [FilePath] -> CommandStart
-start (src:dest:[])
+optParser :: CmdParamsDesc -> Parser ReinjectOptions
+optParser desc = ReinjectOptions
+	<$> cmdParams desc
+	<*> switch
+		( long "known"
+		<> help "inject all known files"
+		<> hidden
+		)
+
+seek :: ReinjectOptions -> CommandSeek
+seek os
+	| knownOpt os = withStrings startKnown (params os)
+	| otherwise = withWords startSrcDest (params os)
+
+startSrcDest :: [FilePath] -> CommandStart
+startSrcDest (src:dest:[])
 	| src == dest = stop
-	| otherwise =
-		ifAnnexed src
-			(error $ "cannot used annexed file as src: " ++ src)
-			go
-  where
-	go = do
+	| otherwise = notAnnexed src $ do
 		showStart "reinject" dest
-		next $ whenAnnexed (perform src) dest
-start _ = error "specify a src file and a dest file"
+		next $ ifAnnexed dest
+			(perform src)
+			stop
+startSrcDest _ = error "specify a src file and a dest file"
+
+startKnown :: FilePath -> CommandStart
+startKnown src = notAnnexed src $ do
+	showStart "reinject" src
+	mkb <- genKey (KeySource src src Nothing) Nothing
+	case mkb of
+		Nothing -> error "Failed to generate key"
+		Just (key, _) -> ifM (isKnownKey key)
+			( next $ perform src key
+			, do
+				warning "Not known content; skipping"
+				next $ next $ return True
+			)
+
+notAnnexed :: FilePath -> CommandStart -> CommandStart
+notAnnexed src = ifAnnexed src (error $ "cannot used annexed file as src: " ++ src)
 
-perform :: FilePath -> FilePath -> Key -> CommandPerform
-perform src _dest key = ifM move
+perform :: FilePath -> Key -> CommandPerform
+perform src key = ifM move
 	( next $ cleanup key
 	, error "failed"
 	)
diff --git a/Logs/Location.hs b/Logs/Location.hs
index 2698d7f..ba2aed1 100644
--- a/Logs/Location.hs
+++ b/Logs/Location.hs
@@ -19,6 +19,7 @@ module Logs.Location (
 	logChange,
 	loggedLocations,
 	loggedLocationsHistorical,
+	isKnownKey,
 	checkDead,
 	setDead,
 	loggedKeys,
@@ -65,6 +66,13 @@ getLoggedLocations getter key = do
 	config <- Annex.getGitConfig
 	map toUUID <$> getter (locationLogFile config key)
 
+{- Is there a location log for the key? True even for keys with no
+ - remaining locations. -}
+isKnownKey :: Key -> Annex Bool
+isKnownKey key = do
+	config <- Annex.getGitConfig
+	not . null <$> readLog (locationLogFile config key)
+
 {- For a key to be dead, all locations that have location status for the key
  - must have InfoDead set. -}
 checkDead :: Key -> Annex Bool
diff --git a/doc/git-annex-reinject.mdwn b/doc/git-annex-reinject.mdwn
index fb17501..e280a12 100644
--- a/doc/git-annex-reinject.mdwn
+++ b/doc/git-annex-reinject.mdwn
@@ -1,32 +1,62 @@
 # NAME
 
-git-annex reinject - sets content of annexed file
+git-annex reinject - inject content of file back into annex
 
 # SYNOPSIS
 
-git annex reinject `src dest`
+git annex reinject `[src dest]`
+
+git annex reinject --known `[src]`
 
 # DESCRIPTION
 
-Moves the src file into the annex as the content of the dest file,
-which should be an already annexed file whose content is not present.
+Moves the content of the src file or files into the annex.
+Only known file contents will be reinjected. Any unknown src files will
+be left unchanged.
 
 This can be useful if you have obtained the content of a file from
-elsewhere and want to put it in the local annex.
-
-Verifies that the src file's content matches with the content that the dest
-file is expected to have, and refuses to reinject it otherwise.
+elsewhere and want to put it in the local annex. For example, if a file's
+content has been lost and you have a backup, you can restore the backup and
+reinject it into your local repository.
 
-Example:
+There are two ways to use this command. Specifying a src file and the name
+of a dest file (located inside the repository's working tree)
+injects the src file as the content of the dest file.
 
 	git annex reinject /tmp/foo.iso foo.iso
 
+Or the `--known` option can be used to reinject all known src files, without
+needing to specify the dest file.
+
+	git annex reinject --known /tmp/*.iso
+
+# OPTIONS
+
+* `--known`
+
+  With this option, each specified src file is hashed using the default
+  key-value backend (or the one specified with `--backend`), and if git-annex
+  has a record of the file having been in the annex before, the content is
+  reinjected.
+
+  Note that this will reinject old versions of files that have been
+  modified or deleted from the current git branch.
+  Use [[git-annex-unused]](1) to detect when such old and potentially
+  unused files have been reinjected.
+
+* `--backend`
+
+  Specify the key-value backend to use when checking if a file is known
+  with the `--known` option.
+
 # SEE ALSO
 
 [[git-annex]](1)
 
 [[git-annex-add]](1)
 
+[[git-annex-unused]](1)

(Diff truncated)
Added a comment
diff --git a/doc/bugs/startup_scan_extremely_slow/comment_4_ade878000a050c87a345e8bc9914deba._comment b/doc/bugs/startup_scan_extremely_slow/comment_4_ade878000a050c87a345e8bc9914deba._comment
new file mode 100644
index 0000000..76cf8fa
--- /dev/null
+++ b/doc/bugs/startup_scan_extremely_slow/comment_4_ade878000a050c87a345e8bc9914deba._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="zarel"
+ subject="comment 4"
+ date="2016-04-22T15:27:20Z"
+ content="""
+git-annex updated to the last version. .git removed, repo recreated from scratch in v5 direct mode and it still happens. I'll try to export GIT_TRACE and understand why the \"cat-file\" is taking 50% of a cpu
+"""]]

rename bugs/startup_scan_extremely_slow___40__v6_repo__41__.mdwn to bugs/startup_scan_extremely_slow.mdwn
diff --git a/doc/bugs/startup_scan_extremely_slow.mdwn b/doc/bugs/startup_scan_extremely_slow.mdwn
new file mode 100644
index 0000000..449c88e
--- /dev/null
+++ b/doc/bugs/startup_scan_extremely_slow.mdwn
@@ -0,0 +1,69 @@
+### Please describe the problem.
+
+When the assistant starts it takes several hours to do the startup scan, even when there are no files to add.
+
+The repo contains many small files but it is configured to add the smaller ones via gitattributes. In particular there are: 91949 files added to git repo and 1029 annexed.
+This is my gitattributes
+
+    * annex.largefiles=(largerthan=500kb)
+
+annex.addunlocked is set to true
+
+### What steps will reproduce the problem?
+
+Create a repo with ~90000 files smaller than 500k and ~1000 files larger (in my case ranging from 500k to 32M). Set addunlocked to true and annex.largefiles to largerthan=500kb. Start the assistant and let it finish adding the files. Restart the assistant.
+
+### What version of git-annex are you using? On what operating system?
+
+git-annex version: 6.20160318
+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: 6
+
+I'm running it on Arch Linux (packaged version)
+
+### Please provide any additional information below.
+
+[[!format sh """
+
+[2016-03-29 22:08:26.356586] main: starting assistant version 6.20160318
+
+  No known network monitor available through dbus; falling back to polling
+(scanning...) [2016-03-29 22:08:41.426049] Watcher: Performing startup scan
+[2016-03-29 23:05:40.533113] Committer: Committing changes to git
+(recording state in git...)
+[2016-03-30 00:10:07.085051] Committer: Committing changes to git
+(recording state in git...)
+[2016-03-30 01:23:29.784236] Committer: Committing changes to git
+(recording state in git...)
+[2016-03-30 02:43:02.048312] Committer: Committing changes to git
+(recording state in git...)
+[2016-03-30 03:37:53.273057] Committer: Committing changes to git
+(recording state in git...)
+[2016-03-30 04:04:56.875573] Committer: Committing changes to git
+(recording state in git...)
+[2016-03-30 04:31:14.370618] Committer: Committing changes to git
+(recording state in git...)
+[2016-03-30 04:56:12.467889] Committer: Committing changes to git
+(recording state in git...)
+[2016-03-30 05:21:09.021728] Committer: Committing changes to git
+(recording state in git...)
+[2016-03-30 05:43:11.111616] Committer: Committing changes to git
+(recording state in git...)
+[2016-03-30 06:14:38.096425] Committer: Committing changes to git
+(recording state in git...)
+[2016-03-30 06:49:54.730879] Committer: Committing changes to git
+(recording state in git...)
+[2016-03-30 07:26:47.721929] Committer: Committing changes to git
+(recording state in git...)
+
+
+# End of transcript or log.
+"""]]
+
+At this point I stopped the assistant that was still doing the startup scan...
+
+### Have you had any luck using git-annex before?
+
+Sure!
diff --git a/doc/bugs/startup_scan_extremely_slow/comment_1_68f88f04c179800c0ce1ff6925d4c6ab._comment b/doc/bugs/startup_scan_extremely_slow/comment_1_68f88f04c179800c0ce1ff6925d4c6ab._comment
new file mode 100644
index 0000000..ea3347d
--- /dev/null
+++ b/doc/bugs/startup_scan_extremely_slow/comment_1_68f88f04c179800c0ce1ff6925d4c6ab._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="zarel"
+ subject="comment 1"
+ date="2016-04-02T20:22:23Z"
+ content="""
+I suppose that the problem is strictly assistant related since both \"git annex status\" and \"git status\" give me the correct status when new files are present in a couple of seconds the first time and in a fraction of a second in the subsequent calls
+"""]]
diff --git a/doc/bugs/startup_scan_extremely_slow/comment_2_116e850299372027481c9d0a1667d5af._comment b/doc/bugs/startup_scan_extremely_slow/comment_2_116e850299372027481c9d0a1667d5af._comment
new file mode 100644
index 0000000..03683de
--- /dev/null
+++ b/doc/bugs/startup_scan_extremely_slow/comment_2_116e850299372027481c9d0a1667d5af._comment
@@ -0,0 +1,25 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2016-04-04T20:23:19Z"
+ content="""
+Note that v6 is still an experimental feature. I have not tested the
+assistant with it much.
+
+There is an issue documented on [[smudge]] where git can end up
+unncessarily running the smudge filter after git-annex eg, gets a file,
+or adds a file.
+
+This could be related to that; after the assistant added a lot of
+files here, the first `git status` run was quite slow as it ran the clean
+filter on every file. Subsequent `git status` runs then went fast.
+
+But, I don't know why this would make the startup scan slow; it
+doesn't seem to use any git commands that would need to smudge files.
+I tested by exporting `GIT_TRACE=1` and starting the assistant; the
+startup scan went fast and there was nothing in .git/annex/daemon.log
+about smudging.
+
+Also, what are these changes that are apparently being committed to git
+during your startup scan? I don't see such commits, either here.
+"""]]
diff --git a/doc/bugs/startup_scan_extremely_slow/comment_3_3eb4c2290e560451e7341b85b58212b0._comment b/doc/bugs/startup_scan_extremely_slow/comment_3_3eb4c2290e560451e7341b85b58212b0._comment
new file mode 100644
index 0000000..a2ac70f
--- /dev/null
+++ b/doc/bugs/startup_scan_extremely_slow/comment_3_3eb4c2290e560451e7341b85b58212b0._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="zarel"
+ subject="comment 3"
+ date="2016-04-05T17:24:06Z"
+ content="""
+You're right, after the initial run there is no smudge filter overhead. I ran htop in tree view and got this result:
+
+    git-annex-assistant (55-60%)
+      |--> git-annex-assistant (six instances, a couple of those with load 20-40%, the others idling at 0%)
+      |--> git ls-files (mostly idle)
+      |--> git check-attr (mostly idle)
+      |--> git check-ignore (mostly idle)
+      |--> git cat-file (stuck at 40-60%)
+"""]]
diff --git a/doc/bugs/startup_scan_extremely_slow___40__v6_repo__41__.mdwn b/doc/bugs/startup_scan_extremely_slow___40__v6_repo__41__.mdwn
deleted file mode 100644
index 449c88e..0000000
--- a/doc/bugs/startup_scan_extremely_slow___40__v6_repo__41__.mdwn
+++ /dev/null
@@ -1,69 +0,0 @@
-### Please describe the problem.
-
-When the assistant starts it takes several hours to do the startup scan, even when there are no files to add.
-
-The repo contains many small files but it is configured to add the smaller ones via gitattributes. In particular there are: 91949 files added to git repo and 1029 annexed.
-This is my gitattributes
-
-    * annex.largefiles=(largerthan=500kb)
-
-annex.addunlocked is set to true
-
-### What steps will reproduce the problem?
-
-Create a repo with ~90000 files smaller than 500k and ~1000 files larger (in my case ranging from 500k to 32M). Set addunlocked to true and annex.largefiles to largerthan=500kb. Start the assistant and let it finish adding the files. Restart the assistant.
-
-### What version of git-annex are you using? On what operating system?
-
-git-annex version: 6.20160318
-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: 6
-
-I'm running it on Arch Linux (packaged version)
-
-### Please provide any additional information below.
-
-[[!format sh """
-
-[2016-03-29 22:08:26.356586] main: starting assistant version 6.20160318
-
-  No known network monitor available through dbus; falling back to polling
-(scanning...) [2016-03-29 22:08:41.426049] Watcher: Performing startup scan
-[2016-03-29 23:05:40.533113] Committer: Committing changes to git
-(recording state in git...)
-[2016-03-30 00:10:07.085051] Committer: Committing changes to git
-(recording state in git...)
-[2016-03-30 01:23:29.784236] Committer: Committing changes to git
-(recording state in git...)
-[2016-03-30 02:43:02.048312] Committer: Committing changes to git
-(recording state in git...)
-[2016-03-30 03:37:53.273057] Committer: Committing changes to git
-(recording state in git...)
-[2016-03-30 04:04:56.875573] Committer: Committing changes to git
-(recording state in git...)
-[2016-03-30 04:31:14.370618] Committer: Committing changes to git
-(recording state in git...)
-[2016-03-30 04:56:12.467889] Committer: Committing changes to git
-(recording state in git...)
-[2016-03-30 05:21:09.021728] Committer: Committing changes to git
-(recording state in git...)
-[2016-03-30 05:43:11.111616] Committer: Committing changes to git
-(recording state in git...)
-[2016-03-30 06:14:38.096425] Committer: Committing changes to git
-(recording state in git...)

(Diff truncated)
Added a comment
diff --git a/doc/forum/n00b_question._Can_I_use_git-annex_to_manage_a_tree_that_contains_git_repos__63__/comment_2_53e0ffe901a1a1c22361bfd7cf71affd._comment b/doc/forum/n00b_question._Can_I_use_git-annex_to_manage_a_tree_that_contains_git_repos__63__/comment_2_53e0ffe901a1a1c22361bfd7cf71affd._comment
new file mode 100644
index 0000000..73a2e8c
--- /dev/null
+++ b/doc/forum/n00b_question._Can_I_use_git-annex_to_manage_a_tree_that_contains_git_repos__63__/comment_2_53e0ffe901a1a1c22361bfd7cf71affd._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="interstar@551341a1dbca18391e90a3f719eae492868ceb7a"
+ nickname="interstar"
+ subject="comment 2"
+ date="2016-04-22T12:38:16Z"
+ content="""
+OK. Thanks.
+"""]]

Added a comment: objecthashlower
diff --git a/doc/bugs/OSX_case_insensitive_filesystem/comment_4_0b0c95a902718dd4e0976bf4e2cf265b._comment b/doc/bugs/OSX_case_insensitive_filesystem/comment_4_0b0c95a902718dd4e0976bf4e2cf265b._comment
new file mode 100644
index 0000000..29a53e0
--- /dev/null
+++ b/doc/bugs/OSX_case_insensitive_filesystem/comment_4_0b0c95a902718dd4e0976bf4e2cf265b._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://id.clacke.se/"
+ nickname="clacke"
+ subject="objecthashlower"
+ date="2016-04-22T07:58:33Z"
+ content="""
+... i.e., can I just `git config --global annex.tune.objecthashlower true` and it will Just Work, managing old repos correctly and using the feature for new repos? And remote machines will handle things correctly just as long as they run a modern enough `git-annex`?
+"""]]

Added a comment: objecthashlower
diff --git a/doc/bugs/OSX_case_insensitive_filesystem/comment_3_4be758c2b70c0aadfe4fc9ecff8e4522._comment b/doc/bugs/OSX_case_insensitive_filesystem/comment_3_4be758c2b70c0aadfe4fc9ecff8e4522._comment
new file mode 100644
index 0000000..dc6b89f
--- /dev/null
+++ b/doc/bugs/OSX_case_insensitive_filesystem/comment_3_4be758c2b70c0aadfe4fc9ecff8e4522._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://id.clacke.se/"
+ nickname="clacke"
+ subject="objecthashlower"
+ date="2016-04-22T07:55:40Z"
+ content="""
+> It's actually possible to make brand-new git-annex repos use all lower case hash directories today, by setting git config annex.tune.objecthashlower true before you run git annex init for the first time.
+
+Am I interpreting this correctly, that this sets some attribute in the git-annex branch, so that clones of this repo will use the same annex layout?
+"""]]

Added a comment: Case-sensitive on OSX
diff --git a/doc/bugs/OSX_case_insensitive_filesystem/comment_2_4472d5db7a1cf7242077184912e32e17._comment b/doc/bugs/OSX_case_insensitive_filesystem/comment_2_4472d5db7a1cf7242077184912e32e17._comment
new file mode 100644
index 0000000..4f84151
--- /dev/null
+++ b/doc/bugs/OSX_case_insensitive_filesystem/comment_2_4472d5db7a1cf7242077184912e32e17._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://id.clacke.se/"
+ nickname="clacke"
+ subject="Case-sensitive on OSX"
+ date="2016-04-22T07:53:56Z"
+ content="""
+> What I'd recommend you do is, move the repository back to OSX, and then make a clone of it on the linux system
+
+Alternatively, create a case-sensitive FS on the Mac (just in a .dmg) and do the clone and copy to there, before rsync'ing to the remote Linux.
+"""]]

Added a comment: git-annex is git
diff --git a/doc/forum/n00b_question._Can_I_use_git-annex_to_manage_a_tree_that_contains_git_repos__63__/comment_1_ac45ad341f026289ce56183b9ff463af._comment b/doc/forum/n00b_question._Can_I_use_git-annex_to_manage_a_tree_that_contains_git_repos__63__/comment_1_ac45ad341f026289ce56183b9ff463af._comment
new file mode 100644
index 0000000..8e409bb
--- /dev/null
+++ b/doc/forum/n00b_question._Can_I_use_git-annex_to_manage_a_tree_that_contains_git_repos__63__/comment_1_ac45ad341f026289ce56183b9ff463af._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://id.clacke.se/"
+ nickname="clacke"
+ subject="git-annex is git"
+ date="2016-04-22T07:44:06Z"
+ content="""
+git-annex is first git, then some additional very neat functionality. Being git, it refuses to handle git repositories as that would create all kinds of potential confusion and inefficiency.
+
+Submodules would be a way to go, if you like how they work. Or you could just ignore the git repos, as you probably have them replicated somewhere else.
+"""]]

diff --git a/doc/forum/n00b_question._Can_I_use_git-annex_to_manage_a_tree_that_contains_git_repos__63__.mdwn b/doc/forum/n00b_question._Can_I_use_git-annex_to_manage_a_tree_that_contains_git_repos__63__.mdwn
new file mode 100644
index 0000000..46257f6
--- /dev/null
+++ b/doc/forum/n00b_question._Can_I_use_git-annex_to_manage_a_tree_that_contains_git_repos__63__.mdwn
@@ -0,0 +1,7 @@
+Just started looking at git-annex and it's very interesting to me as I manage a large tree of different types of projects, spread across two computers and some hard-drives (some backups, some offline resources and archives)
+
+But one question that's bothering me. A lot of my projects are already git repos. Is it possible to use git-annex with this tree or will the gits fight unless I explicitly make them submodules? 
+
+cheers
+
+Phil

todo
diff --git a/doc/todo/support_--allow-unrelated-histories_in_git_2.8.1pre.mdwn b/doc/todo/support_--allow-unrelated-histories_in_git_2.8.1pre.mdwn
new file mode 100644
index 0000000..3218c3b
--- /dev/null
+++ b/doc/todo/support_--allow-unrelated-histories_in_git_2.8.1pre.mdwn
@@ -0,0 +1,15 @@
+git merge has recently been made to refuse to merge disconnected histories
+unless --allow-unrelated-histories is passed. This will break uses of the
+webapp, eg local pairing until git-annex is changed to pass that whenever
+it runs `git merge`.
+
+It could also perhaps break uses of `git annex sync` where a remote with a
+disconnected history is added and it's expected to merge with it. Although
+in this latter case, it might be argued that the default git behavior has
+changed and `git annex sync` should follow suite.
+
+(Also, any uses of `git pull` currently would need to
+be split into a fetch and a merge in order to pass the option to the merge;
+but AFAICS, git-annex never uses `git pull`)
+
+--[[Joey]]

Added a comment
diff --git a/doc/forum/Using_integer_ranges_with_metadata/comment_5_9d310fac003f1cd9e6ca9bc96a210def._comment b/doc/forum/Using_integer_ranges_with_metadata/comment_5_9d310fac003f1cd9e6ca9bc96a210def._comment
new file mode 100644
index 0000000..619eb3c
--- /dev/null
+++ b/doc/forum/Using_integer_ranges_with_metadata/comment_5_9d310fac003f1cd9e6ca9bc96a210def._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="pigmonkey"
+ subject="comment 5"
+ date="2016-04-21T16:57:03Z"
+ content="""
+Absolutely!
+
+<https://github.com/pigmonkey/metamovie>
+
+It's a quick hack job, but has been working so far. I haven't played around with [[tips/automatically adding metadata]] yet. The filename based search does the right thing 99% of the time (at least for my file names), but I still always want to confirm that it is using the right movie data, so I'm running the script manually and keeping it interactive.
+"""]]

calckey can use --backend
diff --git a/doc/git-annex-calckey.mdwn b/doc/git-annex-calckey.mdwn
index 84fafba..340c03e 100644
--- a/doc/git-annex-calckey.mdwn
+++ b/doc/git-annex-calckey.mdwn
@@ -13,9 +13,10 @@ to refer to a file. The file is not added to the annex by this command.
 The key is output to stdout.
 
 The backend used is the first listed in the annex.backends configuration
-setting. For example, to force use of the SHA1 backend:
+setting, which can be overridden by the --backend option.
+For example, to force use of the SHA1 backend:
 
-	git annex calckey -c annex.backends=SHA1 file
+	git annex calckey --backend=SHA1 file
 
 # OPTIONS
 
@@ -24,6 +25,10 @@ setting. For example, to force use of the SHA1 backend:
   Enable batch mode, in which a line containing the filename is read from
   stdin, the key is output to stdout (with a trailing newline), and repeat.
 
+* `--backend=name`
+
+  Specifies which key-value backend to use.
+
 # SEE ALSO
 
 [[git-annex]](1)

Added a comment
diff --git a/doc/forum/Using_integer_ranges_with_metadata/comment_4_c3301d1b2b57994666947fd518fb9922._comment b/doc/forum/Using_integer_ranges_with_metadata/comment_4_c3301d1b2b57994666947fd518fb9922._comment
new file mode 100644
index 0000000..e08fb7d
--- /dev/null
+++ b/doc/forum/Using_integer_ranges_with_metadata/comment_4_c3301d1b2b57994666947fd518fb9922._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="cstork"
+ subject="comment 4"
+ date="2016-04-21T14:35:46Z"
+ content="""
+Could you share your IMDB -> metadata script?  It would be interesting to see what works in practice.
+
+I was about to write something similar and why duplicate work? :-)
+"""]]

Added a comment
diff --git a/doc/todo/import_--reinject/comment_6_2254aee4729f8710076e08992c3ed746._comment b/doc/todo/import_--reinject/comment_6_2254aee4729f8710076e08992c3ed746._comment
new file mode 100644
index 0000000..95d0f58
--- /dev/null
+++ b/doc/todo/import_--reinject/comment_6_2254aee4729f8710076e08992c3ed746._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="CandyAngel"
+ subject="comment 6"
+ date="2016-04-21T11:41:09Z"
+ content="""
+    There's also the problem of different backends; it seems such a thing would need to hash a file 5 different ways to make sure no hash of it is known.
+
+As it leaves non-matched files alone, the user could specify the backend to minimise this requirement.
+
+Perhaps a new command \"ingest\", with an option for the backend and require --force to try all known backends?
+
+This would be very useful for my file sorting project (when I restart it).
+"""]]

Added a comment
diff --git a/doc/bugs/git-annex_smudge_fails_on_git_add/comment_5_44f947f5b1174cf37f4b7f18971d97ca._comment b/doc/bugs/git-annex_smudge_fails_on_git_add/comment_5_44f947f5b1174cf37f4b7f18971d97ca._comment
new file mode 100644
index 0000000..c0a9d06
--- /dev/null
+++ b/doc/bugs/git-annex_smudge_fails_on_git_add/comment_5_44f947f5b1174cf37f4b7f18971d97ca._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="j_k_234@b2b1aa189bf195cefd815fc0fe70e0ebbe2b8077"
+ nickname="j_k_234"
+ subject="comment 5"
+ date="2016-04-21T09:00:49Z"
+ content="""
+Running the smudge command manually works.  Incidentally, just noticed that running the add command a second time seems to work...
+
+I ran the command under strace -f and all subprocesses seem to exit with RC=0, but I can see the error message being output.  Would you like me to send you the strace output (200k gzipped)?
+"""]]

Added a comment
diff --git a/doc/forum/annex.largefiles__58___two_quesitons/comment_2_f34cf28c3f8354e6fc055d4dba6ed555._comment b/doc/forum/annex.largefiles__58___two_quesitons/comment_2_f34cf28c3f8354e6fc055d4dba6ed555._comment
new file mode 100644
index 0000000..ab02f0e
--- /dev/null
+++ b/doc/forum/annex.largefiles__58___two_quesitons/comment_2_f34cf28c3f8354e6fc055d4dba6ed555._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="cstork"
+ subject="comment 2"
+ date="2016-04-21T06:46:40Z"
+ content="""
+Just to prevent a potential misunderstanding: There are two ways to configure annex.largefiles.
+
+1. in `.git/config`, e.g., via `git config annex.largefiles=...`
+2. in `.gitattributes`
+
+The first configuration is specific to your local copy of the repository and does not travel with the content,
+whereas the second one does carry the configuration over to the other repos.
+"""]]

devblog
diff --git a/doc/devblog/day_382-384__pretty_well_caught_up.mdwn b/doc/devblog/day_382-384__pretty_well_caught_up.mdwn
new file mode 100644
index 0000000..86089f5
--- /dev/null
+++ b/doc/devblog/day_382-384__pretty_well_caught_up.mdwn
@@ -0,0 +1,9 @@
+The past three days have felt kind of low activity days, but somehow a lot
+of stuff still got done, both bug fixes and small features, and I am
+feeling pretty well caught up with backlog for the first time in over a
+month. Although as always there is some left, 110 messages.
+
+On Monday I fixed a bug that could cause a hang when dropping content, if
+git-annex had to verify the content was present on a ssh remote. That bug
+was bad enough to make an immediate release for, even though it was only a
+week since the last release.

Added a comment
diff --git a/doc/todo/import_--reinject/comment_5_ab63877b47869c78a3f17465cd985bb1._comment b/doc/todo/import_--reinject/comment_5_ab63877b47869c78a3f17465cd985bb1._comment
new file mode 100644
index 0000000..d80e6c1
--- /dev/null
+++ b/doc/todo/import_--reinject/comment_5_ab63877b47869c78a3f17465cd985bb1._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="grawity@2ea26be48562f66fcb9b66307da72b1e2e37453f"
+ nickname="grawity"
+ subject="comment 5"
+ date="2016-04-20T19:21:33Z"
+ content="""
+\"There's also the problem of different backends; it seems such a thing would need to hash a file 5 different ways to make sure no hash of it is known.\"
+
+Yeah, I guess you're right – and there might even be different 'hashes' in the same backend, e.g. SHA256E considers `Foo.ISO` different from `Foo.iso`...
+
+Actually I ended up doing this only twice, so manual `annex add everything` + duplicate cleaner wasn't really that bad in the end. And `annex calckey` and `annex find` with ${key} will be useful for the other scripts I have; thanks.
+"""]]

Isolate test suite from global git config settings.
diff --git a/Test.hs b/Test.hs
index 03492ad..f7faf47 100644
--- a/Test.hs
+++ b/Test.hs
@@ -112,6 +112,7 @@ optParser = TestOptions
 runner :: Maybe (TestOptions -> IO ())
 runner = Just $ \opts -> do
 	ensuretmpdir
+	isolateGitConfig
 	crippledfilesystem <- Annex.Init.probeCrippledFileSystem' tmpdir
 	case tryIngredients ingredients (tastyOptionSet opts) (tests crippledfilesystem opts) of
 		Nothing -> error "No tests found!?"
@@ -1787,6 +1788,15 @@ ensuretmpdir = do
 	e <- doesDirectoryExist tmpdir
 	unless e $
 		createDirectory tmpdir
+	
+{- Prevent global git configs from affecting the test suite. -}
+isolateGitConfig :: IO ()
+isolateGitConfig = do
+	let tmphome = tmpdir </> "home"
+	createDirectoryIfMissing False tmphome
+	Utility.Env.setEnv "HOME" tmphome True
+	Utility.Env.setEnv "XDG_CONFIG_HOME" tmphome True
+	Utility.Env.setEnv "GIT_CONFIG_NOSYSTEM" "1" True
 
 cleanup :: FilePath -> IO ()
 cleanup = cleanup' False
diff --git a/debian/changelog b/debian/changelog
index 39743f3..7dc48ed 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -10,6 +10,7 @@ git-annex (6.20160419) UNRELEASED; urgency=medium
     to refer to a file.
   * Fix bug that prevented annex.sshcaching=false configuration from taking
     effect when on a crippled filesystem. Thanks, divergentdave.
+  * Isolate test suite from global git config settings.
 
  -- Joey Hess <id@joeyh.name>  Tue, 19 Apr 2016 12:57:15 -0400
 
diff --git a/doc/bugs/Three_tests_fail_when_annex.backends_is_defined.mdwn b/doc/bugs/Three_tests_fail_when_annex.backends_is_defined.mdwn
index 34096db..d7a635d 100644
--- a/doc/bugs/Three_tests_fail_when_annex.backends_is_defined.mdwn
+++ b/doc/bugs/Three_tests_fail_when_annex.backends_is_defined.mdwn
@@ -105,3 +105,7 @@ found a bug report from you on
 be related, but I don't know if that's the case. The newest version I'm 
 able to build is 5.20150219, somewhere after that various things start 
 to fail.
+
+> [[fixed|done]]; I found a way to isolate the test suite from global git
+> configs, by setting `GIT_CONFIG_NOSYSTEM` and also setting
+> `HOME` and `XDG_CONFIG_HOME` to an empty directory. --[[Joey]]

Added a comment
diff --git a/doc/bugs/sync_on_a_repository_on_removable_media_should_not_leave_ssh_conns_open/comment_2_08c25e314bf86b8a67c1730a02957300._comment b/doc/bugs/sync_on_a_repository_on_removable_media_should_not_leave_ssh_conns_open/comment_2_08c25e314bf86b8a67c1730a02957300._comment
new file mode 100644
index 0000000..861ff12
--- /dev/null
+++ b/doc/bugs/sync_on_a_repository_on_removable_media_should_not_leave_ssh_conns_open/comment_2_08c25e314bf86b8a67c1730a02957300._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="spwhitton"
+ subject="comment 2"
+ date="2016-04-20T19:01:21Z"
+ content="""
+Thanks for letting me know about that functionality.  I'll try to isolate why it sometimes fails on my machine.
+"""]]

Fix bug that prevented annex.sshcaching=false configuration from taking effect when on a crippled filesystem. Thanks, divergentdave.
diff --git a/Annex/Ssh.hs b/Annex/Ssh.hs
index a97134c..10efa9f 100644
--- a/Annex/Ssh.hs
+++ b/Annex/Ssh.hs
@@ -101,13 +101,14 @@ sshConnectionCachingParams socketfile =
  - a different filesystem. -}
 sshCacheDir :: Annex (Maybe FilePath)
 sshCacheDir
-	| SysConfig.sshconnectioncaching = ifM crippledFileSystem
-		( maybe (return Nothing) usetmpdir =<< gettmpdir
-		, ifM (fromMaybe True . annexSshCaching <$> Annex.getGitConfig)
-			( Just <$> fromRepo gitAnnexSshDir
+	| SysConfig.sshconnectioncaching = 
+		ifM (fromMaybe True . annexSshCaching <$> Annex.getGitConfig)
+			( ifM crippledFileSystem
+				( maybe (return Nothing) usetmpdir =<< gettmpdir
+				, Just <$> fromRepo gitAnnexSshDir 
+				)
 			, return Nothing
 			)
-		)
 	| otherwise = return Nothing
   where
 	gettmpdir = liftIO $ getEnv "GIT_ANNEX_TMP_DIR"
diff --git a/debian/changelog b/debian/changelog
index 2636403..39743f3 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -8,6 +8,8 @@ git-annex (6.20160419) UNRELEASED; urgency=medium
     instead of deleting it.
   * 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.
 
  -- Joey Hess <id@joeyh.name>  Tue, 19 Apr 2016 12:57:15 -0400
 
diff --git a/doc/bugs/Android_6.0_compatibility/comment_6_a4ef9eb27285aa68d6edc14e30627ebf._comment b/doc/bugs/Android_6.0_compatibility/comment_6_a4ef9eb27285aa68d6edc14e30627ebf._comment
new file mode 100644
index 0000000..fb98077
--- /dev/null
+++ b/doc/bugs/Android_6.0_compatibility/comment_6_a4ef9eb27285aa68d6edc14e30627ebf._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 6"""
+ date="2016-04-20T18:40:57Z"
+ content="""
+Thanks, divergentdave for spotting that and also for writing a fix.
+I've finally noticed your comment and put the fix in. It would probably be
+good to open a todo if you have a patch in the future, to make sure it
+doesn't get forgotten about.
+"""]]

comment
diff --git a/doc/todo/batch_get__47__drop__47__etc/comment_1_c912c829dbb77d2072e0150fcb47932e._comment b/doc/todo/batch_get__47__drop__47__etc/comment_1_c912c829dbb77d2072e0150fcb47932e._comment
new file mode 100644
index 0000000..69b5d03
--- /dev/null
+++ b/doc/todo/batch_get__47__drop__47__etc/comment_1_c912c829dbb77d2072e0150fcb47932e._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-04-20T18:30:23Z"
+ content="""
+I prefer keeping --batch on things that act in terms of keys and have a
+simpler interface.
+
+So, could add --batch to `git annex transferkey`. This would presumably
+need to disable any process displays in order for success/failure to be
+communicated in a machine-parsable way. (Actually, `git annex transferkeys`
+already implements such a batch interface, but one that is currently
+not documented due to only being built for the assistant to use it.)
+
+There is already `git annex dropkey --batch`, although it does not
+verify that other copies exist.
+"""]]

comment
diff --git a/doc/forum/Using_integer_ranges_with_metadata/comment_3_c3ce727f93cce19db1f76de9f7216cee._comment b/doc/forum/Using_integer_ranges_with_metadata/comment_3_c3ce727f93cce19db1f76de9f7216cee._comment
new file mode 100644
index 0000000..bdd36a4
--- /dev/null
+++ b/doc/forum/Using_integer_ranges_with_metadata/comment_3_c3ce727f93cce19db1f76de9f7216cee._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2016-04-20T18:25:20Z"
+ content="""
+It's documented in [[git-annex-matching-options]] and
+[[git-annex-preferred-content]].
+"""]]

comment
diff --git a/doc/bugs/OSX_case_insensitive_filesystem/comment_1_2e81165ac03e1d0566c81016e7728ee6._comment b/doc/bugs/OSX_case_insensitive_filesystem/comment_1_2e81165ac03e1d0566c81016e7728ee6._comment
new file mode 100644
index 0000000..01f355e
--- /dev/null
+++ b/doc/bugs/OSX_case_insensitive_filesystem/comment_1_2e81165ac03e1d0566c81016e7728ee6._comment
@@ -0,0 +1,29 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-04-20T18:14:25Z"
+ content="""
+So the directory structure got lower cased when you copied it from OSX to
+linux. OSX remembered a lower-case name for the J4 directory, for example,
+and propigated that over to linux.
+
+Unfortunately, git-annex is stuck using mixed case hash directories for
+backwards compatability reasons. Changing to all lower-case hash
+directories would need every git-annex repo to be converted; would
+invalidate all old tags and branches and history in the repos, etc.
+This is discussed in [[design/new_repo_versions]].
+
+It's actually possible to make brand-new git-annex repos use all lower case
+hash directories today, by setting `git config annex.tune.objecthashlower true`
+before you run `git annex init` for the first time. 
+
+If you know you will need to move a repository between case-insensative and
+case-sensative filesystems, you could use that configuration. But that
+would be very forward looking, and instead users are just going to stumble
+over the mixed case directories from time to time.
+
+What I'd recommend you do is, move the repository back to OSX, and then
+make a clone of it on the linux system, and use `git annex move --all
+--from origin` to move all the annexed file contents over from OSX to
+linux. This method avoids the problem entirely.
+"""]]
diff --git a/doc/design/new_repo_versions.mdwn b/doc/design/new_repo_versions.mdwn
index a42b52b..97bf2c0 100644
--- a/doc/design/new_repo_versions.mdwn
+++ b/doc/design/new_repo_versions.mdwn
@@ -43,7 +43,8 @@ Possible reasons to make changes:
 
   The mixed case hash directories have caused trouble on case-insensative
   filesystems, although that has mostly been papered over to avoid
-  problems.
+  problems. One remaining problem users can stuble on occurs
+  when [[moving a repository from OSX to Linux|bugs/OSX_case_insensitive_filesystem]].
 
 * The hash directories, and also the per-key directories
   can slow down using a repository on a disk (both SSD and spinning).

Added a comment
diff --git a/doc/forum/Using_integer_ranges_with_metadata/comment_2_064e2c5706d1acc0f9e4576ff80407f7._comment b/doc/forum/Using_integer_ranges_with_metadata/comment_2_064e2c5706d1acc0f9e4576ff80407f7._comment
new file mode 100644
index 0000000..cc95e48
--- /dev/null
+++ b/doc/forum/Using_integer_ranges_with_metadata/comment_2_064e2c5706d1acc0f9e4576ff80407f7._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="pigmonkey"
+ subject="comment 2"
+ date="2016-04-20T18:20:43Z"
+ content="""
+Perfect. It works great! Thanks.
+
+Is this documented anywhere? I see it in the [release notes](https://git-annex.branchable.com/news/version_6.20160229/) now, but I didn't see anything mentioned in the metadata, metadata driven views or metadata design pages, or the git-annex-metadata man page. I'm not sure where I should look to see how else I can query the metadata.
+"""]]

comment
diff --git a/doc/bugs/Non-annexed_files_being_annexed_and_not_stored/comment_1_ef6c2dee191e80a46e348c78ba054fc2._comment b/doc/bugs/Non-annexed_files_being_annexed_and_not_stored/comment_1_ef6c2dee191e80a46e348c78ba054fc2._comment
new file mode 100644
index 0000000..7db4ea2
--- /dev/null
+++ b/doc/bugs/Non-annexed_files_being_annexed_and_not_stored/comment_1_ef6c2dee191e80a46e348c78ba054fc2._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-04-20T18:09:37Z"
+ content="""
+Seems that there are two potential bugs here; a file that was stored in git
+somehow got stored in the annex instead, and something seems to have
+happened to the content of the file in the annex.
+
+Try using `git annex log` to see where the content of the file was
+stored in the past and when the content got marked as no longer being
+present.
+
+A looser annex.largefiles setting could result in a modified file
+that had been stored in git being stored in the annex instead.
+Look at the symlink that was checked into git for the annexed file
+and compare that with the sha256sum of the file that you rescued
+from the git history. Are they the same or different?
+"""]]

this bug report/rant section has gotten way past diminishing returns, so I am deleting it
Sorry, but I have no interest in arguing about false equivilances such as
comment 23.
diff --git a/doc/bugs/Can__39__t_add_a_git_repo_to_git_annex__58_____34__Invalid_path_repo__47__.git__47__X__34___for_many_X/comment_10_2c8e8a4f35b392b1cb4dc8104786312d._comment b/doc/bugs/Can__39__t_add_a_git_repo_to_git_annex__58_____34__Invalid_path_repo__47__.git__47__X__34___for_many_X/comment_10_2c8e8a4f35b392b1cb4dc8104786312d._comment
deleted file mode 100644
index b95b3ed..0000000
--- a/doc/bugs/Can__39__t_add_a_git_repo_to_git_annex__58_____34__Invalid_path_repo__47__.git__47__X__34___for_many_X/comment_10_2c8e8a4f35b392b1cb4dc8104786312d._comment
+++ /dev/null
@@ -1,17 +0,0 @@
-[[!comment format=mdwn
- username="JerSou"
- ip="82.228.88.32"
- subject="comment 10"
- date="2014-09-25T19:27:43Z"
- content="""
-I thought a workaround (but I don't think ultimately use) :
-
->    \# for each git repo :
-
->    mv .git .gitToAnnex
-
->    ln -s .gitToAnnex .git
-
->    echo .gitToAnnex >> .gitignore
-
-"""]]
diff --git a/doc/bugs/Can__39__t_add_a_git_repo_to_git_annex__58_____34__Invalid_path_repo__47__.git__47__X__34___for_many_X/comment_11_b0bd8c98b5a4d67f66f8d64665569490._comment b/doc/bugs/Can__39__t_add_a_git_repo_to_git_annex__58_____34__Invalid_path_repo__47__.git__47__X__34___for_many_X/comment_11_b0bd8c98b5a4d67f66f8d64665569490._comment
deleted file mode 100644
index d5cfd74..0000000
--- a/doc/bugs/Can__39__t_add_a_git_repo_to_git_annex__58_____34__Invalid_path_repo__47__.git__47__X__34___for_many_X/comment_11_b0bd8c98b5a4d67f66f8d64665569490._comment
+++ /dev/null
@@ -1,10 +0,0 @@
-[[!comment format=mdwn
- username="diafygi"
- subject="comment 11"
- date="2014-11-17T00:54:08Z"
- content="""
-FYI, comment #10's solution doesn't work. Apparently, git-annex also ignores any `.*` directory or file (can't find documentation on this?).
-
-Unfortunately, this a dealbreaker for me. I wanted to use git-annex in my office to sync my work folder (which includes a several git repos) across three computers.
-
-"""]]
diff --git a/doc/bugs/Can__39__t_add_a_git_repo_to_git_annex__58_____34__Invalid_path_repo__47__.git__47__X__34___for_many_X/comment_12_1a0337d1df87898db3d3dadc911bdb38._comment b/doc/bugs/Can__39__t_add_a_git_repo_to_git_annex__58_____34__Invalid_path_repo__47__.git__47__X__34___for_many_X/comment_12_1a0337d1df87898db3d3dadc911bdb38._comment
deleted file mode 100644
index 46ab89f..0000000
--- a/doc/bugs/Can__39__t_add_a_git_repo_to_git_annex__58_____34__Invalid_path_repo__47__.git__47__X__34___for_many_X/comment_12_1a0337d1df87898db3d3dadc911bdb38._comment
+++ /dev/null
@@ -1,8 +0,0 @@
-[[!comment format=mdwn
- username="https://www.google.com/accounts/o8/id?id=AItOawlkMeBGmu0UM0O8RPxCfmlT2taReMsflWY"
- nickname="Markus"
- subject="comment 12"
- date="2015-01-09T02:09:54Z"
- content="""
-Just adding my voice to the choir: My use case is very similar to Abdó's and git-annex not handling nested git repos is what stopped me from taking it into use sometime ago when I tried it. To me submodules would seem like a good way to handle this, but others here clearly understand git better than I do so I don't have much to add.
-"""]]
diff --git a/doc/bugs/Can__39__t_add_a_git_repo_to_git_annex__58_____34__Invalid_path_repo__47__.git__47__X__34___for_many_X/comment_13_4aad55df0c48767e7a0156ad3b38be7b._comment b/doc/bugs/Can__39__t_add_a_git_repo_to_git_annex__58_____34__Invalid_path_repo__47__.git__47__X__34___for_many_X/comment_13_4aad55df0c48767e7a0156ad3b38be7b._comment
deleted file mode 100644
index 4877fc5..0000000
--- a/doc/bugs/Can__39__t_add_a_git_repo_to_git_annex__58_____34__Invalid_path_repo__47__.git__47__X__34___for_many_X/comment_13_4aad55df0c48767e7a0156ad3b38be7b._comment
+++ /dev/null
@@ -1,22 +0,0 @@
-[[!comment format=mdwn
- username="https://www.google.com/accounts/o8/id?id=AItOawlXt6nnNs-3uw61EGYtxr_AVhJqXybwLR8"
- nickname="Bruno"
- subject="Why this limitation ?"
- date="2015-03-25T22:32:46Z"
- content="""
-I do not understand this limitation ! Why the git-annex exclude the **.git** directory. If the .git is not int the root annex, what the problem ?
-
-Effectively, for me, this limitation is a big problem for archive my working directory (it's contain a some .git folders)
-
-more, is there a command to showing the files not in the annex after executing \"git annex add .\" exist ?
-
-Because it's dangerous to believe that the data is in backup, but in the reality they have not saved
-
-It's a pity, that powerful archiver tool is limited by himself, it lacks some features to be perfectly.
-
-This does not affect your excelent work !
-
-Regards
-
-BA
-"""]]
diff --git a/doc/bugs/Can__39__t_add_a_git_repo_to_git_annex__58_____34__Invalid_path_repo__47__.git__47__X__34___for_many_X/comment_14_44a912174bfbe128ae40bef2a5b351c7._comment b/doc/bugs/Can__39__t_add_a_git_repo_to_git_annex__58_____34__Invalid_path_repo__47__.git__47__X__34___for_many_X/comment_14_44a912174bfbe128ae40bef2a5b351c7._comment
deleted file mode 100644
index 3b3dafb..0000000
--- a/doc/bugs/Can__39__t_add_a_git_repo_to_git_annex__58_____34__Invalid_path_repo__47__.git__47__X__34___for_many_X/comment_14_44a912174bfbe128ae40bef2a5b351c7._comment
+++ /dev/null
@@ -1,20 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 14"""
- date="2015-03-26T14:43:11Z"
- content="""
-@Abdó, @Markus, you suggested using submodules. git-annex recently added
-support for submodules, in version 5.20150317. May still be a little
-rough.
-
-@diafygi, `git annex add .` defaults to not adding dotfiles. This is
-documented, and there is a --include-dotfiles switch, or you can explicitly
-list the dotfiles you want to add.
-
-@Bruno, most of your questions are answered by the thread which appears
-before them.
-
-(I think this bug report may be reaching the end of its usefulness, since
-people seem to want to use it to pile on about a bunch of unrelated topics.
-Please keep this on topic.)
-"""]]
diff --git a/doc/bugs/Can__39__t_add_a_git_repo_to_git_annex__58_____34__Invalid_path_repo__47__.git__47__X__34___for_many_X/comment_15_3a82ba46d172972c046f7e4238d9d109._comment b/doc/bugs/Can__39__t_add_a_git_repo_to_git_annex__58_____34__Invalid_path_repo__47__.git__47__X__34___for_many_X/comment_15_3a82ba46d172972c046f7e4238d9d109._comment
deleted file mode 100644
index 770cf54..0000000
--- a/doc/bugs/Can__39__t_add_a_git_repo_to_git_annex__58_____34__Invalid_path_repo__47__.git__47__X__34___for_many_X/comment_15_3a82ba46d172972c046f7e4238d9d109._comment
+++ /dev/null
@@ -1,11 +0,0 @@
-[[!comment format=mdwn
- username="badele"
- subject="It's dangerous ignore a folder with same level folder of  a .git directory"
- date="2015-03-27T22:16:13Z"
- content="""
-Hi,
-
-I agree to avoid synchronize directories git, but it's not normal ignore the others directories in the same level of the .git directory. For my case, the .git is the garbage of the old project
-
-It would be nice to show a warning message when the files is ignored. Because it's dangerous, the user dont know if the files isn't archived !
-"""]]
diff --git a/doc/bugs/Can__39__t_add_a_git_repo_to_git_annex__58_____34__Invalid_path_repo__47__.git__47__X__34___for_many_X/comment_16_befb4f82ba2d812766b57cec475b52b5._comment b/doc/bugs/Can__39__t_add_a_git_repo_to_git_annex__58_____34__Invalid_path_repo__47__.git__47__X__34___for_many_X/comment_16_befb4f82ba2d812766b57cec475b52b5._comment
deleted file mode 100644
index cfda4f6..0000000
--- a/doc/bugs/Can__39__t_add_a_git_repo_to_git_annex__58_____34__Invalid_path_repo__47__.git__47__X__34___for_many_X/comment_16_befb4f82ba2d812766b57cec475b52b5._comment
+++ /dev/null
@@ -1,19 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 16"""
- date="2015-03-27T22:53:46Z"
- content="""
-@badele, well, it doesn't ignore such a directory.
-
-<pre>
-joey@darkstar:~/tmp/gitrepo>ls -ld subrepo/.git
-drwxr-xr-x 7 joey joey 4096 Mar 27 18:52 subrepo/.git/
-joey@darkstar:~/tmp/gitrepo>mkdir subrepo/dir
-joey@darkstar:~/tmp/gitrepo>touch subrepo/dir/foo
-joey@darkstar:~/tmp/gitrepo>git annex add subrepo/dir/foo
-add subrepo/dir/foo ok
-(recording state in git...)
-</pre>
-
-git and git-annex have the same behavior here..
-"""]]
diff --git a/doc/bugs/Can__39__t_add_a_git_repo_to_git_annex__58_____34__Invalid_path_repo__47__.git__47__X__34___for_many_X/comment_17_0511e8fa74ec3244879a8e5dc05472b3._comment b/doc/bugs/Can__39__t_add_a_git_repo_to_git_annex__58_____34__Invalid_path_repo__47__.git__47__X__34___for_many_X/comment_17_0511e8fa74ec3244879a8e5dc05472b3._comment
deleted file mode 100644
index a358c32..0000000
--- a/doc/bugs/Can__39__t_add_a_git_repo_to_git_annex__58_____34__Invalid_path_repo__47__.git__47__X__34___for_many_X/comment_17_0511e8fa74ec3244879a8e5dc05472b3._comment
+++ /dev/null
@@ -1,28 +0,0 @@
-[[!comment format=mdwn
- username="badele"
- subject="RE: It's dangerous ignore a folder with same level folder of a .git directory"
- date="2015-03-28T10:24:00Z"
- content="""
-Hi,
-
-Exemple of my project directories:
-
-    + /tmp/git-annex
-        + .git (git-annex git)
-        + project_folder_with_git_folder/.git (garbage git project)
-        + project_folder_with_git_folder/folder1
-            + file1
-        + project_folder_with_git_folder/folder2
-            + file2
-
-
-You can reproduce it
-
-    mkdir -p /tmp/git-annex && cd /tmp/git-annex
-    git init
-    git annex init test
-    cp -R project_folder_with_git_folder .
-    git annex add project_folder_with_git_folder
-    
-No files are added
-"""]]
diff --git a/doc/bugs/Can__39__t_add_a_git_repo_to_git_annex__58_____34__Invalid_path_repo__47__.git__47__X__34___for_many_X/comment_18_bfc63bcae4724a5a437c3aee51822f7e._comment b/doc/bugs/Can__39__t_add_a_git_repo_to_git_annex__58_____34__Invalid_path_repo__47__.git__47__X__34___for_many_X/comment_18_bfc63bcae4724a5a437c3aee51822f7e._comment
deleted file mode 100644
index 3cbee23..0000000
--- a/doc/bugs/Can__39__t_add_a_git_repo_to_git_annex__58_____34__Invalid_path_repo__47__.git__47__X__34___for_many_X/comment_18_bfc63bcae4724a5a437c3aee51822f7e._comment
+++ /dev/null
@@ -1,30 +0,0 @@
-[[!comment format=mdwn
- username="annex.nrb@0b99c9078ef84fe229eb6f00841028a57dc07612"
- nickname="annex.nrb"
- subject="Should something else, not annex solve the ad hoc git use case?"
- date="2015-11-17T10:02:24Z"
- content="""
-Hi,
-
-I also struggle to be \"motivated by this use case\" here for Git-Annex.  As one who happens to be using git on files inside hiearchies I'd like to annex (without the gits).  Like many others it seems I am searching for a better solution for my ad hoc gits generated locally for myself (a quick way of push cloning to a remote and auto syncing).  For me Git-annex to ignore .git is enough.  I'd rather have the lower complexity 'does one job well' than introduce a separate work around to the git inside git issue. 
-
-http://git-annex.branchable.com/forum/Git_repos_in_git_annex__63__/?updated#comment-9fca5cf31ccfd3d78c78cb65f7672340

(Diff truncated)
paren
diff --git a/doc/forum/Using_integer_ranges_with_metadata/comment_1_36298a679379e807892cd6af18ec1dd6._comment b/doc/forum/Using_integer_ranges_with_metadata/comment_1_36298a679379e807892cd6af18ec1dd6._comment
index 50dabe9..1179505 100644
--- a/doc/forum/Using_integer_ranges_with_metadata/comment_1_36298a679379e807892cd6af18ec1dd6._comment
+++ b/doc/forum/Using_integer_ranges_with_metadata/comment_1_36298a679379e807892cd6af18ec1dd6._comment
@@ -6,4 +6,8 @@
 This is a great idea! So great that I got in the ol' time machine,
 set the dial for February 29th 2016, and convinced past-me to implement it
 then.
+
+(For some reason, past-me decided to make the syntax `field>=number` and
+`field<=number` instead of the syntax you suggested. He can be a bit of a
+stick in the mud with his own outdated ideas that he holds onto tightly.)
 """]]

fixed via time machine
diff --git a/doc/forum/Using_integer_ranges_with_metadata/comment_1_36298a679379e807892cd6af18ec1dd6._comment b/doc/forum/Using_integer_ranges_with_metadata/comment_1_36298a679379e807892cd6af18ec1dd6._comment
new file mode 100644
index 0000000..50dabe9
--- /dev/null
+++ b/doc/forum/Using_integer_ranges_with_metadata/comment_1_36298a679379e807892cd6af18ec1dd6._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2016-04-20T17:51:43Z"
+ content="""
+This is a great idea! So great that I got in the ol' time machine,
+set the dial for February 29th 2016, and convinced past-me to implement it
+then.
+"""]]