git-annex/doc/walkthrough/adding_files.mdwn

	# cd ~/annex
	# cp /tmp/big_file .
	# cp /tmp/debian.iso .
	# git annex add .
	add big_file (checksum...) ok
	add debian.iso (checksum...) ok
	# git commit -a -m added

When you add a file to the annex and commit it, only a symlink to
the annexed content is committed. The content itself is stored in
git-annex's backend.
split the walkthrough and inline back together 2011-02-27 16:45:48 +00:00			`# cd ~/annex`
			`# cp /tmp/big_file .`
			`# cp /tmp/debian.iso .`
			`# git annex add .`
use SHA256 by default 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. 2011-11-04 19:21:45 +00:00			`add big_file (checksum...) ok`
			`add debian.iso (checksum...) ok`
split the walkthrough and inline back together 2011-02-27 16:45:48 +00:00			`# git commit -a -m added`

			`When you add a file to the annex and commit it, only a symlink to`
			`the annexed content is committed. The content itself is stored in`
			`git-annex's backend.`