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

@ -27,7 +27,25 @@ this can also be used to migrate files to use the new key format.
* `--update`
This updates the local repository for migrations that were performed
elsewhere.
elsewhere. Only new migrations since the last time this was run will
be performed.
This does not modify the working tree, but only hard links
(or in some cases copies) annex objects to their new keys.
Note that older versions of git-annex did not record migrations in a
way that this can use. Migrations performed with those older versions
had to be manually run in each clone of the repository.
* `--apply`
This applies all recorded migrations to the local repository. It is the
non-incremental form of `--update`.
One situation where this can be useful is when `git-annex migrate
--update` has been run, but since then un-migrated
objects have entered the repository. Using this option ensures that
any such objects get migrated.
Note that older versions of git-annex did not record migrations in a
way that this can use. Migrations performed with those older versions