Fix typos in Patcher docs

_docs-sources/patcher/running-patcher/update.md

@@ -57,7 +57,7 @@ Some modules including third party modules may not have a CHANGELOGS.md file. In
 
 In non-interactive mode, Patcher updates all module dependencies in the current folder (and child folders) according to the specified update strategy.
 
-Non-interactive mode supports both the `next-safe` and `next-breaking` update strategies. 
+Non-interactive mode supports both the `next-safe` and `next-breaking` update strategies.
 
 ### Next Safe (Default)
 
@@ -89,7 +89,7 @@ Beginning with version `0.3.3`, Patcher provides limited support for updating th
 
 Third party modules are supported in both interactive mode and non-interactive mode.
 
-For example, the [terraform-aws-modules/terraform-aws-vpc](https://github.com/terraform-aws-modules/terraform-aws-vpc) module has two recent change: `4.0.2` and `5.0.0`.
+For example, the [terraform-aws-modules/terraform-aws-vpc](https://github.com/terraform-aws-modules/terraform-aws-vpc) module has two recent changes: `4.0.2` and `5.0.0`.
 
 And in `infrastructure-live/prod` there is a dependency on `terraform-aws-vpc/vpc`:
 - `prod/us-east-1/prod/vpc/terragrunt.hcl` currently uses `4.0.0`

_docs-sources/patcher/update-strategies.md

@@ -1,6 +1,6 @@
 # Update Strategies
 
-Patcher supports two update strategies: **next safe** and **next breaking**. Theses update strategy determines how Patcher will behave if it encounters a breaking change that it cannot patch.
+Patcher supports two update strategies: **next safe** and **next breaking**. These update strategies determine how Patcher will behave if it encounters a breaking change that it cannot patch.
 
 For example, the Gruntwork `terraform-aws-security/custom-iam-entity` module has two recent breaking changes: `0.62.0` and `0.65.0`.
 
@@ -12,7 +12,7 @@ And in `infrastructure-live/dev` there are 2 dependencies on `terraform-aws-secu
 
 The **next safe** strategy will update a dependency to either the highest version **before the next closest breaking change** or the latest version of the dependency, whichever is encountered first.
 
-So if Patcher encounters a breaking change that it cannot patch then it will update the dependencies to the highest version before that breaking change and stop. Otherwise, if no breaking chnages are encountered it will update the dependencies the latest version of that module.
+So if Patcher encounters a breaking change that it cannot patch then it will update the dependencies to the highest version before that breaking change and stop. Otherwise, if no breaking changes are encountered it will update the dependencies the latest version of that module.
 
 For example, for the dependencies on `terraform-aws-security/custom-iam-entity` in `infrastructure-live/dev`:
 - `_global/ops-admin-role/terragrunt.hcl` will be updated from `0.65.6` to `0.68.2`, the latest version
@@ -45,7 +45,7 @@ This is an example of the YAML that Patcher writes to `stdout` describing these
 
 The **next breaking** strategy will update a dependency to either the next closest breaking change or the latest version of the dependency, whichever is encountered first.
 
-So if Patcher encounters a breaking change that it cannot patch then it will update the dependencies to the version with the breaking change and stop. Otherwise, if no breaking changes are encountered it will update the dependencies the latest version of that module.
+So if Patcher encounters a breaking change that it cannot patch then it will update the dependencies to the version with the breaking change and stop. Otherwise, if no breaking changes are encountered, it will update the dependencies to the latest version of that module.
 
 This may result in an update that requires manual intervention. If so, Patcher will provide additional information to help you understand what needs to be done.
 
@@ -94,4 +94,4 @@ Here are the release notes for version v0.62.0:
   - From this release onward, we will only be running tests with Terraform `1.1.x` against this repo, so we recommend updating to `1.1.x` soon!
   - We have also updated the minimum required version of Terraform to `1.0.0`. While our repos might continue to be compatible with pre-1.0.0 version of Terraform, we are no longer making any guarantees of that.
   - Once all Gruntwork repos have been upgraded to work with `1.1.x`, we will publish a migration guide with a version compatibility table and announce it all via the Gruntwork Newsletter.
-```
+```

docs/patcher/running-patcher/update.md

@@ -57,7 +57,7 @@ Some modules including third party modules may not have a CHANGELOGS.md file. In
 
 In non-interactive mode, Patcher updates all module dependencies in the current folder (and child folders) according to the specified update strategy.
 
-Non-interactive mode supports both the `next-safe` and `next-breaking` update strategies. 
+Non-interactive mode supports both the `next-safe` and `next-breaking` update strategies.
 
 ### Next Safe (Default)
 
@@ -89,7 +89,7 @@ Beginning with version `0.3.3`, Patcher provides limited support for updating th
 
 Third party modules are supported in both interactive mode and non-interactive mode.
 
-For example, the [terraform-aws-modules/terraform-aws-vpc](https://github.com/terraform-aws-modules/terraform-aws-vpc) module has two recent change: `4.0.2` and `5.0.0`.
+For example, the [terraform-aws-modules/terraform-aws-vpc](https://github.com/terraform-aws-modules/terraform-aws-vpc) module has two recent changes: `4.0.2` and `5.0.0`.
 
 And in `infrastructure-live/prod` there is a dependency on `terraform-aws-vpc/vpc`:
 - `prod/us-east-1/prod/vpc/terragrunt.hcl` currently uses `4.0.0`
@@ -106,6 +106,6 @@ Patcher cannot update from `4.0.x` to `5.0.0` and will instead show a `?` in the
 <!-- ##DOCS-SOURCER-START
 {
   "sourcePlugin": "local-copier",
-  "hash": "ef694de362e2022b29aeb7702efa81a1"
+  "hash": "a1a5840931017bfaf95f069bafd070de"
 }
 ##DOCS-SOURCER-END -->

docs/patcher/update-strategies.md

@@ -1,6 +1,6 @@
 # Update Strategies
 
-Patcher supports two update strategies: **next safe** and **next breaking**. Theses update strategy determines how Patcher will behave if it encounters a breaking change that it cannot patch.
+Patcher supports two update strategies: **next safe** and **next breaking**. These update strategies determine how Patcher will behave if it encounters a breaking change that it cannot patch.
 
 For example, the Gruntwork `terraform-aws-security/custom-iam-entity` module has two recent breaking changes: `0.62.0` and `0.65.0`.
 
@@ -12,7 +12,7 @@ And in `infrastructure-live/dev` there are 2 dependencies on `terraform-aws-secu
 
 The **next safe** strategy will update a dependency to either the highest version **before the next closest breaking change** or the latest version of the dependency, whichever is encountered first.
 
-So if Patcher encounters a breaking change that it cannot patch then it will update the dependencies to the highest version before that breaking change and stop. Otherwise, if no breaking chnages are encountered it will update the dependencies the latest version of that module.
+So if Patcher encounters a breaking change that it cannot patch then it will update the dependencies to the highest version before that breaking change and stop. Otherwise, if no breaking changes are encountered it will update the dependencies the latest version of that module.
 
 For example, for the dependencies on `terraform-aws-security/custom-iam-entity` in `infrastructure-live/dev`:
 - `_global/ops-admin-role/terragrunt.hcl` will be updated from `0.65.6` to `0.68.2`, the latest version
@@ -45,7 +45,7 @@ This is an example of the YAML that Patcher writes to `stdout` describing these
 
 The **next breaking** strategy will update a dependency to either the next closest breaking change or the latest version of the dependency, whichever is encountered first.
 
-So if Patcher encounters a breaking change that it cannot patch then it will update the dependencies to the version with the breaking change and stop. Otherwise, if no breaking changes are encountered it will update the dependencies the latest version of that module.
+So if Patcher encounters a breaking change that it cannot patch then it will update the dependencies to the version with the breaking change and stop. Otherwise, if no breaking changes are encountered, it will update the dependencies to the latest version of that module.
 
 This may result in an update that requires manual intervention. If so, Patcher will provide additional information to help you understand what needs to be done.
 
@@ -96,9 +96,10 @@ Here are the release notes for version v0.62.0:
   - Once all Gruntwork repos have been upgraded to work with `1.1.x`, we will publish a migration guide with a version compatibility table and announce it all via the Gruntwork Newsletter.
 ```
 
+
 <!-- ##DOCS-SOURCER-START
 {
   "sourcePlugin": "local-copier",
-  "hash": "10db644584a7900aa21dbf422a64586f"
+  "hash": "69286f2c56cf15dd58fb969e3f7ade7d"
 }
 ##DOCS-SOURCER-END -->