migrate --apply
authorJoey Hess <joeyh@joeyh.name>
Fri, 8 Dec 2023 17:23:03 +0000 (13:23 -0400)
committerJoey Hess <joeyh@joeyh.name>
Fri, 8 Dec 2023 17:23:46 +0000 (13:23 -0400)
commit4ed71b34dedfc45223cf965c4bce197af84e5192
treefecdfb78aea4429472a7e94005ec83501baca455
parent51b974d9f03c080378cabdf0d70eec11146962af
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
CHANGELOG
Command/Migrate.hs
Logs/Location.hs
Logs/Migrate.hs
Logs/Presence.hs
Logs/Presence/Pure.hs
Logs/Web.hs
doc/git-annex-migrate.mdwn