README: fix some typos and formatting

Signed-off-by: Wei Liu <wl@xen.org>

diff --git a/README.md b/README.md
index 36bf702e7880aa7a415e6aba60f8c084c03eb36d..b056741cfe6fed2b443caab9104a8f6c99f4431d 100644 (file)
--- a/README.md
+++ b/README.md
@@ -14,7 +14,7 @@ See the **Workflow** section for a quick usage guide.
 # Design
 
 Our current standard practice is to provide a patch or series (or
-multiple patches or series), such `master`, as well as all currently
+multiple patches or series), such as `master`, as well as all currently
 supported versions under security support, will have fixes which apply
 via `git am`.
 
@@ -30,9 +30,9 @@ However, these patches:
 
 This tool introduces the concept of a *recipe*.  Each supported
 release will have its own recipe.  The recipe will include the
-specific tree it's targetet at, the *baseline* in `stable-${v}` on
+specific tree it's targeted at, the *baseline* in `stable-${v}` on
 which it's applied, as well as any XSA prerequisites.  The recipe
-would ideally be both machine- and human-readiable, and live in
+would ideally be both machine- and human-readable, and live in
 `xsa.git`.
 
 Which in turns leads us to the next thing: rather than having to
@@ -57,7 +57,7 @@ is reasonably close to being ready.
 The actual creation and manipulation of the patches will be highly
 context-dependent and developer-driven; to that end the standard will
 be to create branches with a specific naming scheme in the various
-trees, which developers can then manipuate.  xsatool will have
+trees, which developers can then manipulate.  xsatool will have
 commands to 'sync' between the trees.
 
 # Data files
@@ -111,13 +111,13 @@ effects on the tree:
 
 - Modify the working tree (including `git clean -ffdx`)
 
-- Discard uncommited changes (e.g., `checkout -f`)
+- Discard uncommitted changes (e.g., `checkout -f`)
 
 - Modify `HEAD`
 
 - Create, delete, or modify branches matching `xsa/*`
 
-- "Fetch" from master and stable-* branches
+- "Fetch" from master and stable-\* branches
 
 ## Branch names
 
@@ -192,7 +192,7 @@ cache used for git clones *during build*.
 `xsatool global update`
 
 If this is run and `xsa.git/global.meta` doesn't exist, it will create
-the file.  It firsts asks what the oldest supported Xen version is.
+the file.  It first asks what the oldest supported Xen version is.
 It then goes through `xen.git` and looks for `RELEASE-M.m.p` tags, and
 marks each version greater than or equal to the specified version as
 supported.
@@ -203,7 +203,7 @@ supported.
 
 Using XSA 213 as an example.
 
-Make sure your staging and staging-* branches are up to date:
+Make sure your staging and staging-\* branches are up to date:
 
 `xsatool repo update`
 
@@ -338,7 +338,7 @@ equivalent to those in the next higher version:
    recipe for version `${v}+1`.  If the `git am` fails, the current
    patches are not redundant and move on to the next version.
 
- - Compare a hash of the two trees (generated with `git rev-partse
+ - Compare a hash of the two trees (generated with `git rev-parse
    $branch:`).  If they match, replace the recipe `${v}` with the
    recipe for `${v}+1`.  Otherwise, leave it as it is.
 
@@ -348,7 +348,7 @@ NB at the moment this only works for the xen repo.
 
 For example, if the patches were made by a colleague.
 
-Make sure your master and stable-* branches are up to date:
+Make sure your master and stable-\* branches are up to date:
 
 `xsatool repo update`
 
@@ -474,7 +474,7 @@ doing a rebase), failing out in case of an error. If no
 ## Marking XSAs as published
 
 To mark an XSA as published (i.e., to remove XSAs from the list of
-"default prerequisites" for new XSAs), edit `global.meta` and
+"default prerequisites" for new XSAs), edit `global.meta`.
 
 ## Adding a new Xen release to support
 
@@ -497,7 +497,7 @@ end-support <version>` command.)
 ## 'Canonicalizing' metadata files
 
 After editing metadata files by hand or with other JSON-parsing tools,
-the order of fields may be signicantly different.  You can run
+the order of fields may be significantly different.  You can run
 
 `xsatool NNN canonicalize`
 
@@ -505,7 +505,7 @@ to reformat a file according to Golang's default format.  This will:
   - Sort maps according to lexographical order (golang canon)
   - Sort elements that correspond do structures according to structure order
        (golang canon)
-  - Sort versions in SupportedVersions in decending order (xsatool canon).
+  - Sort versions in SupportedVersions in descending order (xsatool canon).
   - Remove unknown or obsolete elements.  NB this includes the "XenVersion"
     element in older recipes.
 
@@ -579,7 +579,7 @@ For example, if we had the functionality to check if a patch is appled:
 
 # Open issues
 
-# Inter-tree dependcies
+# Inter-tree dependencies
 
 Do we need to worry about inter-tree dependencies?  For example, could
 it ever be the case that xsa 251, for xen.git, depends on xsa250,