docs: mention that the "view" object knows about all workspaces

I seem to have forgotten to update this when I added support for
workspaces a while back.

I made some other little touchups while at it.

CHANGELOG.md

@@ -17,6 +17,9 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 Thanks to the people who made this release happen!
 
+ * Martin von Zweigbergk (@martinvonz)
+
+
 ## [0.6.1] - 2022-12-05
 
 No changes, only changed to a released version of the `thrift` crate dependency.

docs/operation-log.md

@@ -8,12 +8,12 @@ You can see the log with `jj op log`. Each operation object contains a snapshot
 of how the repo looked at the end of the operation. We call this snapshot a
 "view" object. The view contains information about where each branch, tag, and
 Git ref (in Git-backed repos) pointed, as well as the set of heads in the repo,
-and the current working-copy commit. The operation object also (in addition to
-the view) contains pointers to the operation(s) immediately before it, as well
-as metadata about the operation, such as timestamps, username, hostname,
-description.
+and the current working-copy commit in each workspace. The operation object also
+(in addition to the view) contains pointers to the operation(s) immediately
+before it, as well as metadata about the operation, such as timestamps,
+username, hostname, description.
 
-The operation log allows you to undo an operation (`jj op undo`), which doesn't
+The operation log allows you to undo an operation (`jj [op] undo`), which doesn't
 need to be the most recent one. It also lets you restore the entire repo to the
 way it looked at an earlier point (`jj op restore`).
 

docs/technical/concurrency.md

@@ -30,7 +30,7 @@ beginning. However, that means that operations that wouldn't actually conflict
 would still have to wait for each other. The user experience can be improved by
 using finer-grained locks and/or taking the locks later. The drawback of that is
 complexity. For example, you need to verify that any assumptions you made before
-locking are still valid.
+locking are still valid after you take the lock.
 
 To avoid depending on lock files, Jujutsu takes a different approach by
 accepting that concurrent changes can always happen. It instead exposes any
@@ -52,15 +52,16 @@ what allows us to detect and merge concurrent operations.
 
 ## Operation log
 
-The operation log is similar to a commit DAG (such as in Git), but each commit
-object is instead an "operation" and each tree object is instead a "view". The
-view object contains the set of visible head commits, branches, tags, and the
-working-copy commit. The operation object contains a pointer to the view object
-(like how commit objects point to tree objects), pointers to parent operation(s)
-(like how commit objects point to parent commit(s)), and metadata about the
-operation. These types are defined [here](../../lib/protos/op_store.proto). The
-operation log is normally linear. It becomes non-linear if there are concurrent
-operations.
+The operation log is similar to a commit DAG (such as in
+[Git's object model](https://git-scm.com/book/en/v2/Git-Internals-Git-Objects)),
+but each commit object is instead an "operation" and each tree object is instead
+a "view". The view object contains the set of visible head commits, branches,
+tags, and the working-copy commit in each workspace. The operation object
+contains a pointer to the view object (like how commit objects point to tree
+objects), pointers to parent operation(s) (like how commit objects point to
+parent commit(s)), and metadata about the operation. These types are defined
+[here](../../lib/protos/op_store.proto). The operation log is normally linear.
+It becomes non-linear if there are concurrent operations.
 
 When a command starts, it loads the repo at the latest operation. Because the
 associated view object completely defines the repo state, the running command
@@ -70,8 +71,8 @@ cannot fail to commit (except for disk failures and such). It is left for the
 next command to notice if there were concurrent operations. It will have to be
 able to do that anyway since the concurrent operation could have arrived via a
 distributed file system. This model -- where each operation sees a consistent
-view of the repo and are guaranteed to be able to commit their changes --
-greatly simplifies the implementation of commands.
+view of the repo and is guaranteed to be able to commit their changes -- greatly
+simplifies the implementation of commands.
 
 It is possible to load the repo at a particular operation with
 `jj --at-operation=<operation ID> <command>`. If the command is mutational, that