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.
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
, 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