chore: Standardize on term 'working copy'

Author: bts

src/advanced/simultaneous-edits.md

@@ -211,10 +211,10 @@ Check out this `jj log`:
 
 Glorious!
 
-So now our working directory has all of our changes in it. We can make changes,
-and then `jj squash` them into the appropriate branch. If we decide we want a
-new change at the head of any of these branches, we'll need to use a rebase,
-but it's not too bad:
+So now our working copy has all of our changes in it. We can make changes, and
+then `jj squash` them into the appropriate branch. If we decide we want a new
+change at the head of any of these branches, we'll need to use a rebase, but
+it's not too bad:
 
 ```console
 > jj new z -m "second 80% done"

src/branching-merging-and-conflicts/merging.md

@@ -211,8 +211,8 @@ working copy, and if that's in conflict, it has to be fixed or the next commit
 is nonsense. We'll talk about how `jj` handles conflicts shortly, but as I
 said before: rebases *always* succeed in `jj`. So this change is quick: it's
 only modifying information in the repository, not touching any of the files we
-have in our working directory. This also means our working directory hasn't
-changed, so `@` is in the same place it was before the rebase.
+have in our working copy. This also means our working copy hasn't changed, so
+`@` is in the same place it was before the rebase.
 
 Some commands do move `@` by default, like `jj new`. This is because if you're
 creating a new change, you probably want to start working on it. But it has a

src/branching-merging-and-conflicts/revsets.md

@@ -25,12 +25,11 @@ are other examples of symbols.
 
 Operators let you describe more complex relationships between changes. For
 example, remember how in the squash workflow, we would move the contents of
-the working directory into the parent change? Well, the `-` operator refers to
-the parent of a given revision, and `@` is the change referring to the current
-working directory, so we might say "we squashed the contents of `@` into `@-`.
-And in fact, `jj squash` is short for `jj squash -r @` or equivalently `jj
-squash --from @ --into @-`. There are many operators, including, but not
-limited to:
+the working copy into the parent change? Well, the `-` operator refers to the
+parent of a given revision, and `@` is the change referring to the current
+working copy, so we might say "we squashed the contents of `@` into `@-`. And
+in fact, `jj squash` is short for `jj squash -r @` or equivalently `jj squash
+--from @ --into @-`. There are many operators, including, but not limited to:
 
 * `x & y`: changes that are in both x and y
 * `x | y`: changes that are in either x or y
@@ -88,10 +87,10 @@ decent revset for larger repositories:
 $ jj log -r '@ | ancestors(remote_bookmarks().., 2) | trunk()'
 ```
 
-This will show the history from the working directory, some detail about remote
-branches, as well as the trunk. What's good varies between what you're trying to
-do and what your repository looks like, so experiment with some of this stuff
-to find something that works well for you.
+This will show the history from the working copy, some detail about remote
+branches, as well as the trunk. What's good varies between what you're trying
+to do and what your repository looks like, so experiment with some of this
+stuff to find something that works well for you.
 
 Revsets are very powerful, and you'll learn some useful ones as you explore
 more. At some point, we'll even talk about how to create custom aliases for

src/hello-world/creating-new-changes.md

@@ -21,7 +21,7 @@ Working copy : puomrwxl 01a35aad (empty) (no description set)
 Parent commit: yyrsmnoo ac691d85 hello world
 ```
 
-Nice, a clean working directory: all of our changes were made in `yyrsmnoo`, and
+Nice, a clean working copy: all of our changes were made in `yyrsmnoo`, and
 we're starting this change fresh.
 
 We now technically have a very primitive, but near-complete, workflow. That's