Currently, git-annex-migrate leads to content (and metadata) being stored under both old and new keys. git-annex-unused can drop the contents under the old key, but then you can't access the content if you check out an older commit. Maybe, an option can be added to migrate keys using git-replace ? You'd git-replace the blob .git/annex/objects/old_key with the blob .git/annex/objects/new_key, the blob ../.git/annex/objects/old_key with the blob ../.git/annex/objects/new_key , etc. You could then also have a setting to auto-migrate non-checksum keys to checksum keys whenever the contents gets downloaded.
More generally, git-annex-replace could be implemented this way, doing what git-replace does, but for git-annex keys rather than git hashes. git-annex-pre-commit might need to be changed to implement replacement of keys added later.
Very interesting idea! But some problems:
As mentioned, not only
.git/annex/<...>blobs need to be replaces for every key, but also/annex/<...>and all../.git/annex/<...>,../../.git/annex/<...>, etc.In big repositories it can create a giant amount of refs/replace/ refs. I don't know how it affects the performance if they are stored in .git/packed-refs, but it can interfere with the normal operation on a repo. For example
git show-refwill not work without| grepor something.In the meantime, distributed migration has been implemented, allowing to
git-annex migrate --updateto catch up with all migrations that were started elsewhere.This is essentially the same goal, and it is much more efficient in terms of storage than git-replace of a large number of refs.
So, I'm going to close this.