2010-10-19 19:59:40 +00:00
|
|
|
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).
|
|
|
|
|
2011-08-28 20:28:38 +00:00
|
|
|
Multiple pluggable key-value backends are supported, and a single repository
|
|
|
|
can use different ones for different files.
|
2011-03-28 02:52:13 +00:00
|
|
|
|
2014-07-16 17:31:01 +00:00
|
|
|
* `SHA256E` -- The default backend for new files, combines a 256 bit SHA-2
|
|
|
|
hash of the file's content with the file's extension. This allows
|
2011-08-29 16:08:54 +00:00
|
|
|
verifying that the file content is right, and can avoid duplicates of
|
|
|
|
files with the same content. Its need to generate checksums
|
2011-11-04 19:21:45 +00:00
|
|
|
can make it slower for large files.
|
2015-08-06 19:02:25 +00:00
|
|
|
* `SHA256` -- SHA-2 hash that does not include the file extension in the
|
|
|
|
key, which can lead to better deduplication but can confuse some programs.
|
2014-07-16 17:31:01 +00:00
|
|
|
* `SHA512`, `SHA512E` -- Best SHA-2 hash, for the very paranoid.
|
2015-08-06 19:02:25 +00:00
|
|
|
* `SHA384`, `SHA384E`, `SHA224`, `SHA224E` -- SHA-2 hashes for
|
|
|
|
people who like unusual sizes.
|
2015-08-13 02:19:11 +00:00
|
|
|
* `SHA3_512`, `SHA3_512E`, `SHA3_384`, `SHA3_384E`, `SHA3_256`, `SHA3_256E`, `SHA3_224`, `SHA3_224E`
|
2015-08-06 19:02:25 +00:00
|
|
|
-- SHA-3 hashes, for bleeding edge fun.
|
2014-07-16 17:31:01 +00:00
|
|
|
* `SKEIN512`, `SKEIN512E`, `SKEIN256`, `SKEIN256E`
|
|
|
|
-- [Skein hash](http://en.wikipedia.org/wiki/Skein_hash),
|
2013-10-02 00:34:06 +00:00
|
|
|
a well-regarded SHA3 hash competition finalist.
|
2015-08-06 19:02:25 +00:00
|
|
|
* `SHA1`, `SHA1E`, `MD5`, `MD5E` -- Smaller hashes than `SHA256`
|
|
|
|
for those who want a checksum but are not concerned about security.
|
|
|
|
* `WORM` ("Write Once, Read Many") -- This assumes that any file with
|
|
|
|
the same filename, size, and modification time has the same content.
|
|
|
|
This is the least expensive backend, recommended for really large
|
|
|
|
files or slow systems.
|
|
|
|
* `URL` -- This is a key that is generated from the url to a file.
|
|
|
|
It's generated when using eg, `git annex addurl --fast`, when the file
|
|
|
|
content is not available for hashing.
|
2011-03-28 02:52:13 +00:00
|
|
|
|
2015-08-06 19:02:25 +00:00
|
|
|
Note that the various 512 and 384 length hashes result in long paths,
|
2015-01-07 02:33:57 +00:00
|
|
|
which are known to not work on Windows. If interoperability on Windows is a
|
2015-08-06 19:02:25 +00:00
|
|
|
concern, avoid those.
|
2015-01-07 02:33:57 +00:00
|
|
|
|
2010-11-01 23:11:06 +00:00
|
|
|
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
|
2010-11-28 22:58:03 +00:00
|
|
|
files, the `.gitattributes` file can be used. The `annex.backend`
|
2010-11-01 23:11:06 +00:00
|
|
|
attribute can be set to the name of the backend to use for matching files.
|
|
|
|
|
2012-09-12 17:22:16 +00:00
|
|
|
For example, to use the SHA256E backend for sound files, which tend to be
|
2011-11-04 19:21:45 +00:00
|
|
|
smallish and might be modified or copied over time,
|
|
|
|
while using the WORM backend for everything else, you could set
|
|
|
|
in `.gitattributes`:
|
2010-11-01 23:11:06 +00:00
|
|
|
|
2011-11-04 19:21:45 +00:00
|
|
|
* annex.backend=WORM
|
2012-09-12 17:22:16 +00:00
|
|
|
*.mp3 annex.backend=SHA256E
|
|
|
|
*.ogg annex.backend=SHA256E
|