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
This commit is contained in:
Joey Hess 2023-12-08 13:23:03 -04:00
parent 51b974d9f0
commit 4ed71b34de
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
8 changed files with 78 additions and 25 deletions

View file

@ -70,14 +70,18 @@ buildLog = mconcat . map genline
genstatus InfoMissing = charUtf8 '0'
genstatus InfoDead = charUtf8 'X'
{- Given a log, returns only the info that is are still in effect. -}
{- Given a log, returns only the info that is still present. -}
getLog :: L.ByteString -> [LogInfo]
getLog = map info . filterPresent . parseLog
{- Returns the info from LogLines that are in effect. -}
{- Returns the info from LogLines that is present. -}
filterPresent :: [LogLine] -> [LogLine]
filterPresent = filter (\l -> InfoPresent == status l) . compactLog
{- Returns the info from LogLines that is not present. -}
filterNotPresent :: [LogLine] -> [LogLine]
filterNotPresent = filter (\l -> InfoPresent /= status l) . compactLog
{- Compacts a set of logs, returning a subset that contains the current
- status. -}
compactLog :: [LogLine] -> [LogLine]