Merge branch 'v7'

doc/bugs/Metadata_views_in_v6_repo_upgraded_from_direct_mode_act_strangely.mdwn

@@ -77,3 +77,5 @@ file_%subdir%
 
 ### 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)
 Yep! I already use it to move files between my laptop's HDD and SSD, and to copy files between my many SD cards. I was trying this to see if I could not have to scroll as far on my 3D printer's menu.
+
+> [[done]] see comments --[[Joey]]

doc/bugs/Metadata_views_in_v6_repo_upgraded_from_direct_mode_act_strangely/comment_4_17838fe16ad66af62ac809829d8ede99._comment

@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2018-10-26T16:53:47Z"
+ content="""
+`git annex adjust --hide-missing` is now available to do what you want
+re hiding missing files.
+
+`git annex view` doesn't currently unlock files in a v6 repo, so it's not
+usable on a crippled filesystem. That's why the cat in the transcript above
+shows the symlink content which git writes to a regular file when in a
+crippled filesystem.
+
+I would like to eventually unify adjust with view, so `git annex adjust
+--unlock` can be used with a view, which would support that.
+See [[todo/unify_adjust_with_view]].
+"""]]

doc/bugs/git-annex-sync_sometimes_fails_in_submodule_in_V6_adjusted_branch/comment_1_f85e1b0af1a1f67c39806ba69cb0c4ed._comment

@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2018-10-26T17:04:09Z"
+ content="""
+Have you ever seen this again or have any more information about how to
+reproduce it?
+
+This seems similar to the problem fixed by [[!commit a13c0ce66c6dd5d8cf5b09ee2fc5a58f43db4b14]]
+but the version you were using already had that commit in it.
+"""]]

doc/bugs/v6_hardlinking_is_not_stable_across_lock__47__unlock_or_cloning.mdwn

@@ -377,3 +377,5 @@ total 12
 lil' positive end note mode on:
 
 git-annex is the only thing to which I trust my archive of most valuable documents and memories!
+
+> [[done]]; see comments --[[Joey]]

doc/bugs/v6_hardlinking_is_not_stable_across_lock__47__unlock_or_cloning/comment_4_41478c52765cf09a94c7137437ad8716._comment

@@ -5,6 +5,7 @@
  subject="comment 4"
  date="2018-10-18T23:34:26Z"
  content="""
+
 I am stupid talking about executable files hardlinking. I think I just chmod-ed already hardlinking files, that's how I got it. No surprise.
 
 I am ok with this quirk (executable files are not thinned), but just curious: what exactly influenced such design decision?

doc/bugs/v6_hardlinking_is_not_stable_across_lock__47__unlock_or_cloning/comment_5_2b36163f3c8cca18ce4b05e381bf1795._comment

@@ -0,0 +1,24 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2018-10-26T17:17:35Z"
+ content="""
+[[!commit b7c8bf5274a64389ac87d6ce0388b8708c261971]] is where that was
+implemented. Interestingly, its commit message does say that the annex
+object file is made executable when using annex.thin.
+And indeed, git add of an executable file with annex.thin set does
+make the object executable and hard link to it.
+
+But that commit contains this line that avoids hard linking:
+
+	        | maybe False isExecutable destmode = copy =<< getstat
+
+Which is what I based my earlier comment on. But without that line,
+AFAIK it will behave the way you want, with the annex object and
+executable worktree file being hard linked. The code also removes the
+execute bit if the annex object file later ends up getting hard linked
+instead to a non-executable file.
+
+So, based on this analysis, I'm going to remove that line. And improve the
+annex.thin docs slightly, and I think that's sufficient to close this bug.
+"""]]