docs: Fix various typos

diff --git a/docs/atomic-upgrades.md b/docs/atomic-upgrades.md
index 3ddd8b40cf950d4dd5c41c01294414e8c97edb07..f4b31acaa292bdcb1a5aba19ef077f1d28ab7763 100644 (file)
--- a/docs/atomic-upgrades.md
+++ b/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).

diff --git a/docs/buildsystem-and-repos.md b/docs/buildsystem-and-repos.md
index 6d506b4eb4c8a890cc4b78d43db01380a39c2ce7..e265ee7a034bdba94a498a4e239444bba7f45e02 100644 (file)
--- a/docs/buildsystem-and-repos.md
+++ b/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
 

diff --git a/docs/deployment.md b/docs/deployment.md
index 1ea7ea4602841f73981691b798edf303fba416bf..30323f8cc8c456beb90823d1f0ebf6e17d5f5745 100644 (file)
--- a/docs/deployment.md
+++ b/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

diff --git a/docs/formats.md b/docs/formats.md
index 36d395bda10a3a01539883028925e768be8b6a5c..0943aafa6c90adb7b52147bbc0b0605acc9ef2d7 100644 (file)
--- a/docs/formats.md
+++ b/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`,

diff --git a/docs/repo.md b/docs/repo.md
index 5cc59bf1f002dee85ecfb36dd168f24450e5fa8c..9b254b12921a3c4deb817b8bc26b3263937f8a96 100644 (file)
--- a/docs/repo.md
+++ b/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.
 

diff --git a/docs/repository-management.md b/docs/repository-management.md
index 11fe2f40de823445ef442e9f050ff4362dd0360b..41b8d2b1530f9f29501c8c4743bb3e1572b68170 100644 (file)
--- a/docs/repository-management.md
+++ b/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...