Alternatively, the old key could be left on a special remote, but update
the location log for the special remote to say it has the new key,
and have git-annex request the old key when it wants to get (or checkpresent)
-the content from the special remote. This would need the mapping to be
-cheap enough to query that it won't signficantly slow down accessing a
-special remote.
+the new key from the special remote. (Being careful to verify the content
+using the new key when downloading from the old key on the special remote.)
+This would need the mapping to be cheap enough to query that it won't
+signficantly slow down accessing a special remote.
+
+> A complication is that the special remote could end up containing both
+> old and new key. So it would need to fall back from one to the other for
+> get and checkpresent. Which will double the number of round trips to the
+> special remote if it tries the wrong one first.
+>
+> And how to handle dropping from a special remote then? It would need to
+> update the location log for both old key and new key when dropping the
+> old key or the new key. But when the special remote stores both the old
+> and new key on it separately, dropping one should not change the location
+> log for the other. So it seems it would need to drop the key, then check
+> if the other key is stored there and if not, update the location log to
+> indicate it's not present.
Rather than a dedicated command that users need to remember to run,
distributed migration could be done automatically when merging a git-annex
--- /dev/null
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2023-12-01T19:00:41Z"
+ content="""
+Even if the stuff with special remotes turned out to be too complicated to
+implement, `git-annex migrate --update` would be useful for some users.
+So it's worth implementing the mapping and then incrementally implementing
+these ideas.
+"""]]