migrate --apply

And avoid migrate --update/--aply migrating when the new key was already
present in the repository, and got dropped. Luckily, the location log
allows distinguishing from the new key never having been present!

That is mostly useful for --apply because otherwise dropped files would
keep coming back until the old objects were reaped as unused. But it
seemed to make sense to also do it for --update. for consistency in edge
cases if nothing else. One case where --update can use it is when one
branch got migrated earlier, and we dropped the file, and now another
branch has migrated the same file.

Sponsored-by: Jack Hill on Patreon

Logs/Migrate.hs

@@ -117,15 +117,18 @@ commitMigration = do
 				(asTopFilePath migrationTreeGraftPoint)
 			committedMigration commitsha
 
--- Streams distributed migrations from the git-annex branch that have not
--- been performed here, and runs the provided action on each old and new
--- key pair.
-streamNewDistributedMigrations :: (Key -> Key -> Annex ()) -> Annex ()
-streamNewDistributedMigrations a = do
+-- Streams distributed migrations from the git-annex branch,
+-- and runs the provided action on each old and new key pair.
+--
+-- With the incremental option, only scans as far as the last recorded
+-- migration that this has handled before.
+streamNewDistributedMigrations :: Bool -> (Key -> Key -> Annex ()) -> Annex ()
+streamNewDistributedMigrations incremental a = do
 	void Annex.Branch.update
 	branchsha <- Annex.Branch.getBranch
 	(stoppoint, toskip) <- getPerformedMigrations
-	(l, cleanup) <- inRepo $ getGitLog branchsha stoppoint
+	(l, cleanup) <- inRepo $ getGitLog branchsha
+		(if incremental then stoppoint else Nothing)
 		[fromRawFilePath migrationTreeGraftPoint]
 		-- Need to follow because migrate.tree is grafted in 
 		-- and then deleted, and normally git log stops when a file