Various typo fixes in doc/*.mdwn
This commit is contained in:
parent
334a9f5738
commit
490e97ec10
8 changed files with 9 additions and 9 deletions
|
@ -39,7 +39,7 @@ terminal. A fairly full set of tools is provided, including `git`, `ssh`,
|
|||
`rsync`, and `gpg`.
|
||||
|
||||
To prevent the webapp from being automatically started
|
||||
when a terminal window opens, go into the terminal preferences, to "Inital
|
||||
when a terminal window opens, go into the terminal preferences, to "Initial
|
||||
Command", and clear out the default `git annex webapp` setting.
|
||||
|
||||
Or, if you'd like to run the assistant automatically, but not open the
|
||||
|
|
|
@ -17,7 +17,7 @@ you don't want.
|
|||
|
||||
The "AAA" and "BBB" in the above example are essentially arbitrary
|
||||
(technically they are the MD5 checksum of the key). The automatic merge
|
||||
conflict resoltuion is designed so that if two or more repositories both get
|
||||
conflict resolution is designed so that if two or more repositories both get
|
||||
a merge conflict, and resolve it, the resolved repositories will not
|
||||
themselves conflict. This is why it doesn't use something nicer, like
|
||||
perhaps the name of the remote that the file came from.
|
||||
|
|
|
@ -13,7 +13,7 @@ To enable chunking, pass a `chunk=nnMiB` parameter to `git annex
|
|||
initremote`, specifying the chunk size.
|
||||
|
||||
Good chunk sizes will depend on the remote, but a good starting place
|
||||
is probably `1MiB`. Very large chunks are problimatic, both because
|
||||
is probably `1MiB`. Very large chunks are problematic, both because
|
||||
git-annex needs to buffer one chunk in memory when uploading, and because
|
||||
a larger chunk will make resuming interrupted transfers less efficient.
|
||||
On the other hand, when a file is split into a great many chunks,
|
||||
|
|
|
@ -18,11 +18,11 @@ AES encryption:
|
|||
use SPEKE (or similar methods like J-PAKE) to generate a shared key.
|
||||
Avoids active MITM attacks. Makes pairing harder, especially pairing
|
||||
between one's own devices, since the passphrase has to be entered on
|
||||
all devices. Also problimatic when pairing more than 2 devices,
|
||||
all devices. Also problematic when pairing more than 2 devices,
|
||||
especially when adding a device to the set later, since there
|
||||
would then be multiple different keys in use.
|
||||
* Rely on the user's gpg key, and do gpg key verification during XMPP
|
||||
pairing. Problimatic because who wants to put their gpg key on their
|
||||
pairing. Problematic because who wants to put their gpg key on their
|
||||
phone? Also, require the users be in the WOT and be gpg literate.
|
||||
|
||||
Update: This seems unlikely to be worth doing. [[Telehash]] is better.
|
||||
|
|
|
@ -26,7 +26,7 @@ For more details about the git-annex assistant, see
|
|||
* `--startdelay=N`
|
||||
|
||||
Wait N seconds before running the startup scan. This process can
|
||||
be expensive and you may not want to run it immediatly upon login.
|
||||
be expensive and you may not want to run it immediately upon login.
|
||||
|
||||
* `--foreground`
|
||||
|
||||
|
|
|
@ -15,7 +15,7 @@ No verification is performed of the url's contents.
|
|||
|
||||
If the key and url are not specified on the command line, they are
|
||||
instead read from stdin. Any number of lines can be provided in this
|
||||
mode, each containing a key and url, sepearated by whitespace.
|
||||
mode, each containing a key and url, separated by whitespace.
|
||||
|
||||
# SEE ALSO
|
||||
|
||||
|
|
|
@ -1,6 +1,6 @@
|
|||
# NAME
|
||||
|
||||
git-annex unannex - undo accidential add command
|
||||
git-annex unannex - undo accidental add command
|
||||
|
||||
# SYNOPSIS
|
||||
|
||||
|
|
|
@ -172,7 +172,7 @@ subdirectories).
|
|||
|
||||
* `assistant`
|
||||
|
||||
Atomatically sync folders between devices.
|
||||
Automatically sync folders between devices.
|
||||
|
||||
See [[git-annex-assistant]](1) for details.
|
||||
|
||||
|
|
Loading…
Reference in a new issue