about summary refs log tree commit diff
path: root/tvix
diff options
context:
space:
mode:
Diffstat (limited to 'tvix')
-rw-r--r--tvix/castore/docs/blobstore-chunking.md4
-rw-r--r--tvix/castore/docs/data-model.md6
-rw-r--r--tvix/castore/docs/why-not-git-trees.md2
-rw-r--r--tvix/eval/docs/bindings.md2
-rw-r--r--tvix/store/docs/api.md2
5 files changed, 8 insertions, 8 deletions
diff --git a/tvix/castore/docs/blobstore-chunking.md b/tvix/castore/docs/blobstore-chunking.md
index 49bbe6927554..df3c29680257 100644
--- a/tvix/castore/docs/blobstore-chunking.md
+++ b/tvix/castore/docs/blobstore-chunking.md
@@ -73,10 +73,10 @@ This means one only needs to the root digest to validate a constructions, and th
 constructions can be sent [separately][bao-spec].
 
 This relieves us from the need of having to encode more granular chunking into
-our data model / identifier upfront, but can make this a mostly a transport/
+our data model / identifier upfront, but can make this mostly a transport/
 storage concern.
 
-For the some more description on the (remote) protocol, check
+For some more description on the (remote) protocol, check
 `./blobstore-protocol.md`.
 
 #### Logical vs. physical chunking
diff --git a/tvix/castore/docs/data-model.md b/tvix/castore/docs/data-model.md
index 2df6761aae8f..5e6220cc23fa 100644
--- a/tvix/castore/docs/data-model.md
+++ b/tvix/castore/docs/data-model.md
@@ -15,8 +15,8 @@ a directory.
 
 All three message types have a `name` field, specifying the (base)name of the
 element (which MUST not contain slashes or null bytes, and MUST not be '.' or '..').
-For reproducibility reasons, the lists MUST be sorted by that name and also
-MUST be unique across all three lists.
+For reproducibility reasons, the lists MUST be sorted by that name and the
+name MUST be unique across all three lists.
 
 In addition to the `name` field, the various *Node messages have the following
 fields:
@@ -27,7 +27,7 @@ A `DirectoryNode` message represents a child directory.
 It has a `digest` field, which points to the identifier of another `Directory`
 message, making a `Directory` a merkle tree (or strictly speaking, a graph, as
 two elements pointing to a child directory with the same contents would point
-to the same `Directory` message.
+to the same `Directory` message).
 
 There's also a `size` field, containing the (total) number of all child
 elements in the referenced `Directory`, which helps for inode calculation.
diff --git a/tvix/castore/docs/why-not-git-trees.md b/tvix/castore/docs/why-not-git-trees.md
index fd46252cf55c..4a12b4ef5554 100644
--- a/tvix/castore/docs/why-not-git-trees.md
+++ b/tvix/castore/docs/why-not-git-trees.md
@@ -48,7 +48,7 @@ The git tree object format uses sha1 both for references to other trees and
 hashes of blobs, which isn't really a hash function to fundamentally base
 everything on in 2023.
 The [migration to sha256][git-sha256] also has been dead for some years now,
-and it's unclear how a "blake3" version of this would even look like.
+and it's unclear what a "blake3" version of this would even look like.
 
 [bao]: https://github.com/oconnor663/bao
 [blake3]: https://github.com/BLAKE3-team/BLAKE3
diff --git a/tvix/eval/docs/bindings.md b/tvix/eval/docs/bindings.md
index 2b062cb13d87..17867acfe9f9 100644
--- a/tvix/eval/docs/bindings.md
+++ b/tvix/eval/docs/bindings.md
@@ -62,7 +62,7 @@ This is done by compiling bindings in several phases:
 
    At the end of this phase, we know the stack slots of all namespaces for
    inheriting from, all values inherited from them, and all values (and
-   optionall keys) of bindings at the current level.
+   optionally keys) of bindings at the current level.
 
    Only statically known keys are actually merged, so any dynamic keys that
    conflict will lead to a "key already defined" error at runtime.
diff --git a/tvix/store/docs/api.md b/tvix/store/docs/api.md
index 01e72671a743..c5a5c477aa17 100644
--- a/tvix/store/docs/api.md
+++ b/tvix/store/docs/api.md
@@ -5,7 +5,7 @@ This document outlines the design of the API exposed by tvix-castore and tvix-
 store, as well as other implementations of this store protocol.
 
 This document is meant to be read side-by-side with
-[castore.md](../../tvix-castore/docs/castore.md) which describes the data model
+[castore.md](../../castore/docs/data-model.md) which describes the data model
 in more detail.
 
 The store API has four main consumers: