git-annex/ git-annex-reinject

# NAME

git-annex reinject - inject content of file back into annex

# SYNOPSIS

git annex reinject `[src dest]`

git annex reinject --known `[src]`

# DESCRIPTION

Moves the content of the src file or files into the annex. Only known file contents will be reinjected. Any unknown src files will be left unchanged.

This can be useful if you have obtained the content of a file from elsewhere and want to put it in the local annex. For example, if a file's content has been lost and you have a backup, you can restore the backup and reinject it into your local repository.

There are two ways to use this command. Specifying a src file and the name of a dest file (located inside the repository's working tree) injects the src file as the content of the dest file.

    git annex reinject /tmp/foo.iso foo.iso

Or the `--known` option can be used to reinject all known src files, without needing to specify the dest file.

    git annex reinject --known /tmp/*.iso

# OPTIONS

- `--known`

  With this option, each specified src file is hashed using the default key-value backend (or the one specified with `--backend`), and if git-annex has a record of the resulting key having been in the annex before, the content is reinjected.

  Note that, when using a key-value backend that includes the filename extension in the key, this will only work if the src files have the same extensions as the files with the same content that was originally added to git-annex.

  Note that this will reinject old versions of files that have been modified or deleted from the current git branch. Use git-annex-unused(1) to detect when such old and potentially unused files have been reinjected.

- `--backend`

  Specify the key-value backend to use when checking if a file is known with the `--known` option.

- `--guesskeys`

  With this option, each specified source file is checked to see if it has the name of a git-annex key, and if so it is imported as the content of that key.

  This can be used to pluck git-annex objects out of `lost+found`, as long as the original filename has not been lost, and is particularly useful when using key-value backends that don't hash to the content of a file.

  When the key-value backend does support hashing, the content of the file is verified before importing it.

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

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

# SEE ALSO

git-annex(1)

git-annex-add(1)

git-annex-unused(1)

git-annex-fsck(1)

# AUTHOR

Joey Hess id@joeyh.name

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

comment 3
The difference of `git annex reinject` to (`git annex import` or `cp/mv; git annex add`) is that only known file contents will be reinjected.
Comment by Lukey — Tue Jul 22 18:11:47 2025
Difference to import/add?
Considering `git annex reinject /tmp/foo.iso foo.iso`, what is the difference to `git import`/tmp/foo.iso`or`cp /tmp/foo.iso; git annex add foo.iso`?
Comment by AlbertZeyer — Tue Jul 22 18:11:47 2025
Like it's written: annex only

# Summary

Just to make it explicit: `--known` mode operates on the annex only. If trying to reinject a file that is stored in the regular git part of the repository, and therefore practically known, `git-annex-reinject` will consider it not known.

# Context

I'm currently using `git-annex reinject --known` to tidy a pre-git-annex storage. It gets progressively near-emptied of big files, letting unknown files stand out in the deserted directory hierarchy.

Yet only actually annexed files will get removed.

In my case big files are pictures (NEF, JPG), and regular git files are `xmp` metadata files used by http://darktable.org/ to store processing parameters. So, all xmp files linger there, whether they were committed in git or not, needing separate handling.

# How to detect if a file is known to regular git repository (not annex).

There must be a number of ways. I just hacked one:

    HASH=$( git hash-object "$FILEPATH" )
    if $( git cat-file -e "$HASH" )
    then
            echo "Known $FILEPATH"
    else
            echo "Unknown $FILEPATH"
    fi

This can be wrapped into a helper function and used in a `find | ...` one-liner to remove any file already known to git.

## Caveats

`git cat-file` will probably consider known any file actually stored within git objects, even if on an deleted branch or whatever situations where it is not reachable. As a result, removing files based on this test may well lose information, not immediately, but on some subsequent `git gc`.

Such caveat is not surprising, as regular git content and annexed content have differing "scopes"/lifetime.

# Question

Joey, is there an alternative to `git-annex-reinject --known` that considers regular git content, too? Perhaps it's a pure git issue and therefore not something inside git-annex job?

A quick test of `git-annex-import --clean-duplicates` shows similar behavior.

Comment by https://launchpad.net/~stephane-gourichon-lpad — Tue Jul 22 18:11:47 2025
Comments on this page are closed.