When annex.thin is set, allow hard links to be made between executable work tree files and annex objects.

This is safe, because while the annex object ends up executable,
there were already at least two other cases where it ended up executable:

1. git add an an executable file
2. chmod +x of a a non-executable worktree file that was hard linked to the
   annex object

After copy/hard link, it always fixes up the permissions to match the mode
of the worktree file, so when an executable annex object gets hard linked
to a non-executable worktree file, its execute bit gets removed.

Commit b7c8bf5274 already *said* it would do
this; I suspect the line of code I've removed was included in that commit
accidentially.

Also improves annex.thin documentation.

This commit was sponsored by Boyd Stephen Smith Jr. on Patreon.

Annex/Content/LowLevel.hs

@@ -49,7 +49,6 @@ linkOrCopy = linkOrCopy' (annexThin <$> Annex.getGitConfig)
 
 linkOrCopy' :: Annex Bool -> Key -> FilePath -> FilePath -> Maybe FileMode -> Annex (Maybe LinkedOrCopied)
 linkOrCopy' canhardlink key src dest destmode
-	| maybe False isExecutable destmode = copy =<< getstat
 	| otherwise = catchDefaultIO Nothing $
 		ifM canhardlink
 			( hardlink

CHANGELOG

@@ -44,6 +44,8 @@ git-annex (7.20181025) UNRELEASED; urgency=medium
     exporttree remote.
   * init --version=6 will still work, but the repository is auto-upgraded
     immediately to v7.
+  * When annex.thin is set, allow hard links to be made between executable
+    work tree files and annex objects.
 
  -- Joey Hess <id@joeyh.name>  Sat, 13 Oct 2018 00:52:02 -0400
 

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.
+"""]]

doc/git-annex.mdwn

@@ -1024,14 +1024,17 @@ Here are all the supported configuration settings.
 * `annex.thin`
 
   Set this to `true` to make unlocked files be a hard link to their content
-  in the annex, rather than a second copy. (Only when supported by the file
-  system, and only in repository version 6.) This can save considerable
+  in the annex, rather than a second copy. This can save considerable
   disk space, but when a modification is made to a file, you will lose the
   local (and possibly only) copy of the old version. So, enable with care.
 
   After setting (or unsetting) this, you should run `git annex fix` to
   fix up the annexed files in the work tree to be hard links (or copies).
  
+  Note that this has no effect when the filesystem does not support hard links.
+  And when multiple files in the work tree have the same content, only
+  one of them gets hard linked to the annex.
+
 * `annex.delayadd`
 
   Makes the watch and assistant commands delay for the specified number of