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)
AUTHOR
Joey Hess id@joeyh.name
Warning: Automatically converted into a man page by mdwn2man. Edit with care.
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:
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 subsequentgit 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.git annex reinject /tmp/foo.iso foo.iso
, what is the difference togit import
/tmp/foo.isoor
cp /tmp/foo.iso; git annex add foo.iso`?git annex reinject
to (git annex import
orcp/mv; git annex add
) is that only known file contents will be reinjected.