mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

docs

Browse source
This commit is contained in:
Joey Hess 2010-10-14 21:12:54 -04:00
parent 29039fdf97
commit 1ab3e54ca8
1 changed files with 17 additions and 17 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

34
git-annex.mdwn
View file

@ -13,7 +13,7 @@ associated with annexed files but that benefit from full revision control.
Enough broad picture, here's how it actually looks: Enough broad picture, here's how it actually looks:
* `git annex --add $file` moves the file into `.git/annex/`, and replaces * `git annex add $file` moves the file into `.git/annex/`, and replaces
it with a symlink pointing at the annexed file, and then calls `git add` it with a symlink pointing at the annexed file, and then calls `git add`
to version the *symlink*. (If the file has already been annexed, it does to version the *symlink*. (If the file has already been annexed, it does
nothing.) nothing.)
@ -24,23 +24,23 @@ Enough broad picture, here's how it actually looks:
* If you use normal git push/pull commands, the annexed file contents * If you use normal git push/pull commands, the annexed file contents
won't be sent, but the symlinks will be. So different clones of a repository won't be sent, but the symlinks will be. So different clones of a repository
can have different sets of annexed files available. can have different sets of annexed files available.
* `git annex --push $repository` pushes *all* annexed files to the specified * `git annex push $repository` pushes *all* annexed files to the specified
repository. repository.
* `git annex --pull $repository` pulls *all* annexed files from the specified * `git annex pull $repository` pulls *all* annexed files from the specified
repository. repository.
* `git annex --want $file` indicates that you want access to a file's * `git annex want $file` indicates that you want access to a file's
content, without immediatly transferring it. content, without immediatly transferring it.
* `git annex --get $file` is used to transfer a specified file, and/or * `git annex get $file` is used to transfer a specified file, and/or
files previously indicated with --want. If a configured repository has it, files previously indicated with `git annex want`. If a configured repository has it,
or it is available from other key/value storage, it will be immediatly or it is available from other key/value storage, it will be immediatly
downloaded. downloaded.
* `git annex --drop $file` indicates that you no longer want the file's * `git annex drop $file` indicates that you no longer want the file's
content to be available in this repository. content to be available in this repository.
* `git annex --unannex $file` undoes a `git annex --add`. But use `--drop` * `git annex unannex $file` undoes a `git annex add`. But use `git annex drop`
if you're just done with a file; only use `--unannex` if you if you're just done with a file; only use `unannex` if you
accidentially added a file. accidentially added a file.
* `git annex $file` is a shorthand for either --add or --get. If the file * `git annex $file` is a shorthand. If the file
is already known, it does --get, otherwise it does --add. is already known, it does `git annex get`, otherwise it does `git annex add`.
## copies ## copies
@ -48,17 +48,17 @@ git-annex can be configured to try to keep N copies of a file's content
available across all repositories. By default, N is 1 (configured by available across all repositories. By default, N is 1 (configured by
annex.numcopies). annex.numcopies).
`git annex --drop` attempts to check all other configured `git annex drop` attempts to check all other configured
repositories, to check that N copies of the file exist. If enough repositories, to check that N copies of the file exist. If enough
repositories cannot be verified to have it, it will retain the file content repositories cannot be verified to have it, it will retain the file content
to avoid data loss. to avoid data loss.
For example, consider three repositories: Server, Laptop, and USB. Both Server For example, consider three repositories: Server, Laptop, and USB. Both Server
and USB have a copy of a file, and N=1. If on Laptop, you `git annex --get and USB have a copy of a file, and N=1. If on Laptop, you `git annex get
$file`, this will transfer it from either Server or USB (depending on which $file`, this will transfer it from either Server or USB (depending on which
is available), and there are now 3 copies of the file. is available), and there are now 3 copies of the file.
Suppose you want to free up space on laptop again, and you --drop the file Suppose you want to free up space on laptop again, and you `git annex drop` the file
there. If USB is connected, or Server can be contacted, git-annex can check there. If USB is connected, or Server can be contacted, git-annex can check
that it still has a copy of the file, and the content is removed from that it still has a copy of the file, and the content is removed from
Laptop. But if USB is currently disconnected, and Server also cannot be Laptop. But if USB is currently disconnected, and Server also cannot be
@ -108,11 +108,11 @@ to store different files' contents in a given repository.
git-annex keeps track of on which repository it last saw a file's content. git-annex keeps track of on which repository it last saw a file's content.
This can be useful when using it for archiving with offline storage. When This can be useful when using it for archiving with offline storage. When
you indicate you --want a file, git-annex will tell you which repositories you indicate you want a file, git-annex will tell you which repositories
have the file's content. have the file's content.
Location tracking information is stored in `.git-annex/$key.log`. Location tracking information is stored in `.git-annex/$key.log`.
Repositories record their UUID and the date when they --get or --drop Repositories record their UUID and the date when they get or drop
a file's content. (Git is configured to use a union merge for this file, a file's content. (Git is configured to use a union merge for this file,
so the lines may be in arbitrary order, but it will never conflict.) so the lines may be in arbitrary order, but it will never conflict.)
@ -150,7 +150,7 @@ If the symlink to annexed content is relative, moving it to a subdir will
break it. But it it's absolute, moving the git repo (or mounting its drive break it. But it it's absolute, moving the git repo (or mounting its drive
elsewhere) will break it. Either: elsewhere) will break it. Either:
* Use relative links and need `git annex --mv` to move (or post-commit * Use relative links and need `git annex mv` to move (or post-commit
hook that caches moves and updates links). hook that caches moves and updates links).
* Use absolute links and need `git annex fixlinks` when location changes; * Use absolute links and need `git annex fixlinks` when location changes;
note that would also mean that git would see the symlink targets changed note that would also mean that git would see the symlink targets changed