ef3457196a
To get old behavior, add a .gitattributes containing: * annex.backend=WORM I feel that SHA256 is a better default for most people, as long as their systems are fast enough that checksumming their files isn't a problem. git-annex should default to preserving the integrity of data as well as git does. Checksum backends also work better with editing files via unlock/lock. I considered just using SHA1, but since that hash is believed to be somewhat near to being broken, and git-annex deals with large files which would be a perfect exploit medium, I decided to go to a SHA-2 hash. SHA512 is annoyingly long when displayed, and git-annex displays it in a few places (and notably it is shown in ls -l), so I picked the shorter hash. Considered SHA224 as it's even shorter, but feel it's a bit weird. I expect git-annex will use SHA-3 at some point in the future, but probably not soon! Note that systems without a sha256sum (or sha256) program will fall back to defaulting to SHA1. |
||
|---|---|---|
| .. | ||
| adding_a_remote | ||
| moving_file_content_between_repositories | ||
| removing_files | ||
| adding_a_remote.mdwn | ||
| adding_files.mdwn | ||
| automatically_managing_content.mdwn | ||
| backups.mdwn | ||
| creating_a_repository.mdwn | ||
| fsck:_verifying_your_data.mdwn | ||
| fsck:_when_things_go_wrong.mdwn | ||
| getting_file_content.mdwn | ||
| modifying_annexed_files.mdwn | ||
| more.mdwn | ||
| moving_file_content_between_repositories.mdwn | ||
| removing_files.mdwn | ||
| removing_files:_When_things_go_wrong.mdwn | ||
| renaming_files.mdwn | ||
| transferring_files:_When_things_go_wrong.mdwn | ||
| unused_data.mdwn | ||
| using_bup.mdwn | ||
| using_ssh_remotes.mdwn | ||