git-annex/doc/walkthrough/moving_file_content_between_repositories.mdwn

Often you will want to move some file contents from a repository to some
other one. For example, your laptop's disk is getting full; time to move
some files to an external disk before moving another file from a file
server to your laptop. Doing that by hand (by using `git annex get` and
`git annex drop`) is possible, but a bit of a pain. `git annex move`
makes it very easy.

	$ git annex move my_cool_big_file --to usbdrive
	move my_cool_big_file (to usbdrive...) ok
	$ git annex move video/hackity_hack_and_kaxxt.mov --from fileserver
	move video/hackity_hack_and_kaxxt.mov (from fileserver...)
	SHA256-s86050597--6ae2688bc533437766a48aa19f2c06be14d1bab9c70b468af445d4f07b65f41e   100%   82MB 199.1KB/s   07:02
	ok
split the walkthrough and inline back together 2011-02-27 16:45:48 +00:00			`Often you will want to move some file contents from a repository to some`
			`other one. For example, your laptop's disk is getting full; time to move`
			`some files to an external disk before moving another file from a file`
			server to your laptop. Doing that by hand (by using `git annex get` and
			`git annex drop`) is possible, but a bit of a pain. `git annex move`
			`makes it very easy.`

this is not all run as root 2019-03-27 15:15:03 +00:00			`$ git annex move my_cool_big_file --to usbdrive`
document S3 remotes 2011-03-28 02:52:13 +00:00			`move my_cool_big_file (to usbdrive...) ok`
this is not all run as root 2019-03-27 15:15:03 +00:00			`$ git annex move video/hackity_hack_and_kaxxt.mov --from fileserver`
document S3 remotes 2011-03-28 02:52:13 +00:00			`move video/hackity_hack_and_kaxxt.mov (from fileserver...)`
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			`SHA256-s86050597--6ae2688bc533437766a48aa19f2c06be14d1bab9c70b468af445d4f07b65f41e 100% 82MB 199.1KB/s 07:02`
split the walkthrough and inline back together 2011-02-27 16:45:48 +00:00			`ok`