docs: Fix various typos

docs/atomic-upgrades.md

@@ -30,14 +30,14 @@ the remote server.  Suppose we're tracking a ref named
 which contains a SHA256 checksum.  This determines the tree to deploy,
 and `/etc` will be merged from currently booted tree.
 
-If we do not have this commit, then, then we perform a pull process.
+If we do not have this commit, then we perform a pull process.
 At present (without static deltas), this involves quite simply just
 fetching each individual object that we do not have, asynchronously.
 Put in other words, we only download changed files (zlib-compressed).
 Each object has its checksum validated and is stored in `/ostree/repo/objects/`.
 
-Once the pull is complete, we have all the objects locally
-we need to perform a deployment.
+Once the pull is complete, we have downloaded all the objects that we need
+to perform a deployment.
 
 ## Upgrades via external tools (e.g. package managers)
 
@@ -50,7 +50,7 @@ locally, etc.
 
 At a practical level, most package managers today (`dpkg` and `rpm`)
 operate "live" on the currently booted filesystem.  The way they could
-work with OSTree is instead to take the list of installed packages in
+work with OSTree is to, instead, take the list of installed packages in
 the currently booted tree, and compute a new filesystem from that.  A
 later chapter describes in more details how this could work:
 [Adapting Existing Systems](adapting-existing.md).

docs/buildsystem-and-repos.md

@@ -21,10 +21,10 @@ primarily on server-side concerns.
 ## Build vs buy
 
 Therefore, you need to either pick an existing tool for writing
-content into an OSTree repository, or to write your own.  An example
-tool is [rpm-ostree](https://github.com/projectatomic/rpm-ostree) - it
-takes as input RPMs, and commits them (currently oriented for a server
-side, but aiming to do client side too).
+content into an OSTree repository, or write your own.  An example
+tool is [rpm-ostree](https://github.com/coreos/rpm-ostree) - it
+takes as input RPMs, and commits them (currently oriented for
+server-side, but aiming to do client-side too).
 
 ## Initializing
 

docs/deployment.md

@@ -26,7 +26,7 @@ at a time; each deployment is intended to be a target for
 Each deployment is grouped in exactly one "stateroot" (also known as an "osname");
 the former term is preferred.
 
-From above, you can see that an stateroot is physically represented in the
+From above, you can see that a stateroot is physically represented in the
 `/ostree/deploy/$stateroot` directory. For example, OSTree can allow parallel
 installing Debian in `/ostree/deploy/debian` and Red Hat Enterprise Linux in
 `/ostree/deploy/rhel` (subject to operating system support, present released

docs/formats.md

@@ -103,12 +103,11 @@ Since static deltas may not exist, the client first needs to attempt
 to locate one.  Suppose a client wants to retrieve commit `${new}`
 while currently running `${current}`.
 
-The first thing to understand is that in order to save space, these
-two commits are "modified base64" - the `/` character is replaced with
-`_`.
+In order to save space, these two commits are "modified base64" - the 
+`/` character is replaced with `_`.
 
 Like the commit objects, a "prefix directory" is used to make
-management easier for filesystem tools
+management easier for filesystem tools.
 
 A delta is named `$(mbase64 $from)-$(mbase64 $to)`, for example
 `GpTyZaVut2jXFPWnO4LJiKEdRTvOw_mFUCtIKW1NIX0-L8f+VVDkEBKNc1Ncd+mDUrSVR4EyybQGCkuKtkDnTwk`,

docs/repo.md

@@ -39,7 +39,7 @@ regenerate it from source code.
 A dirtree contains a sorted array of (filename, checksum)
 pairs for content objects, and a second sorted array of
 (filename, dirtree checksum, dirmeta checksum), which are
-subdirectories. These type of objects are stored as files
+subdirectories. This type of object is stored as files
 ending with `.dirtree` in the objects directory.
 
 ### Dirmeta objects
@@ -56,7 +56,7 @@ Unlike the first three object types which are metadata, designed to be
 `mmap()`ed, the content object has a separate internal header and
 payload sections.  The header contains uid, gid, mode, and symbolic
 link target (for symlinks), as well as extended attributes.  After the
-header, for regular files, the content follows. These parts toghether
+header, for regular files, the content follows. These parts together
 form the SHA256 hash for content objects. The content type objects in
 this format exist only in `archive` OSTree repositories. Today the
 content part is gzip'ed and the objects are stored as files ending
@@ -102,7 +102,7 @@ systems.
 The `bare-user-only` mode is a variant to the `bare-user` mode. Unlike
 `bare-user`, neither ownership nor extended attributes are stored. These repos
 are meant to to be checked out in user mode (with the `-U` flag), where this
-information is not applied anyway. Hence this mode may loose metadata.
+information is not applied anyway. Hence this mode may lose metadata.
 The main advantage of `bare-user-only` is that repos can be stored on
 filesystems which do not support extended attributes, such as tmpfs.
 

docs/repository-management.md

@@ -106,8 +106,7 @@ want to "promote" that commit.  Let's create a new branch called
 complete system.  This might be where human testers get involved, for
 example.
 
-A basic way to "promote" the `buildmaster` commit that passed
-testing like this:
+This is a basic way to "promote" the `buildmaster` commit that passed testing:
 
 ```
 ostree commit -b exampleos/x86_64/smoketested/standard -s 'Passed tests' --tree=ref=aec070645fe53...