docs: fix spelling and punctuation

docs/config.md

@@ -1,6 +1,6 @@
 # Configuration
 
-These are the config settings available to jj/Jujutsu.
+These are the config settings available to `jj`/Jujutsu.
 
 
 ## Config files and TOML
@@ -642,7 +642,7 @@ Obviously, you would only set one line, don't copy them all in!
 ## Editing diffs
 
 The `ui.diff-editor` setting affects the default tool used for editing diffs
-(e.g.  `jj split`, `jj squash -i`). If it is not set, the special value
+(e.g. `jj split`, `jj squash -i`). If it is not set, the special value
 `:builtin` is used. It launches a built-in TUI tool (known as [scm-diff-editor])
 to edit the diff in your terminal.
 
@@ -767,7 +767,7 @@ same as the contents of `$right`.
 
 ### `JJ-INSTRUCTIONS`
 
-When editing a diff, jj will include a synthetic file called `JJ-INSTRUCTIONS`
+When editing a diff, `jj` will include a synthetic file called `JJ-INSTRUCTIONS`
 in the diff with instructions on how to edit the diff. Any changes you make to
 this file will be ignored. To suppress the creation of this file, set
 `ui.diff-instructions = false`.
@@ -1004,7 +1004,7 @@ backends.ssh.allowed-signers = "/path/to/allowed-signers"
 
 By default, if a single remote exists it is used for `jj git fetch` and `jj git
 push`; however if multiple remotes exist, the default remote is assumed to be
-named `"origin"`, just like in Git. Sometimes this is undesirable, e.g. when you
+named "origin", just like in Git. Sometimes this is undesirable, e.g. when you
 want to fetch from a different remote than you push to, such as a GitHub fork.
 
 To change this behavior, you can modify the [repository
@@ -1116,7 +1116,7 @@ To configure the Watchman filesystem monitor, set
 `core.fsmonitor = "watchman"`. Ensure that you have [installed the Watchman
 executable on your system](https://facebook.github.io/watchman/docs/install).
 
-You can configure `jj` to use watchman triggers to automatically create
+You can configure `jj` to use Watchman triggers to automatically create
 snapshots on filesystem changes by setting
 `core.watchman.register_snapshot_trigger = true`.
 

docs/contributing.md

@@ -39,7 +39,7 @@ test and document.
 
 The commit message should describe the changes in the commit;
 the PR description can even be empty, but feel free to include a personal
-message. We start the commit message with `<topic>: `  and don't use
+message. We start the commit message with `<topic>:`  and don't use
 [conventional commits](https://www.conventionalcommits.org/en/v1.0.0/). This means if
 you modified a command in the CLI, use its name as the topic, e.g.
 `next/prev: <your-modification>` or `conflicts: <your-modification>`. We don't
@@ -364,7 +364,7 @@ Windows, you'll need to understand and adapt the shell script):
 cloned from your fork of `jj` (e.g. `github.com/jjfan/jj`). You can also use a
 pure Git repo if you prefer.
 
-2. Make sure `github.com/jjfan/jj` includes the `gh-pages` bookmark of the jj repo
+2. Make sure `github.com/jjfan/jj` includes the `gh-pages` bookmark of the `jj` repo
 and run `git fetch origin gh-pages`.
 
 3. Go to the GitHub repository settings, enable GitHub Pages, and configure them
@@ -430,7 +430,7 @@ you can submit a PR based on the `gh-pages` bookmark of
 
 ## Modifying protobuffers (this is not common)
 
-Occasionally, you may need to change the `.proto` files that define jj's data
+Occasionally, you may need to change the `.proto` files that define `jj`'s data
 storage format. In this case, you will need to add a few steps to the above
 workflow.
 

docs/git-compatibility.md

@@ -156,7 +156,7 @@ repos may require you to deal with more involved Jujutsu and Git concepts.
   as Git represents them, unfinished `git rebase` states, as well as other less
   common states a Git repository can be in.
 
-* Colocated repositories are less resilient to
+* Co-located repositories are less resilient to
   [concurrency](technical/concurrency.md#syncing-with-rsync-nfs-dropbox-etc)
   issues if you share the repo using an NFS filesystem or Dropbox. In general,
   such use of Jujutsu is not currently thoroughly tested.

docs/glossary.md

@@ -14,7 +14,7 @@ A backend is an implementation of the storage layer. There are currently two
 builtin commit backends: the Git backend and the native backend. The Git backend
 stores commits in a Git repository. The native backend is used for testing
 purposes only. Alternative backends could be used, for example, if somebody
-wanted to use jj with a humongous monorepo (as Google does).
+wanted to use `jj` with a humongous monorepo (as Google does).
 
 There are also pluggable backends for storing other information than commits,
 such as the "operation store backend" for storing
@@ -141,7 +141,7 @@ The operation log is the
 [operation](#operation) objects, much in the same way that commits form a DAG,
 which is sometimes called the "commit history". When operations happen in
 sequence, they form a single line in the graph. Operations that happen
-concurrently from jj's perspective result in forks and merges in the DAG.
+concurrently from `jj`'s perspective result in forks and merges in the DAG.
 
 ## Repository
 
@@ -154,7 +154,7 @@ TODO
 
 ## Revision
 
-A synonym for [Commit](#commit).
+A synonym for [commit](#commit).
 
 ## Revset
 

docs/revsets.md

@@ -533,7 +533,7 @@ Show commits not on any remote bookmark:
 jj log -r 'remote_bookmarks()..'
 ```
 
-Show commits not on `origin` (if you have other remotes like `fork`):
+Show commits not on "origin" (if you have other remotes like "fork"):
 
 ```shell
 jj log -r 'remote_bookmarks(remote=origin)..'

docs/sapling-comparison.md

@@ -2,10 +2,10 @@
 
 ## Introduction
 
-This document attempts to describe how jj is different
+This document attempts to describe how `jj` is different
 from [Sapling](https://sapling-scm.com). Sapling is a VCS developed by Meta. It
-was announced about 3 years after development started on jj. It is a heavily
-modified fork of [Mercurial](https://www.mercurial-scm.org/). Because jj has
+was announced about 3 years after development started on `jj`. It is a heavily
+modified fork of [Mercurial](https://www.mercurial-scm.org/). Because `jj` has
 copied many ideas from Mercurial, there are many similarities between the two
 tools, such as:
 
@@ -18,11 +18,11 @@ tools, such as:
 
 ## Differences
 
-Here is a list of some differences between jj and Sapling.
+Here is a list of some differences between `jj` and Sapling.
 
 * **Working copy:** When using Sapling (like most VCSs), the
   user explicitly tells the tool when to create a commit and which files to
-  include. When using jj, the working copy
+  include. When using `jj`, the working copy
   is [automatically snapshotted by every command](working-copy.md). New files
   are automatically tracked and deleted files are automatically untracked. This
   has several advantages:
@@ -34,40 +34,40 @@ Here is a list of some differences between jj and Sapling.
     other commit.
 
 * **Conflicts:** Like most VCSs, Sapling requires the user to
-  resolve conflicts before committing. jj lets
+  resolve conflicts before committing. `jj` lets
   you [commit conflicts](conflicts.md). Note that it's a representation of the
   conflict that's committed, not conflict markers (`<<<<<<<` etc.). This also
   has several advantages:
 
   * Merge conflicts won't prevent you from checking out another commit.
   * You can resolve the conflicts when you feel like it.
-  * Rebasing descendants always succeeds. Like jj, Sapling automatically
+  * Rebasing descendants always succeeds. Like `jj`, Sapling automatically
     rebases, but it will fail if there are conflicts.
   * Merge commits can be rebased correctly (Sapling sometimes fails).
   * You can rebase conflicts and conflict resolutions.
 
-* **Undo:** jj's undo is powered by [the operation log](operation-log.md), which
+* **Undo:** `jj`'s undo is powered by [the operation log](operation-log.md), which
   records how the repo has changed over time. Sapling has a similar feature
   with its [MetaLog](https://sapling-scm.com/docs/internals/metalog).
-  They seem to provide similar functionality, but jj also exposes the log to the
+  They seem to provide similar functionality, but `jj` also exposes the log to the
   user via `jj op log`, so you can tell how far back you want to go back.
   Sapling has `sl debugmetalog`, but that seems to show the history of a single
-  commit, not the whole repo's history. Thanks to jj snapshotting the working
+  commit, not the whole repo's history. Thanks to `jj` snapshotting the working
   copy, it's possible to undo changes to the working copy. For example, if
   you `jj undo` a ` jj commit`, `jj diff` will show the same changes as
   before `jj commit`, but if you `sl undo` a `sl commit`, the working copy will
   be clean.
 * **Git interop:** Sapling supports cloning, pushing, and pulling from a remote
-  Git repo. jj also does, and it also supports sharing a working copy with a Git
+  Git repo. `jj` also does, and it also supports sharing a working copy with a Git
   repo, so you can use `jj` and `git` interchangeably in the same repo.
 * **Polish:** Sapling is much more polished and feature-complete. For example,
-  jj has no `blame/annotate` or `bisect` commands, and also no copy/rename
+  `jj` has no `blame/annotate` or `bisect` commands, and also no copy/rename
   support. Sapling also has very nice web UI
   called [Interactive Smartlog](https://sapling-scm.com/docs/addons/isl), which
   lets you drag and drop commits to rebase them, among other things.
 * **Forge workflow:** Sapling has `sl pr submit --stack`, which lets you
   push a stack of commits as separate GitHub PRs, including setting the base
-  branch. It only supports GitHub. jj doesn't have any direct integration with
+  branch. It only supports GitHub. `jj` doesn't have any direct integration with
   GitHub or any other forge. However, it has `jj git push --change` for
   automatically creating branches for specified commits. You have to specify
   each commit you want to create a branch for by using

docs/templates.md

@@ -302,7 +302,7 @@ This type cannot be printed. The following methods are defined.
 
 The default templates and aliases() are defined in the `[templates]` and
 `[template-aliases]` sections of the config respectively. The exact definitions
-can be seen in the `cli/src/config/templates.toml` file in jj's source tree.
+can be seen in the `cli/src/config/templates.toml` file in `jj`'s source tree.
 
 <!--- TODO: Find a way to embed the default config files in the docs -->