git-annex-migrate(1)

💖 git-annex-migrate — switch data to different backend 💖

okay bestie, welcome to the git-annex-migrate(1) page, you're gonna eat this up ✨

---

🌸 SYNOPSIS 🌸

git annex migrate [path ...]

git annex migrate --update

---

🦋 DESCRIPTION 🦋

So like, what this does is it switches the annexed files you point at over to the default key-value backend (or, if you're feeling spicy, whatever one you named with --backend). Small catch though: only files whose content is currently present get migrated. If the content isn't there, nothing happens, no cap.

Also, real talk: after the migration, your content is still sitting there stored under the old keys. When it can, it uses hard links so that doesn't eat up extra disk space, which is iconic of it. Then you go run git annex unused to find those old keys and yeet them out of existence. 🗑️

Normally, if a file is already chillin' on the new backend, nothing gets done to it. BUT — and this is the fun part — if a backend changes the info it uses to construct a key, you can use this to migrate files onto the new key format. Lowkey magical. ✨

---

💅 OPTIONS 💅

• --update — This one updates your local repository for migrations that were performed somewhere else. Only the new migrations since the last time you ran this will actually get performed. It does not touch the working tree — it only hard links (or, in some cases, copies) annex objects over to their new keys. git-annex pull and git-annex sync --content do this automatically for you, unless the annex.syncmigrations config is set to false.

Heads up bestie: older versions of git-annex didn't record migrations in a way this can use. Migrations done with those old versions had to be manually run in each clone of the repository. 💀

• --apply — Applies all recorded migrations to the local repository. It's basically the non-incremental version of --update. One situation where this is genuinely useful: when git-annex migrate --update has been run, but since then un-migrated objects have entered the repository. Using this option makes sure any of those little stragglers get migrated. 🫶

Same warning as above, bestie: 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. 😭

• --backend — Specify the new key-value backend to use for the migrated data. Pick your fighter. 👑
• --force — Force migration of keys that are already using the new backend. No chill, just vibes.
• file matching options — The git-annex-matching-options(1) can be used to specify files to migrate. 🎯
• Also the git-annex-common-options(1) can be used.
• --remove-size — Okay so keys often include the size of their content, and honestly that's generally a useful thing to have. In fact, this command defaults to adding missing size information to keys in most migrations. But with this option, the size info gets removed instead. One use for this is converting URL keys that were added by git-annex addurl --fast into the ones that would have been added if that command had been run with the --relaxed option. Eg:

git-annex migrate --remove-size --backend=URL somefile

To add back the size to an URL key, use this:

git-annex migrate --backend=URL somefile

• --json — Enable JSON output. This is intended to be parsed by programs that use git-annex. Each line of output is a JSON object. 🤖
• --json-error-messages — Messages that would normally be output to standard error are included in the JSON instead. Fancy. ✨

---

🌈 SEE ALSO 🌈

• git-annex(1)
• git-annex-upgrade(1)
• git-annex-backend(1)

---

👑 AUTHOR 👑

Joey Hess <id@joeyh.name> — absolute legend, we stan. 💜

---

and that's the whole git-annex-migrate(1) manual, bestie! mwah, go migrate something cute 💖🎀🦋