skip distributed migration to insecure key when annex.securehashesonly is set
authorJoey Hess <joeyh@joeyh.name>
Fri, 8 Dec 2023 16:39:18 +0000 (12:39 -0400)
committerJoey Hess <joeyh@joeyh.name>
Fri, 8 Dec 2023 16:41:50 +0000 (12:41 -0400)
This only avoids extra work and a warning messsage. It seems likely that
in such a situation, the user does not want migrations to insecure
hashes, and so best to ignore them as much as possible. If
the user merges a branch that switches annexed files to an insecure
hash, they will notice that the file contents are unavailable,
and git-annex get will tell them the problem then. So it does not seem
useful to have migrate --update also complain about it.

Command/Migrate.hs

index 65652a8c635cd6f231ccd40823aa5d894994e855..e184bf588fa8544ec98d22886f9693dd84e2988f 100644 (file)
@@ -149,7 +149,7 @@ perform onlyremovesize o file oldkey oldkeyrec oldbackend newbackend = go =<< ge
 
 update :: Key -> Key -> CommandStart
 update oldkey newkey =
-       stopUnless ((not <$> inAnnex newkey) <&&> inAnnex oldkey) $ do
+       stopUnless ((not <$> inAnnex newkey) <&&> inAnnex oldkey <&&> allowed) $ do
                ai <- findworktreefile >>= return . \case
                        Just f -> ActionItemAssociatedFile (AssociatedFile (Just f)) newkey
                        Nothing -> ActionItemKey newkey
@@ -161,6 +161,11 @@ update oldkey newkey =
                                , next $ return False
                                )
   where
+       -- annex.securehashesonly will block adding keys with insecure
+       -- hashes, this check is only to avoid doing extra work and
+       -- displaying a message when it fails.
+       allowed = isNothing <$> checkSecureHashes newkey
+
        findworktreefile = do
                fs <- Database.Keys.getAssociatedFiles newkey
                g <- Annex.gitRepo