fix export subtree reversion

Fix reversion in last release that caused wrong tree to be written to
remote tracking branch after an export of a subtree.

The invariant "commitsha should have the treesha as its tree"
was not met due to a bug. Guarantee it's met by catting the commitsha
to find its actual tree. A little bit slower, but this is not run often.

Annex/Import.hs

@@ -192,7 +192,7 @@ buildImportCommit' importcommitconfig mtrackingcommit imported@(History ti _) =
 					let oldimportedtrees = mapHistory historyCommitTree oldimported
 					mknewcommits oldhc oldimportedtrees imported
 			Just <$> makeRemoteTrackingBranchMergeCommit'
-				trackingcommit importedcommit ti
+				trackingcommit importedcommit
 	  where
 		h'@(History t s) = mapHistory historyCommitTree h
 

Annex/RemoteTrackingBranch.hs

@@ -16,6 +16,7 @@ module Annex.RemoteTrackingBranch
 	) where
 
 import Annex.Common
+import Annex.CatFile
 import Git.Types
 import qualified Git.Ref
 import qualified Git.Branch
@@ -49,11 +50,9 @@ setRemoteTrackingBranch tb commit =
  - But since we know that the second parent consists entirely of such
  - import commits, they can be reused when updating the
  - RemoteTrackingBranch.
- -
- - The commitsha should have the treesha as its tree.
  -}
-makeRemoteTrackingBranchMergeCommit :: RemoteTrackingBranch -> Sha -> Sha -> Annex Sha
-makeRemoteTrackingBranchMergeCommit tb commitsha treesha =
+makeRemoteTrackingBranchMergeCommit :: RemoteTrackingBranch -> Sha -> Annex Sha
+makeRemoteTrackingBranchMergeCommit tb commitsha =
 	-- Check if the tracking branch exists.
 	inRepo (Git.Ref.sha (fromRemoteTrackingBranch tb)) >>= \case
 		Nothing -> return commitsha
@@ -61,15 +60,19 @@ makeRemoteTrackingBranchMergeCommit tb commitsha treesha =
 			Nothing -> return commitsha
 			Just (History hc _) -> case historyCommitParents hc of
 				[_, importhistory] ->
-					makeRemoteTrackingBranchMergeCommit' commitsha importhistory treesha
+					makeRemoteTrackingBranchMergeCommit' commitsha importhistory
 				-- Earlier versions of git-annex did not
 				-- make the merge commit, or perhaps
 				-- something else changed where the
 				-- tracking branch pointed.
 				_ -> return commitsha
 
-makeRemoteTrackingBranchMergeCommit' :: Sha -> Sha -> Sha -> Annex Sha
-makeRemoteTrackingBranchMergeCommit' commitsha importedhistory treesha = 
+makeRemoteTrackingBranchMergeCommit' :: Sha -> Sha -> Annex Sha
+makeRemoteTrackingBranchMergeCommit' commitsha importedhistory = do
+	treesha <- maybe
+		(giveup $ "Unable to cat commit " ++ fromRef commitsha)
+		commitTree
+		<$> catCommit commitsha
 	inRepo $ Git.Branch.commitTree
 			Git.Branch.AutomaticCommit
 			"remote tracking branch"

CHANGELOG

@@ -1,3 +1,10 @@
+git-annex (7.20190504) UNRELEASED; urgency=medium
+
+  * Fix reversion in last release that caused wrong tree to be written
+    to remote tracking branch after an export of a subtree.
+
+ -- Joey Hess <id@joeyh.name>  Mon, 06 May 2019 13:52:02 -0400
+
 git-annex (7.20190503) upstream; urgency=medium
 
   * adb special remote supports being configured with importtree=yes,

Command/Export.hs

@@ -235,7 +235,7 @@ fillExport r db newtree mtbcommitsha = do
 		Nothing -> noop
 		Just (tb, commitsha) ->
 			whenM (liftIO $ fromAllFilled <$> takeMVar allfilledvar) $
-				makeRemoteTrackingBranchMergeCommit tb commitsha newtree
+				makeRemoteTrackingBranchMergeCommit tb commitsha
 					>>= setRemoteTrackingBranch tb
 	
 	liftIO $ fromFileUploaded <$> takeMVar cvar

doc/bugs/remote_tracking_exporttree_importtree_directory.mdwn

@@ -49,3 +49,4 @@ ls
 ### 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)
 git-annex does a great job in managing my distributed backups. Thanks!
 
+> [[fixed|done]] --[[Joey]]

doc/bugs/remote_tracking_exporttree_importtree_directory/comment_2_894698b0136c3bad155109577848c52f._comment

@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2019-05-06T16:47:49Z"
+ content="""
+It's not limited to git-annex sync, running import followed by merge and
+then export shows the same behavior on the 3rd run. Without the export step, 
+the bug doesn't happen.
+
+The problem actually is in the second pass, the import is ok, but then the
+export sets the remote tracking branch to only contain the subdirectory.
+Then in the third pass that bad basis is used by the import (which does
+nothing) and gets merged.
+
+Why does only the second export trigger the bug, not the first?
+Has to do with makeRemoteTrackingBranchMergeCommit and the shape of the
+commit history.
+
+Indeed, 7.20190322 doesn't have this bug, it was introduced in
+the newest release which added makeRemoteTrackingBranchMergeCommit.
+The export code accidentially passed a tree to that.
+"""]]