adjust unlocked execute bit handling

When building an adjusted unlocked branch, make pointer files executable
when the annex object file is executable.

This slows down git-annex adjust --unlock/--unlock-present by needing to
stat all annex object files in the tree. Probably not a significant
slowdown compared to other work they do, but I have not benchmarked.

I chose to leave git-annex adjust --unlock marked as stable, even though
get or drop of an object file can change whether it would make the pointer
file executable. Partly because making it unstable would slow down
re-adjustment, and partly for symmetry with the handling of an unlocked
pointer file that is executable when the content is dropped, which does not
remove its execute bit.

Annex/AdjustedBranch.hs

@@ -1,6 +1,6 @@
 {- adjusted branch
  -
- - Copyright 2016-2023 Joey Hess <id@joeyh.name>
+ - Copyright 2016-2024 Joey Hess <id@joeyh.name>
  -
  - Licensed under the GNU AGPL version 3 or higher.
  -}
@@ -68,9 +68,12 @@ import qualified Database.Keys
 import Config
 import Logs.View (is_branchView)
 import Logs.AdjustedBranchUpdate
+import Utility.FileMode
+import qualified Utility.RawFilePath as R
 
 import Data.Time.Clock.POSIX
 import qualified Data.Map as M
+import System.PosixCompat.Files (fileMode)
 
 class AdjustTreeItem t where
 	-- How to perform various adjustments to a TreeItem.
@@ -155,8 +158,13 @@ adjustToPointer :: TreeItem -> Annex (Maybe TreeItem)
 adjustToPointer ti@(TreeItem f _m s) = catKey s >>= \case
 	Just k -> do
 		Database.Keys.addAssociatedFile k f
-		Just . TreeItem f (fromTreeItemType TreeFile)
+		exe <- catchDefaultIO False $
-			<$> hashPointerFile k
+			(isExecutable . fileMode) <$> 
+				(liftIO . R.getFileStatus
+					=<< calcRepo (gitAnnexLocation k))
+		let mode = fromTreeItemType $ 
+			if exe then TreeExecutable else TreeFile
+		Just . TreeItem f mode <$> hashPointerFile k
 	Nothing -> return (Just ti)
 
 adjustToSymlink :: TreeItem -> Annex (Maybe TreeItem)

CHANGELOG

@@ -5,6 +5,8 @@ git-annex (10.20240431) UNRELEASED; urgency=medium
     (Based on Michael Hanke's git-remote-datalad-annex.)
   * initremote, enableremote: Added --with-url to enable using
     git-remote-annex.
+  * When building an adjusted unlocked branch, make pointer files
+    executable when the annex object file is executable.
   * fsck: Fix recent reversion that made it say it was checksumming files
     whose content is not present.
   * Avoid the --fast option preventing checksumming in some cases it

doc/bugs/adjust_or_sync_in_unlock-present_repo_removes_+x_permission.mdwn

@@ -34,3 +34,5 @@ annex.alwayscommit = false.
 
 PS: git-annex is so solid that this is the first data-related issue I've 
 ever seen. Kudos!
+
+> [[fixed|done]] --[[Joey]]

doc/bugs/adjust_or_sync_in_unlock-present_repo_removes_+x_permission/comment_1_c081e6824b116ca4960dc31a0a20b81a._comment

@@ -37,4 +37,11 @@ than stat.
 
 Overall, I think this is probably worth doing, just to be symmetric with
 `git-annex unlock`.
+
+There's also an argument that, if I have a large executable (LLM models
+come to mind for some ungodly reason), and I annex it and enter an adjusted
+branch, I should still be able to run it. Although it's really better to
+add it unlocked in the first place, since then you're tracking the execute
+bit in git permanantly and not relying on best-effort execute bit
+preservation when copying objects around.
 """]]

doc/bugs/adjust_or_sync_in_unlock-present_repo_removes_+x_permission/comment_2_39b5177e7666c7a3680458749cb0f600._comment

@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2024-05-28T16:27:10Z"
+ content="""
+If the object file is executable at `git-annex unlock` time, the pointer
+file is made executable. If the object is then dropped, the pointer file
+remains executable.
+
+So shouldn't it be the case for symmetry that `git-annex adjust --unlock`
+should make the pointer file executable, and a drop followed by re-doing
+the same adjustment should leave the pointer file executable? That would
+argue for leaving it stable.
+
+I don't think there's a perfect solution to that question, both behaviors
+seem perhaps wanted at different times. But since leaving it stable avoids
+extra work, I'm leaning toward that.
+"""]]