Avoid grafting in export tree objects that are missing

They could be missing due to an interrupted git-annex at just the wrong
time during a prior graft, after which the tree objects got garbage
collected.

Or they could be missing because of manual messing with the git-annex
branch, eg resetting it to back before the graft commit.

Sponsored-by: Dartmouth College's OpenNeuro project

Annex/Branch.hs

@@ -889,9 +889,13 @@ performTransitionsLocked jl ts neednewlocalbranch transitionedrefs = do
 		return c
 	  where
 		regraft [] c = pure c
-		regraft (et:ets) c = 
-			prepRememberTreeish et graftpoint c
-				>>= regraft ets
+		regraft (et:ets) c =
+			-- Verify that the tree object exists.
+			catObjectDetails et >>= \case
+				Just _ ->
+					prepRememberTreeish et graftpoint c
+						>>= regraft ets
+				Nothing -> regraft ets c
 		graftpoint = asTopFilePath exportTreeGraftPoint
 
 checkBranchDifferences :: Git.Ref -> Annex ()

doc/bugs/annex_merge__breaks_git_repository__33__.mdwn

@@ -53,3 +53,4 @@ there are good and there are some bad days ;)
 [[!meta author=yoh]]
 [[!tag projects/openneuro]]
 
+> [[fixed|done]] --[[Joey]]

doc/bugs/annex_merge__breaks_git_repository__33__/comment_9_67dfc2b1444bd345f911ed779cb98bcc._comment

@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 9"""
+ date="2024-06-07T20:25:27Z"
+ content="""
+Note that at least in the case of ds002144, its git-annex branch does not
+contain grafts of the missing trees. The grafts only get created in the
+clone when dealing with a transition.
+
+So, it seems that to recover from the problem, at least in the case of this
+repository, it will be sufficient for git-annex to avoid regrafting trees
+if the object is missing.
+
+Done that, and so I suppose this bug can be closed. I'd be more satified if
+I knew how this repository was produced though.
+"""]]