docs: hyphenate "working-copy" when used as a compound modifier

docs/git-comparison.md

@@ -66,7 +66,7 @@ commit only part of the working copy. However, Jujutsu provides commands for
 more directly achieving most use cases you're used to using Git's index for. For
 example, to create a commit from part of the changes in the working copy, you
 might be used to using `git add -p; git commit`. With Jujutsu, you'd instead
-use `jj split` to split the working copy commit into two commits. To add more
+use `jj split` to split the working-copy commit into two commits. To add more
 changes into the parent commit, which you might normally use
 `git add -p; git commit --amend` for, you can instead use `jj squash -i` to
 choose which changes to move into the parent commit.
@@ -74,7 +74,7 @@ choose which changes to move into the parent commit.
 
 ## Command equivalence table
 
-Note that all `jj` commands can be run on any commit (not just the working copy
+Note that all `jj` commands can be run on any commit (not just the working-copy
 commit), but that's left out of the table to keep it simple. For example,
 `jj squash/amend -r <revision>` will move the diff from that revision into its
 parent.

docs/related-work.md

@@ -11,7 +11,7 @@ Similar tools:
   [GitUpKit library](https://github.com/git-up/GitUp#gitupkit).
 * [Gitless](https://gitless.com/): Another attempt at providing a simpler
   interface for Git. Like Jujutsu, does not have an "index"/"staging area"
-  concept. Also doesn't move the working copy changes between branches (which
+  concept. Also doesn't move the working-copy changes between branches (which
   we do simply as a consequence of making the working copy a commit).
 * [Pijul](https://pijul.org/): Architecturally quite different from Jujutsu,
   but its "first-class conflicts" feature seems quite similar to ours.

docs/revsets.md

@@ -23,7 +23,7 @@ The symbol `root` refers to the virtual commit that is the oldest ancestor of
 all other commits.
 
 The symbol `@` refers to the working copy commit in the current workspace. Use
-`<workspace name>@` to refer to the working copy commit in another workspace.
+`<workspace name>@` to refer to the working-copy commit in another workspace.
 
 A full commit ID refers to a single commit. A unique prefix of the full commit
 ID can also be used. It is an error to use a non-unique prefix.
@@ -116,7 +116,7 @@ revsets (expressions) as arguments.
 
 ## Examples
 
-Show the parent(s) of the working copy commit (like `git log -1 HEAD`):
+Show the parent(s) of the working-copy commit (like `git log -1 HEAD`):
 ```
 jj log -r @-
 ```

docs/tutorial.md

@@ -43,10 +43,10 @@ The working copy is clean
 ```
 
 You might have noticed that even though we asked to check out some commit
-(`080a9b37ff7e`), our working copy commit ended being another commit
+(`080a9b37ff7e`), our working-copy commit ended being another commit
 (`608c179a60df`). That is because `jj co` (short for `jj checkout`) creates a
 new commit on top of the commit you asked it to check out. The new commit is for
-the working copy changes. (There's some more nuance to this. We'll go through
+the working-copy changes. (There's some more nuance to this. We'll go through
 that in a bit.)
 
 ## Creating our first change
@@ -97,13 +97,13 @@ Jujutsu's diff format currently defaults to inline coloring of the diff (like
 `git diff --color-words`), so we used `--git` above to make the diff visible in
 this doc.
 
-As you may have noticed, the working copy commit's ID changed both when we
+As you may have noticed, the working-copy commit's ID changed both when we
 edited the description and when we edited the README. However, the parent commit
-stayed the same. Each change to the working copy commit amends the previous
-version. So how do we tell Jujutsu that we are done amending the working copy
+stayed the same. Each change to the working-copy commit amends the previous
+version. So how do we tell Jujutsu that we are done amending the working-copy
 commit? The answer is that we need to "close" the commit. When we close a
 commit, we indicate that we're done making changes to the commit. As described
-earlier, when we check out a commit, a new working copy commit is created on
+earlier, when we check out a commit, a new working-copy commit is created on
 top. However, that is only true for closed commits. If the commit is open, then
 that commit itself will be checked out instead.
 
@@ -123,7 +123,7 @@ indicates a closed commit.
 If we later realize that we want to make further changes, we can make them
 in the working copy and then run `jj squash`. That command squashes the changes
 from a given commit into its parent commit. Like most commands, it acts on the
-working copy commit by default.
+working-copy commit by default.
 
 ## The log command, "revsets", and aliases
 
@@ -139,7 +139,7 @@ o 080a9b37ff7e 6a91b4ba16c7 martinvonz@google.com 2021-05-23 22:08:37.000 -07:00
 ~ cli: make `jj st` show parent commit before working copy commit
 ```
 
-The `@` indicates the working copy commit. The first hash on a line is the
+The `@` indicates the working-copy commit. The first hash on a line is the
 commit ID. The second hash is a "change ID", which is an ID that follows the
 commit as it's rewritten (similar to Gerrit's Change-Id). You can give either
 hash to commands that take revisions as arguments. We will generally prefer
@@ -150,7 +150,7 @@ context.  The `~` indicates that the commit has parents that are not included
 in the graph. We can use the `-r` flag to select a different set of revisions we
 want to list. The flag accepts a ["revset"](revsets.md), which is an expression
 in a simple language for specifying revisions. For example, `@` refers to the
-working copy commit, `root` refers to the root commit, `branches()` refers to
+working-copy commit, `root` refers to the root commit, `branches()` refers to
 all commits pointed to by branches. We can combine expressions with `|` for
 union, `&` for intersection and `~` for difference. For example:
 ```shell script

docs/working-copy.md

@@ -8,9 +8,9 @@ interact with them. It also where files are read from in order to create new
 commits (though there are many other ways of creating new commits).
 
 Unlike most other VCSs, Jujutsu will automatically create commits from the
-working copy contents when they have changed. Most `jj` commands you run will
-commit the working copy changes if they have changed. The resulting revision
-will replace the previous working copy revision.
+working-copy contents when they have changed. Most `jj` commands you run will
+commit the working-copy changes if they have changed. The resulting revision
+will replace the previous working-copy revision.
 
 Also unlike most other VCSs, added files are implicitly tracked. That means that
 if you add a new file to the working copy, it will be automatically committed
@@ -51,7 +51,7 @@ You can even resolve part of a conflict by updating the different parts of the
 conflict marker.
 
 If the commit with conflicts was closed, your conflict resolution would be in
-the working copy commit. Once you have resolved the conflicts, you would then
+the working-copy commit. Once you have resolved the conflicts, you would then
 typically use `jj squash` to move the conflict resolutions into the conflicted
 commit.