git-annex/ git-annex-move

# NAME

git-annex move - move content of files to/from another repository

# SYNOPSIS

git annex move `[path ...] [--from=remote|--to=remote|--to=here]`

# DESCRIPTION

Moves the content of files from or to another remote.

With no parameters, operates on all annexed files in the current directory. Paths of files or directories to operate on can be specified.

# OPTIONS

- `--from=remote`

  Move the content of files from the specified remote to the local repository.

- `--to=remote`

  Move the content of files from the local repository to the specified remote.

- `--to=here`

  Move the content of files from all reachable remotes to the local repository.

- `--from=remote1 --to=remote2`

  Move the content of files that are in remote1 to remote2. Does not change what is stored in the local repository.

  This is implemented by first downloading the content from remote1 to the local repository (if not already present), then sending it to remote2, and then deleting the content from the local repository (if it was not present to start with).

- `--from-anywhere --to=remote`

  Move to the remote files from the local repository and from all reachable remotes.

- `--force`

  Override numcopies and required content checking, and always remove files from the source repository once the destination repository has a copy.

  Note that, even without this option, you can move the content of a file from one repository to another when numcopies is not satisfied, as long as the move does not result in there being fewer copies.

- `--jobs=N` `-JN`

  Enables parallel transfers with up to the specified number of jobs running at once. For example: `-J10`

  Setting this to "cpus" will run one job per CPU core.

  Note that when using --from with --to, twice this many jobs will run at once, evenly split between the two remotes.

- `--all` `-A`

  Rather than specifying a filename or path to move, this option can be used to move all available versions of all files.

  This is the default behavior when running git-annex in a bare repository.

- `--branch=ref`

  Operate on files in the specified branch or treeish.

- `--unused`

  Operate on files found by last run of git-annex unused.

- `--failed`

  Operate on files that have recently failed to be transferred.

- `--key=keyname`

  Use this option to move a specified key.

- matching options

  The git-annex-matching-options(1) can be used to control what to move.

- `--batch`

  Enables batch mode, in which lines containing names of files to move are read from stdin.

  As each specified file is processed, the usual progress output is displayed. If a file's content does not need to be moved, or it does not match specified matching options, or it is not an annexed file, a blank line is output in response instead.

  Since the usual output while moving a file is verbose and not machine-parseable, you may want to use --json in combination with --batch.

- `--batch-keys`

  This is like `--batch` but the lines read from stdin are parsed as keys.

- `-z`

  Makes batch input be delimited by nulls instead of the usual newlines.

- `--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-progress`

  Include progress objects in JSON output.

- `--json-error-messages`

  Messages that would normally be output to standard error are included in the JSON instead.

- Also the git-annex-common-options(1) can be used.

# SEE ALSO

git-annex(1)

git-annex-get(1)

git-annex-copy(1)

git-annex-drop(1)

# AUTHOR

Joey Hess id@joeyh.name

Warning: Automatically converted into a man page by mdwn2man. Edit with care.

comment 7

Use `git mv` if you want to rename an annexed file. That does not change the key, the old key will work fine despite the extension having changed.

Comment by joey — Wed Oct 29 14:05:27 2025
comment 6

Renaming files is still somewhat unclear then. So I should just use `git mv` to rename files? What if the file extension changes? E.g. I have lots of pictures with uppercase `.JPG` and I might want to change them to `.jpg`. I might also have some files as `.jpeg` and to unify them, I might change them as well to `.jpg`. But as far as I understand, that would also change the default hash, as the default hash contains the extension? But doing `git mv` will take care about all of that via pre-commit hooks?

Comment by AlbertZeyer — Wed Oct 29 14:05:27 2025
comment 5
`git annex move` belongs so the same class of commands as `git annex get`, `git annex drop` and `git annex copy` in that it manages file content. Git annex automatically registers a pre-commit hook to fixup symlinks. `git annex fix` can also be used to fixup symlinks, but it currently is broken.
Comment by Lukey — Wed Oct 29 14:05:27 2025
rename or move files

Is this command also for renaming or moving files, like `git mv`?

If not, I think this should be explained more clearly in the documentation.

If not, how would I move/rename files then? As I understand, annexed files are just symlinks. So if I would move the file to another directory (e.g. via `git mv` or just `mv`), the symlink might break.

Comment by AlbertZeyer — Wed Oct 29 14:05:27 2025
comment 3

git-annex always reuses TCP connections.

More likely you are using an older version of git-annex which had some overhead due to running rsync once per transfer. Since version 6.20180316 git-annex has avoided that overhead.

Comment by joey — Wed Oct 29 14:05:27 2025
3rd party "mover" / speed up git annex move
git annex move seems to be quite slow if many small files have to be transferred. I think the main issue is that for each file a new TCP connection is opened. In this case reusing the TCP connection could significantly speed up the transfers. Two questions about this. a) Am I just doing something wrong? (I don't want to use -J because the remote is cluster and -J connects to different servers.) b) Is there an efficient method to write my own mover for the files in question? Basically "git annex find [...] --json" gives me all the files in question, so I know what to move. But after copying them to the remote, how do I tell git annex that they are there? Does it make sense to use git annex reinject?
Comment by mario — Wed Oct 29 14:05:27 2025
Move from A to B

It would be awesome to be able to move (or copy) between remotes, eg. `git annex copy --from=remote-a --to=remote-b`

Use case: I have a repo of ~1TB, but only ~30GB free disk space on my laptop. Currently I have to manually `get` and `move` the files almost one by one to get them from one remote to the other.

Comment by lykos — Wed Oct 29 14:05:27 2025
Comments on this page are closed.