s/hyphen/em dash/g

5 files changed, 16 insertions, 16 deletions

diff --git a/tutorials/builds.sr.ht/github-integration.md b/tutorials/builds.sr.ht/github-integration.md
index 7a1091a..a26806f 100644
--- a/tutorials/builds.sr.ht/github-integration.md
+++ b/tutorials/builds.sr.ht/github-integration.md
@@ -25,7 +25,7 @@ tasks:
 This is a build manifest, written in [YAML](http://yaml.org/). When we submit
 this to builds.sr.ht, it will boot up an [Alpine
 Linux](https://alpinelinux.org/) virtual machine using the edge release of
-Alpine Linux. Then it will execute each of our build tasks - in this case,
+Alpine Linux. Then it will execute each of our build tasks — in this case,
 saying "hello world".
 
 ## Submitting jobs on the web
@@ -68,13 +68,13 @@ Before starting your tasks, builds.sr.ht will clone each repository listed in
 "sources" to the build environment. You can have as many or as few (including
 zero) git repositories as you like. builds.sr.ht will also install [Alpine
 Linux's meson package][meson] before starting your build. This uses Alpine's
-native `apk` package manager - other images use different package managers.
+native `apk` package manager — other images use different package managers.
 
 [meson]: https://pkgs.alpinelinux.org/package/edge/main/x86_64/meson
 
 ## Testing on other platforms
 
-Portability is important - so let's try running the same manifest on another
+Portability is important — so let's try running the same manifest on another
 operating system.
 
 ```yaml
@@ -101,7 +101,7 @@ different names for packages, different distributions of coreutils, and so on.
 ## Adding these builds to your GitHub repository
 
 Try making a new "mrsh" repository on your GitHub account. Note that forks won't
-work - so make sure you make a *new* repository and push the mrsh code to it.
+work — so make sure you make a *new* repository and push the mrsh code to it.
 Take a look at the `.builds` directory in mrsh: each of these build manifests
 can be submitted on push or pull request by rigging up a dispatch.sr.ht task.
 
diff --git a/tutorials/builds.sr.ht/using-build-secrets.md b/tutorials/builds.sr.ht/using-build-secrets.md
index 9b17511..47e74e8 100644
--- a/tutorials/builds.sr.ht/using-build-secrets.md
+++ b/tutorials/builds.sr.ht/using-build-secrets.md
@@ -23,7 +23,7 @@ tasks:
     rsync -r example.org/* example.org:/var/www/
 ```
 
-This is straightforward enough - but it won't work because the build won't have
+This is straightforward enough — but it won't work because the build won't have
 authorization to log into example.org.
 
 ## Generating the secrets & preparing our server
@@ -54,7 +54,7 @@ next step.
 
 Go to the [builds.sr.ht secret management
 dashboard](https://builds.sr.ht/secrets) and select "SSH key" for secret type,
-then paste your key into the text box. Click "submit" - and your new secret
+then paste your key into the text box. Click "submit" — and your new secret
 should show up on the right, along with its UUID.
 
 This UUID is used to uniquely identify this secret in build manifests. Copy this
@@ -80,7 +80,7 @@ tasks:
 
 It's as easy as that! builds.sr.ht will install this SSH key into your build
 environment when you submit this build manifest. However, it will only work for
-builds submitted with your user - if someone else copies and pastes this build
+builds submitted with your user — if someone else copies and pastes this build
 manifest, the SSH key will not be added to their build VM.
 
 ## Controlling the use of secrets
@@ -89,13 +89,13 @@ The easiest way to control whether or not secrets work in your build is by
 turning them off via the API: if you set secrets=false in [POST
 /api/jobs](/builds.sr.ht/api.md#post-apijobs), the secrets will not be resolved.
 This is automatically done in many places where the build manifest could be
-modified by an untrusted party - for example, dispatch.sr.ht disables secrets
+modified by an untrusted party — for example, dispatch.sr.ht disables secrets
 when submitting build manifests from GitHub pull requests.
 
 However, some degree of responsibility lies with you for keeping your secrets
 secure. Avoid writing build manifests that would print your secrets to the logs,
 particularly if using file secrets. If a secret is ever leaked in this manner,
-you should consider that secret compromised - revoke it and generate a new one.
+you should consider that secret compromised — revoke it and generate a new one.
 
 ---
 
diff --git a/tutorials/getting-started-with-builds.md b/tutorials/getting-started-with-builds.md
index 973473f..ab534ef 100644
--- a/tutorials/getting-started-with-builds.md
+++ b/tutorials/getting-started-with-builds.md
@@ -24,7 +24,7 @@ tasks:
 This is a build manifest, written in [YAML](http://yaml.org/). When we submit
 this to builds.sr.ht, it will boot up an [Alpine
 Linux](https://alpinelinux.org/) virtual machine using the edge release of
-Alpine Linux. Then it will execute each of our build tasks - in this case,
+Alpine Linux. Then it will execute each of our build tasks — in this case,
 saying "hello world".
 
 ## Submitting jobs on the web
@@ -93,12 +93,12 @@ tasks:
 
 This time, builds.sr.ht will install [Alpine Linux's meson
 package](https://pkgs.alpinelinux.org/package/edge/main/x86_64/meson) before
-starting your build. This uses Alpine's native `apk` package manager - other
+starting your build. This uses Alpine's native `apk` package manager — other
 images use different package managers.
 
 ## Testing on other platforms
 
-Portability is important - so let's try running the same manifest on another
+Portability is important — so let's try running the same manifest on another
 operating system.
 
 ```yaml
diff --git a/tutorials/set-up-account-and-git.md b/tutorials/set-up-account-and-git.md
index ae8c131..138dcd9 100644
--- a/tutorials/set-up-account-and-git.md
+++ b/tutorials/set-up-account-and-git.md
@@ -20,7 +20,7 @@ need to set up your SSH key and add it on the keys page.
 ## Generating an SSH key
 
 sr.ht does not support pushing to git repositories over HTTPS with a
-username+password - SSH keys are mandatory. If you already have an SSH key, you
+username+password — SSH keys are mandatory. If you already have an SSH key, you
 can skip this step. If not, run the following command to generate one:
 
     ssh-keygen
@@ -75,7 +75,7 @@ master branch to git.sr.ht:
     git push -u origin master
 
 Since this repository didn't previously exist, you'll be prompted with a link to
-create the repository on git.sr.ht - click that link and fill out the form on
+create the repository on git.sr.ht — click that link and fill out the form on
 that page. You'll be redirected to your repository on git.sr.ht: you're done!
 
 <div class="alert alert-primary">
diff --git a/tutorials/set-up-account-and-hg.md b/tutorials/set-up-account-and-hg.md
index 3d2cc7c..ecfe37d 100644
--- a/tutorials/set-up-account-and-hg.md
+++ b/tutorials/set-up-account-and-hg.md
@@ -19,7 +19,7 @@ need to set up your SSH key and add it on the keys page.
 ## Generating an SSH key
 
 sr.ht does not support pushing to Mercurial repositories over HTTPS with a
-username+password - SSH keys are mandatory. If you already have an SSH key, you
+username+password — SSH keys are mandatory. If you already have an SSH key, you
 can skip this step. If not, run the following command to generate one:
 
     ssh-keygen
@@ -68,7 +68,7 @@ Run the following command to push your changes to hg.sr.ht:
     hg push ssh://hg@hg.sr.ht/~{{{srht_username}}}/example
 
 Since this repository didn't previously exist, you'll be prompted with a link to
-create the repository on hg.sr.ht - click that link and fill out the form on
+create the repository on hg.sr.ht — click that link and fill out the form on
 that page. You'll be redirected to your repository on hg.sr.ht: you're done!
 
 You can save yourself some typing and just run `hg push` next time by adding