Merge branch 'master' of ssh://git-annex.branchable.com into master

diff --cc doc/todo/memory_use_increase/comment_4_774d540ce6f5c3ffda924159e146721e._comment
index 5d94c1cedca45fbe39b891e6a513e1a1899fa878,5371142eac0ac064471b58b1d91230b4e31ff701..f877c890002da04fdf588ed4446b04574e946c52
--- 1/doc/todo/memory_use_increase/comment_4_774d540ce6f5c3ffda924159e146721e._comment
--- 2/doc/todo/memory_use_increase/comment_4_774d540ce6f5c3ffda924159e146721e._comment
+++ b/doc/todo/memory_use_increase/comment_4_774d540ce6f5c3ffda924159e146721e._comment
@@@ -22,11 -28,16 +22,11 @@@ single chunk input, that bypasses the u
  
      goLen1 _   bs Empty = bs
  
 -So, that keeps the original strict bytestring, not copying it. And so
 -the rest of it, after the NULL, remains allocated!
 -
 -This is surprising behavior. Could even be a bug. L.toStrict does
 -say that it copies all the data, but not that it pins data that is not
 -even part of the input bytestring as far as the user is concerned.
 -
 -So that explains the PINNED memory use.
 +That keeps the original strict bytestring, not copying it. And so
 +the rest of it, after the NULL, remains allocated for as long as the result
 +is in use.
  
 -So, I think git-annex needs to stop using L.toStrict here
 -(and probably everywhere involving streaming any amount of data),
 -there are some other ones.
 +Hmm, this doesn't explain the memory leak (throwing in a S.copy didn't fix
 +it either) or why profiling doesn't show the full memory use, but it does
- explain the PINNED memory use, probably.
++start to explain the PINNED memory use.
  """]]