37 lines
1.7 KiB
Markdown
37 lines
1.7 KiB
Markdown
git-annex uses a key-value abstraction layer to allow file contents to be
|
|
stored in different ways. In theory, any key-value storage system could be
|
|
used to store file contents.
|
|
|
|
When a file is annexed, a key is generated from its content and/or metadata.
|
|
The file checked into git symlinks to the key. This key can later be used
|
|
to retrieve the file's content (its value).
|
|
|
|
Multiple pluggable backends are supported, and a single repository
|
|
can use different backends for different files.
|
|
|
|
* `WORM` ("Write Once, Read Many") This backend stores the file's content
|
|
only in `.git/annex/objects/`, and assumes that any file with the same
|
|
basename, size, and modification time has the same content. So with
|
|
this backend, files can be moved around, but should never be added to
|
|
or changed. This is the default, and the least expensive backend.
|
|
* `SHA1` -- This backend stores the file's content in
|
|
`.git/annex/objects/`, with a name based on its sha1 checksum. This backend
|
|
allows modifications of files to be tracked. Its need to generate checksums
|
|
can make it slower for large files.
|
|
for use.
|
|
* `URL` -- This backend downloads the file's content from an external URL.
|
|
|
|
The `annex.backends` git-config setting can be used to list the backends
|
|
git-annex should use. The first one listed will be used by default when
|
|
new files are added.
|
|
|
|
For finer control of what backend is used when adding different types of
|
|
files, the `.gitattributes` file can be used. The `annex.backend`
|
|
attribute can be set to the name of the backend to use for matching files.
|
|
|
|
For example, to use the SHA1 backend for sound files, which tend to be
|
|
smallish and might be modified over time, you could set in
|
|
`.gitattributes`:
|
|
|
|
*.mp3 annex.backend=SHA1
|
|
*.ogg annex.backend=SHA1
|