s/hyphen/em dash/g

api-conventions.md

@@ -70,7 +70,7 @@ All requests and response bodies shall be encoded with Content-Type
 Each resource returned by the API has its own schema, and may be given in two
 forms: *full form* and *short form*. The full form is always returned when
 retrieving a resource by ID, and contains the maximum amount of detail.  The
-short form contains less information - an ID at the minimum, but often more -
+short form contains less information — an ID at the minimum, but often more -
 and is returned where the long form would be inconvenient, such as from a list
 endpoint or for singletons embedded in a parent resource.
 
@@ -134,7 +134,7 @@ versioning, each version being of the format "major.minor.patch". The patch
 number increments with every release, the minor number increments when new
 features are added, and the major version increments on breaking changes. Note
 that the minor and patch versions may increment when changes are made to the web
-frontend - which may not necessarily affect the API - but major versions only
+frontend — which may not necessarily affect the API — but major versions only
 increment on breaking API changes. Any API whose major version is 0 makes no
 guarantees about interface stability.
 
@@ -184,7 +184,7 @@ meta.sr.ht) `profile:update` or `ssh-key:remove`. These require the same OAuth
 scopes to configure as are necessary to obtain these resources through polling -
 there's no separate OAuth scope for webhooks.
 
-Periodically polling the API is discouraged - use webhooks instead.
+Periodically polling the API is discouraged — use webhooks instead.
 
 ### Webhook delivery
 

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)
 }
 ```
 

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"

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:
 

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

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
 

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:
 

configuration.md

@@ -25,7 +25,7 @@ Before configuring any sr.ht service, ensure that you have the following
 services installed. Every sr.ht service makes use of them, so your deployment
 will likely not work as expected if they are missing.
 
-- [core.sr.ht][core] - Provides functionality used by all sr.ht services.
+- [core.sr.ht][core] — Provides functionality used by all sr.ht services.
 
     - For users installing from packages, this package is automatically pulled
       in as a dependency.
@@ -40,7 +40,7 @@ will likely not work as expected if they are missing.
              class="alert-link">Alpine package</a>.
         </div>
 
-- [meta.sr.ht][meta] - Performs various administrative tasks (e.g., storing
+- [meta.sr.ht][meta] — Performs various administrative tasks (e.g., storing
   account details, handling logins, SSH and PGP key storage).
 
 [meta]: https://git.sr.ht/~sircmpwn/meta.sr.ht

dispatch.sr.ht/installation.md

@@ -12,7 +12,7 @@ installation process](/installation.md#installing-from-packages).
 
 ## Daemons
 
-- `dispatch.sr.ht` - The web service.
+- `dispatch.sr.ht` — The web service.
 
 ## Configuration
 

git.sr.ht/api.md

@@ -467,4 +467,4 @@ executing `git push`. Your server has 5 seconds to respond to the HTTP request.
 - Push options (specified via `git push -o <option>`) are interpreted as
   `key=value`, and the map is populated as such. For example, `git push -o
   foo=bar` would result in `{"foo": "bar"}`. Options specified without a value -
-  e.g. `-o foo` - will have their value set to an empty string.
+  e.g. `-o foo` — will have their value set to an empty string.

git.sr.ht/index.md

@@ -152,7 +152,7 @@ git tag -a <tag name>
 ```
 
 For example, `git tag -a 2.3.4` to tag version 2.3.4. Your text editor will
-open, and you'll be prompted to *annotate* the tag - fill this in with release
+open, and you'll be prompted to *annotate* the tag — fill this in with release
 notes, a changelog, etc. Consider using
 [`git-shortlog`](https://git-scm.com/docs/git-shortlog) to generate your
 changelog.

git.sr.ht/installation.md

@@ -12,13 +12,13 @@ installation](/installation.md#installing-from-packages).
 
 ## Daemons
 
-- `git.sr.ht` - The web service.
-- `git.sr.ht-api` - The API service.
-- `git.sr.ht-webhooks` - Webhook delivery service.
+- `git.sr.ht` — The web service.
+- `git.sr.ht-api` — The API service.
+- `git.sr.ht-webhooks` — Webhook delivery service.
 
 ## Cronjobs
 
-- `gitsrht-periodic` - Performs various maintenance tasks.
+- `gitsrht-periodic` — Performs various maintenance tasks.
 
 ## Configuration
 

git.sr.ht/send-email.md

@@ -14,7 +14,7 @@ https://git-send-email.io
 ## Tell people how to contribute
 
 The first thing you need to do is help potential contributors figure out how to
-contact you. The easiest way is to do nothing - git records your email with
+contact you. The easiest way is to do nothing — git records your email with
 every commit, so someone with a copy of your git repository can figure out how
 to contact you. You'll probably want to make it a bit easier on them, though.
 
@@ -30,7 +30,7 @@ When a patch comes in, you should review it carefully. Read the code, apply the
 patch locally and make sure it compiles, test the changes, and so on. During
 this process you'll probably come up with feedback on the patch. Pull open that
 email client and compose a reply to the patch author. When your client composes
-the reply, don't be afraid to slice and dice the email you're replying to - trim
+the reply, don't be afraid to slice and dice the email you're replying to — trim
 out the fat and only include specific lines that you want to comment on.
 
 If you only have small comments here and there, feel free to make the changes

graphql.md

@@ -142,7 +142,7 @@ query {
 ```
 
 Each field adds 1 to your complexity, unless it represents a relationship like
-sshKeys - in which case it is multiplied by the number of results you request.
+sshKeys — in which case it is multiplied by the number of results you request.
 The total complexity of your request is capped to 200 by default; some services
 permit more.
 

hg.sr.ht/email.md

@@ -28,15 +28,15 @@ out, check out the [sr.ht-dev][sr.ht-dev] mailing list.
 [sr.ht-dev]: https://lists.sr.ht/~sircmpwn/sr.ht-dev
 
 Unsure if your setup is correct? Try sending the patch to sir@cmpwn.com for
-feedback first - make sure you mention in the email that you want feedback.
+feedback first — make sure you mention in the email that you want feedback.
 
 # For contributors
 
 ## Preparing your changes
 
-There's no need to "fork" the repository you want to contribute to -- simply use
+There's no need to "fork" the repository you want to contribute to — simply use
 [`hg clone`][hg-clone] to obtain a local copy of the mercurial repository and
-[work normally][work-normally]. Be deliberate about your commits -- use
+[work normally][work-normally]. Be deliberate about your commits — use
 meaningful commit messages and take special care to commit your work in the form
 of logically separate changes. When it comes time to review your work, your
 commit history is an important tool for the reviewer and will be closely
@@ -48,10 +48,10 @@ examined.
 # Find out where to send your changes
 
 This workflow is optional for projects hosted on sr.ht and each project will
-have different requirements - review them carefully. To use this guide, you need
-to find an email address to send your work to - this will often be a mailing
+have different requirements — review them carefully. To use this guide, you need
+to find an email address to send your work to — this will often be a mailing
 list on [lists.sr.ht](/lists.sr.ht). You will also want to find people who can
-help review your changes - look for dedicated maintainers for the modules you're
+help review your changes — look for dedicated maintainers for the modules you're
 working on, or use [`hg annotate`][hg-annotate] to find people who have recently
 worked on similar code.
 
@@ -201,7 +201,7 @@ any other value passed through the command-line.
 ## Tell people how to contribute
 
 The first thing you need to do is help potential contributors figure out how to
-contact you. The easiest way is to do nothing - mercurial records your email
+contact you. The easiest way is to do nothing — mercurial records your email
 with every commit, so someone with a copy of your mercurial repository can
 figure out how to contact you. You'll probably want to make it a bit easier on
 them, though.
@@ -218,7 +218,7 @@ When a patch comes in, you should review it carefully. Read the code, apply the
 patch locally and make sure it compiles, test the changes, and so on. During
 this process you'll probably come up with feedback on the patch. Pull open that
 email client and compose a reply to the patch author. When your client composes
-the reply, don't be afraid to slice and dice the email you're replying to - trim
+the reply, don't be afraid to slice and dice the email you're replying to — trim
 out the fat and only include specific lines that you want to comment on.
 
 If you only have small comments here and there, feel free to make the changes

hg.sr.ht/installation.md

@@ -12,7 +12,7 @@ installation process](/installation.md#installing-from-packages).
 
 ## Daemons
 
-- `hg.sr.ht` - The web service.
+- `hg.sr.ht` — The web service.
 
 ## Cronjobs
 

installation.md

@@ -48,14 +48,14 @@ security vulnerabilities, and so on.
 
 Most sr.ht services require the following:
 
-- A [PostgreSQL](https://www.postgresql.org/) server - persistent storage
+- A [PostgreSQL](https://www.postgresql.org/) server — persistent storage
 
-- A [Redis](https://redis.io) server - ephemeral storage, caching, work
+- A [Redis](https://redis.io) server — ephemeral storage, caching, work
   distribution
 
-- A mail server - incoming/outgoing mail
+- A mail server — incoming/outgoing mail
 
-- A cron daemon - scheduled tasks
+- A cron daemon — scheduled tasks
 
 # Installing From Packages
 

lists.sr.ht/configuration.md

@@ -13,7 +13,7 @@ to accept SMTP and run on another server. See `config.ini` for details.
 
 The LMTP daemon uses the same config file as the others, and there are some
 options there specifically catered to it. The most important is the Unix socket
-path for the LMTP socket - and the user/group it should be assigned to. Make
+path for the LMTP socket — and the user/group it should be assigned to. Make
 sure that this is readable and writable by your MTA.
 
 Enable the `lists.sr.ht-lmtp` service and configure your MTA to forward emails

lists.sr.ht/index.md

@@ -107,7 +107,7 @@ fine-grained enough to support many access scenarios, here are some examples:
 ## Announcement lists
 
 A list that only you can write to is useful for announcements. Remove all user's
-"post" and "reply" permissions to prevent them from submitting - owners are
+"post" and "reply" permissions to prevent them from submitting — owners are
 always able to post. You can optionally leave the "reply" permission enabled to
 allow people to respond to announcements, but be aware that their responses will
 be sent out to all subscribers, which is usually undesirable for low-volume

lists.sr.ht/installation.md

@@ -12,10 +12,10 @@ installation process](/installation.md#installing-from-packages).
 
 ## Daemons
 
-- `lists.sr.ht` - The web service.
-- `lists.sr.ht-lmtp` - Incoming mail service.
-- `lists.sr.ht-process` - Mail processing service.
-- `lists.sr.ht-webhooks` - Webhook delivery service.
+- `lists.sr.ht` — The web service.
+- `lists.sr.ht-lmtp` — Incoming mail service.
+- `lists.sr.ht-process` — Mail processing service.
+- `lists.sr.ht-webhooks` — Webhook delivery service.
 
 ## Configuration
 

man.sr.ht/index.md

@@ -35,7 +35,7 @@ are:
 
 Publishing your changes is as easy as committing them and pushing them
 upstream. You can collaborate with others on your wiki the same way you
-do on your git.sr.ht projects - a mailing list on lists.sr.ht or
+do on your git.sr.ht projects — a mailing list on lists.sr.ht or
 any other approach that you like.
 
 ## Settings

man.sr.ht/installation.md

@@ -16,7 +16,7 @@ installation process](/installation.md#installing-from-packages).
 
 ## Daemons
 
-- `man.sr.ht` - The web service.
+- `man.sr.ht` — The web service.
 
 ## Configuration
 

meta.sr.ht/installation.md

@@ -17,9 +17,9 @@ installation process](/installation.md#installing-from-packages).
 
 ## Daemons
 
-- `meta.sr.ht` - The web service.
-- `meta.sr.ht-api` - The API service.
-- `meta.sr.ht-webhooks` - Webhook delivery service.
+- `meta.sr.ht` — The web service.
+- `meta.sr.ht-api` — The API service.
+- `meta.sr.ht-webhooks` — Webhook delivery service.
 
 ## Cronjobs
 

meta.sr.ht/oauth-api.md

@@ -59,11 +59,11 @@ Provide the following parameters in the query string:
     <dt>client_id</dt>
     <dd>The client ID assigned to you in the previous step.</dd>
     <dt>scopes</dt>
-    <dd>A list of scopes you're requesting - see next section.</dd>
+    <dd>A list of scopes you're requesting — see next section.</dd>
     <dt>state</dt>
-    <dd>Optional: an arbitrary string - see notes.</dd>
+    <dd>Optional: an arbitrary string — see notes.</dd>
     <dt>redirect_uri</dt>
-    <dd>Optional: your application URI for redirect the user to - see notes.</dd>
+    <dd>Optional: your application URI for redirect the user to — see notes.</dd>
 </dl>
 
 The optional `state` field is returned to you after the redirect. One example
@@ -112,7 +112,7 @@ some additional query string parameters you can use for the next steps:
     <dt>scopes</dt>
     <dd>The list of OAuth scopes the user consented to.</dd>
     <dt>error</dt>
-    <dd>If present, indicates that an error occurred in the process - see notes.</dd>
+    <dd>If present, indicates that an error occurred in the process — see notes.</dd>
     <dt>details</dt>
     <dd>If present, a human friendly error string, if that human is an engineer.</dd>
 </dl>

ops/backups.md

@@ -30,7 +30,7 @@ report to the [ops mailing list][ops ml].
    ensure that our snapshots are actually being taken.
 2. Investigate something like [repospanner](https://github.com/repoSpanner/repoSpanner)
    to block git pushes until the data is known to be received and stored across
-   multiple servers - would make git backups real-time
+   multiple servers — would make git backups real-time
 
 # Off-site backups
 

ops/monitoring.md

@@ -14,7 +14,7 @@ Our Prometheus instance is publically available at
 1. We should make dashboards. It would be pretty to look at and could be a
    useful tool for root cause analysis. Note that some users who have their own
    Grafana instance have pointed it at our public Prometheus data and made some
-   simple dashboards - I would be open to having community ownership over this.
+   simple dashboards — I would be open to having community ownership over this.
 
 # Pushgateway
 

ops/new-sysadmin.md

@@ -31,6 +31,6 @@ the correct account? Is the email they sent DKIM signed and verified from the
 right sender? If in doubt, ask for a secondary form of authentication, such as a
 PGP challenge.
 
-This also applies to normal requests from users - don't let someone impersonate
+This also applies to normal requests from users — don't let someone impersonate
 another user in an attempt to gain access to or manipulate their account. Be
 especially careful with requests from users with 2FA enabled.

ops/provisioning.md

@@ -44,5 +44,5 @@ This configuration supports up to 16 parallel build slots.
 
 # Virtual machines
 
-There is no standard loadout - tune the specifications for the task at hand.
+There is no standard loadout — tune the specifications for the task at hand.
 Generally limit 1 VM == 1 service, and tune accordingly.

pages.sr.ht/installation.md

@@ -14,7 +14,7 @@ installation](/installation.md#installing-from-packages).
 
 ## Daemons
 
-- `pages.sr.ht` - The web and API service.
+- `pages.sr.ht` — The web and API service.
 
 ## Configuration
 

paste.sr.ht/installation.md

@@ -11,4 +11,4 @@ installation process](/installation.md#installing-from-packages).
 
 ## Daemons
 
-- `paste.sr.ht` - The web service.
+- `paste.sr.ht` — The web service.

privacy.md

@@ -69,7 +69,7 @@ give us, including (but not limited to):
 
 To faciliate automated access to your account for third-party service or your
 personal use, we also generate and store API keys which can be used to authorize
-use of your account. A portion of these keys are stored in plaintext - not
+use of your account. A portion of these keys are stored in plaintext — not
 enough to gain access to your account, but enough for us to quickly look up your
 account details given the key. The full key is stored only after processing with
 bcrypt, similar to the process used for your password.

todo.sr.ht/installation.md

@@ -12,9 +12,9 @@ installation process](/installation.md#installing-from-packages).
 
 ## Daemons
 
-- `todo.sr.ht` - The web service.
-- `todo.sr.ht-lmtp` - Incoming mail service.
-- `todo.sr.ht-webhooks` - Webhook delivery service.
+- `todo.sr.ht` — The web service.
+- `todo.sr.ht-lmtp` — Incoming mail service.
+- `todo.sr.ht-webhooks` — Webhook delivery service.
 
 ## Configuration
 

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.
 

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.
 
 ---
 

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

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">

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