git-annex-gpl - git-annex without the AGPL

	Commit message (Collapse)	Author	Age
*	link to the centralized_git_repository_tutorial	Joey Hess	2015-08-05
\|
*	add new walkthrough chapter on using special remotes	Joey Hess	2015-01-20
\|
*	typo	http://brohaveyouseenmysocks.wordpress.com/	2013-07-21
\|
*	use SHA256 by default	Joey Hess	2011-11-04
\| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \|	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.
*	get --from is the same as copy --from	Joey Hess	2011-06-09
\| \| \| \| \| \| \| \|	get not honoring --from has surprised me a few times, so least surprise suggests it should just behave like copy --from. This leaves the difference between get and copy being that copy always requires the remote to copy from, while get will decide whether to get a file from a key/value store or a remote.
*	initial pass at doc update	Joey Hess	2011-03-15
\|
*	be more clear about the rsync usage	http://m-f-k.myopenid.com/	2011-03-06
\|
*	split the walkthrough and inline back together	Joey Hess	2011-02-27