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

minor typos/trailing spaces fixes in git-annex.mdwn

Browse source
This commit is contained in:
Yaroslav Halchenko 2013-12-04 01:10:18 -05:00 committed by Joey Hess
parent 71faabe278
commit 9639142df9
1 changed files with 26 additions and 26 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

26
doc/git-annex.mdwn
View file

@ -135,7 +135,7 @@ subdirectories).
* `sync [remote ...]`
Use this command when you want to synchronize the local repository with
one or more of its remotes. You can specifiy the remotes to sync with;
one or more of its remotes. You can specify the remotes to sync with;
the default is to sync with all remotes. Or specify `--fast` to sync with
the remotes with the lowest annex-cost value.
@ -302,7 +302,7 @@ subdirectories).
* `init [description]`
Until a repository (or one of its remotes) has been initialized,
git-annex will refuse to operate on it, to avoid accidentially
git-annex will refuse to operate on it, to avoid accidentally
using it in a repository that was not intended to have an annex.
It's useful, but not mandatory, to initialize each new clone
@ -327,22 +327,22 @@ subdirectories).
All special remotes support encryption. You can either specify
`encryption=none` to disable encryption, or specify
`encryption=hybrid keyid=$keyid ...` to specify a gpg key id (or an email
`encryption=hybrid keyid=$keyid ...` to specify a GPG key id (or an email
address associated with a key.)
There are actually three schemes that can be used for management of the
encryption keys. When using the encryption=hybrid scheme, additional
gpg keys can be given access to the encrypted special remote easily
GPG keys can be given access to the encrypted special remote easily
(without re-encrypting everything). When using encryption=shared,
a shared key is generated and stored in the git repository, allowing
anyone who can clone the git repository to access it. Finally, when using
encryption=pubkey, content in the special remote is directly encrypted
to the specified gpg keys, and additional ones cannot easily be given
to the specified GPG keys, and additional ones cannot easily be given
access.
Note that with encryption enabled, a cryptographic key is created.
This requires sufficient entropy. If initremote seems to hang or take
a long time while generating the key, you may want to ctrl-c it and
a long time while generating the key, you may want to Ctrl-c it and
re-run with `--fast`, which causes it to use a lower-quality source of
randomness.
@ -369,7 +369,7 @@ subdirectories).
the as the encryption scheme cannot be changed once a special remote
has been created.)
The gpg keys that an encrypted special remote is encrypted to can be
The GPG keys that an encrypted special remote is encrypted to can be
changed using the keyid+= and keyid-= parameters. These respectively
add and remove keys from the list. However, note that removing a key
does NOT necessarily prevent the key's owner from accessing data
@ -546,7 +546,7 @@ subdirectories).
When this rewritten branch is merged into other clones of
the repository, `git-annex` will automatically perform the same rewriting
to their local `git-annex` branches. So the forgetfulness will automatically
propigate out from its starting point until all repositories running
propagate out from its starting point until all repositories running
git-annex have forgotten their old history. (You may need to force
git to push the branch to any git repositories not running git-annex.)
@ -554,7 +554,7 @@ subdirectories).
This can repair many of the problems with git repositories that `git fsck`
detects, but does not itself fix. It's useful if a repository has become
badly damaged. One way this can happen is if a repisitory used by git-annex
badly damaged. One way this can happen is if a repository used by git-annex
is on a removable drive that gets unplugged at the wrong time.
This command can actually be used inside git repositories that do not
@ -562,7 +562,7 @@ subdirectories).
does additional repairs of the git-annex branch.
It works by deleting any corrupt objects from the git repository, and
retriving all missing objects it can from the remotes of the repository.
retrieving all missing objects it can from the remotes of the repository.
If that is not sufficient to fully recover the repository, it can also
reset branches back to commits before the corruption happened, delete
@ -616,7 +616,7 @@ subdirectories).
Displays the location log for the specified file or files,
showing each repository they were added to ("+") and removed from ("-").
To limit how far back to seach for location log changes, the options
To limit how far back to search for location log changes, the options
`--since`, `--after`, `--until`, `--before`, and `--max-count` can be specified.
They are passed through to git log. For example, `--since "1 month ago"`
@ -1032,7 +1032,7 @@ no equivilant to `--in`.
When a repository is in one of the standard predefined groups, like "backup"
and "client", setting its preferred content to "standard" will use a
built-in preferred content expression ddeveloped for that group.
built-in preferred content expression developed for that group.
# SCHEDULED JOBS
@ -1160,7 +1160,7 @@ Here are all the supported configuration settings.
Note that upgrade checking is only done when git-annex is installed
from one of the prebuilt images from its website. This does not
bypass eg, a Linux distribution's own upgrade handling code.
bypass e.g., a Linux distribution's own upgrade handling code.
This setting also controls whether to restart the git-annex assistant
when the git-annex binary is detected to have changed. That is useful