6 files changed, 14 insertions, 14 deletions
diff --git a/builds.sr.ht/api.md b/builds.sr.ht/api.md
index ba9c069..bd79378 100644
--- a/builds.sr.ht/api.md
+++ b/builds.sr.ht/api.md
@@ -43,9 +43,9 @@ Inserts a new job into the job queue.
                                   lowercase alphanumeric characters, or any
                                   of "-_." (optional)
   "execute": boolean,           True to start the build immediately
-                                  (optional - defaults to true)
+                                  (optional — defaults to true)
   "secrets": boolean,           True to provide secrets during the build
-                                  (optional - defaults to true)
+                                  (optional — defaults to true)
 }
 ```
 
diff --git a/builds.sr.ht/compatibility.md b/builds.sr.ht/compatibility.md
index 59b59a9..41c9af8 100644
--- a/builds.sr.ht/compatibility.md
+++ b/builds.sr.ht/compatibility.md
@@ -19,7 +19,7 @@ The support lifecycle for each build image follows the upstream support cycle.
 Each supported upstream release is generally offered on sr.ht, as well as the
 bleeding edge or development releases if applicable. No sooner than two weeks
 after a release becomes unsupported upstream, it will be unsupported on
-builds.sr.ht - and anyone who's submitted recent builds using those images will
+builds.sr.ht — and anyone who's submitted recent builds using those images will
 get an email warning them of the impending breakage.
 
 It's recommended that you use aliases like "alpine/latest" or "debian/testing"
diff --git a/builds.sr.ht/configuration.md b/builds.sr.ht/configuration.md
index 9e52038..0d38492 100644
--- a/builds.sr.ht/configuration.md
+++ b/builds.sr.ht/configuration.md
@@ -56,7 +56,7 @@ runner if you prefer). They need the following permissions:
   and read access to the user and secrets tables.
 
 If you are running the master and runners on the same server, you will only be
-able to use one user - the master user. Configure both the web service and build
+able to use one user — the master user. Configure both the web service and build
 runner with this account. Otherwise, two separate accounts is recommended.
 
 Note: in the future runners will not have database access.
@@ -90,7 +90,7 @@ directory.
 A `build.yml` file is also provided for each image to build itself on your
 build infrastructure once you have it set up, which you should customize as
 necessary. It's recommended that you set up cron jobs to build fresh images
-frequently - a script at `contrib/submit_image_build` is provided for this
+frequently — a script at `contrib/submit_image_build` is provided for this
 purpose.
 
 **Note**: it is recommended that you modify our `build.yml` files to suit your
@@ -132,7 +132,7 @@ In order to run builds, we require the following:
 - SSH listening on port 22 (the standard port) with passwordless login *enabled*
 - A user named `build` to log into SSH with, preferrably with uid 1000
 - git config setting user.name to builds.sr.ht and user.email to builds@sr.ht
-- Bash (temporary - we'll make this more generic at some point)
+- Bash (temporary — we'll make this more generic at some point)
 
 Not strictly necessary, but recommended:
 
diff --git a/builds.sr.ht/index.md b/builds.sr.ht/index.md
index 54e4518..831fa71 100644
--- a/builds.sr.ht/index.md
+++ b/builds.sr.ht/index.md
@@ -28,12 +28,12 @@ on.
 # How jobs are submitted
 
 Unlike some other build systems, builds.sr.ht does not let you configure builds
-on the website itself. Instead, you write build *manifests* - YAML files that
+on the website itself. Instead, you write build *manifests* — YAML files that
 tell builds.sr.ht what to do. You can then submit these manifests via the API
 and we'll assign a runner and execute your job.
 
 For convenience, there are ways of submitting builds automatically throughout
-the sr.ht ecosystem - for example by pushing to repositories on git.sr.ht.
+the sr.ht ecosystem — for example by pushing to repositories on git.sr.ht.
 These integrations are [discussed below](#integrations). For details on
 submitting jobs via the API, see the [API reference](api.md).
 
@@ -55,7 +55,7 @@ tasks:
 When you submit this build, we'll fire up a virtual machine running an
 up-to-date image of Alpine Linux. Then, we'll copy your scripts into the machine
 and run them one at a time. More complex build jobs will probably use more
-features of the build.yml - here's an example that deploys
+features of the build.yml — here's an example that deploys
 [web.synapse-bt.org](https://web.synapse-bt.org):
 
 ```yaml
@@ -201,7 +201,7 @@ submitted, 4 manifests will be randomly chosen).
 ## hg.sr.ht
 
 hg.sr.ht will also automatically submit builds for you. The naming conventions
-and other details are the same as the process used by git.sr.ht - described
+and other details are the same as the process used by git.sr.ht — described
 above.
 
 ## hub.sr.ht
diff --git a/builds.sr.ht/installation.md b/builds.sr.ht/installation.md
index 8c3485c..1cd429f 100644
--- a/builds.sr.ht/installation.md
+++ b/builds.sr.ht/installation.md
@@ -25,8 +25,8 @@ On each server hosting a job runner, install the `builds.sr.ht-worker` and
 
 ## Daemons
 
-- `builds.sr.ht` - The web service (master server).
-- `builds.sr.ht-worker` - The job runner.
+- `builds.sr.ht` — The web service (master server).
+- `builds.sr.ht-worker` — The job runner.
 
 ## Configuration
 
diff --git a/builds.sr.ht/private-repos.md b/builds.sr.ht/private-repos.md
index 403e9ed..a3946d0 100644
--- a/builds.sr.ht/private-repos.md
+++ b/builds.sr.ht/private-repos.md
@@ -4,7 +4,7 @@ title: Private repos on builds.sr.ht
 
 <div class="alert alert-danger">
   <strong>Warning!</strong> The list of commands run in a builds.sr.ht job, as
-  well as their stdout and stderr, are visible to the public - even if the job
+  well as their stdout and stderr, are visible to the public — even if the job
   uses a private repository. Take care not to leak any secrets this way.
 </div>
 
@@ -15,7 +15,7 @@ configure each job with an SSH key that has access to your account.
 1. Add the public key [to your account](https://meta.sr.ht/keys)
 1. Add the private key as a secret using the [secrets management page](https://builds.sr.ht/secrets)
 1. Copy the secret's UUID into your build manifest's secrets list.
-1. Update your sources list to use the SSH clone URL - not the https clone URL.
+1. Update your sources list to use the SSH clone URL — not the https clone URL.
 
 The resulting build manifest should look something like this: