Reword some of the documentation and spelling fixes

CONTRIBUTING.md

@@ -37,13 +37,13 @@ a separate e2e test suite in python (`just test-e2e`).
 
 To run all tests, run `just test`.
 
-When contributing, consider whether it makes sense to add tests that to prevent
-regressions in the future. When fixing bugs, it makes sense to add tests that
-expose the wrong behaviour beforehand.
+When contributing, consider whether it makes sense to add tests which could
+prevent regressions in the future. When fixing bugs, it makes sense to add
+tests that expose the wrong behaviour beforehand.
 
 ## Documentation
 
 The documentation lives in `docs` and uses
-[mdBook](https://github.com/rust-lang/mdBook).  Please document new user-facing
+[mdBook](https://github.com/rust-lang/mdBook). Please document new user-facing
 features here!
 

docs/src/forge_integration.md

@@ -17,7 +17,7 @@ You will end up with your projects cloned into `~/projects/{your_github_username
 
 ## Authentication
 
-The only currently supported authentication option is using personal access
+The only currently supported authentication option is using a personal access
 token.
 
 ### GitHub
@@ -27,7 +27,7 @@ See the GitHub documentation for personal access tokens:
 
 The only required permission is the "repo" scope.
 
-### GitHub
+### GitLab
 
 See the GitLab documentation for personal access tokens:
 [Link](https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html).

docs/src/repos.md

@@ -77,6 +77,6 @@ $ grm repos status
 ## YAML
 
 By default, the repo configuration uses TOML. If you prefer YAML, just give it
-a YAML file instead (file ending does not matter, `grm` will figure out the format
-itself). For generating a configuration, pass `--format yaml` to `grm repo find`
-to generate YAML instead of TOML.
+a YAML file instead (file ending does not matter, `grm` will figure out the format).
+For generating a configuration, pass `--format yaml` to `grm repo find`
+which generates a YAML config instead of a TOML configuration.

docs/src/worktrees.md

@@ -5,11 +5,11 @@
 The default workflow when using git is having your repository in a single directory.
 Then, you can check out a certain reference (usually a branch), which will update
 the files in the directory to match the state of that reference. Most of the time,
-this is exactly what you need and works perfectly. But especially when you're using
+this is exactly what you need and works perfectly. But especially when you're working
 with branches a lot, you may notice that there is a lot of work required to make
-everything run smootly.
+everything run smoothly.
 
-Maybe you experienced the following: You're working on a feature branch. Then,
+Maybe you have experienced the following: You're working on a feature branch. Then,
 for some reason, you have to change branches (maybe to investigate some issue).
 But you get the following:
 
@@ -20,7 +20,7 @@ error: Your local changes to the following files would be overwritten by checkou
 Now you can create a temporary commit or stash your changes. In any case, you have
 some mental overhead before you can work on something else. Especially with stashes,
 you'll have to remember to do a `git stash pop` before resuming your work (I
-cannot count the number of times where is "rediscovered" some code hidden in some
+cannot count the number of times where I "rediscovered" some code hidden in some
 old stash I forgot about.
 
 And even worse: If you're currently in the process of resolving merge conflicts or an
@@ -40,7 +40,7 @@ In any case, Git Worktrees are here for the rescue:
 independent checkouts of your repository on different directories. You can have
 multiple directories that correspond to different references in your repository.
 Each worktree has it's independent working tree (duh) and index, so there is no
-to run into conflicts. Changing to a different branch is just a `cd` away (if
+way to run into conflicts. Changing to a different branch is just a `cd` away (if
 the worktree is already set up).
 
 ## Worktrees in GRM
@@ -210,7 +210,7 @@ your changes to. I'd rather not delete work that you cannot recover."
 
 Note that `grm` is very cautious here. As your repository will not be deleted,
 you could still recover the commits via [`git-reflog`](https://git-scm.com/docs/git-reflog).
-But better safe then sorry! Note that you'd get a similar error message if your
+But better safe than sorry! Note that you'd get a similar error message if your
 worktree had any uncommitted files, for the same reason. Now you can either
 commit & push your changes, or your tell `grm` that you know what you're doing:
 
@@ -241,7 +241,7 @@ calls them "persistent branches" and treats them a bit differently:
   `grm wt delete`, which will not require a `--force` flag. Note that of
   course, actual changes in the worktree will still block an automatic cleanup!
 * As soon as you enable persistent branches, non-persistent branches will only
-  ever cleaned up when merged into a persistent branch.
+  ever be cleaned up when merged into a persistent branch.
 
 To elaborate: This is mostly relevant for a feature-branch workflow. Whenever a
 feature branch is merged, it can usually be thrown away. As merging is usually
@@ -340,7 +340,7 @@ $ grm wt rebase --pull --rebase
 hell is there a `--rebase` flag in the `rebase` command?"
 
 Yes, it's kind of weird. Remember that `pull` only ever updates each worktree
-to their remote branch, if possible. `rebase` rabases onto the **default** branch
+to their remote branch, if possible. `rebase` rebases onto the **default** branch
 instead. The switches to `rebase` are just convenience, so you do not have to
 run two commands.