diff options
| author | Junio C Hamano <gitster@pobox.com> | 2023-10-23 14:45:54 -0700 |
|---|---|---|
| committer | Junio C Hamano <gitster@pobox.com> | 2023-10-23 14:45:54 -0700 |
| commit | 33be82183d4cd6dc645f64da1402cf9a3f4cdbf3 (patch) | |
| tree | 4a681cad5c6da23a7d7f56022666fb31397026d2 /technical | |
| parent | 359f02427091f2c0fcac4eb7651fe5d159b84a54 (diff) | |
| download | git-htmldocs-33be82183d4cd6dc645f64da1402cf9a3f4cdbf3.tar.gz | |
Autogenerated HTML docs for v2.42.0-482-g2e8e7
Diffstat (limited to 'technical')
31 files changed, 88 insertions, 88 deletions
diff --git a/technical/api-error-handling.html b/technical/api-error-handling.html index 35b06fb42..fb9133085 100644 --- a/technical/api-error-handling.html +++ b/technical/api-error-handling.html @@ -735,7 +735,7 @@ asciidoc.install(); <body class="article">
<div id="header">
<h1>Error reporting in git</h1>
-<span id="revdate">2023-10-20</span>
+<span id="revdate">2023-10-23</span>
</div>
<div id="content">
<div id="preamble">
diff --git a/technical/api-index-skel.txt b/technical/api-index-skel.txt index eda8c195c..7780a76b0 100644 --- a/technical/api-index-skel.txt +++ b/technical/api-index-skel.txt @@ -1,7 +1,7 @@ Git API Documents ================= -Git has grown a set of internal API over time. This collection +Git has grown a set of internal APIs over time. This collection documents them. //////////////////////////////////////////////////////////////// diff --git a/technical/api-index.html b/technical/api-index.html index 11581bb7b..25ba484fe 100644 --- a/technical/api-index.html +++ b/technical/api-index.html @@ -735,12 +735,12 @@ asciidoc.install(); <body class="article">
<div id="header">
<h1>Git API Documents</h1>
-<span id="revdate">2023-10-20</span>
+<span id="revdate">2023-10-23</span>
</div>
<div id="content">
<div id="preamble">
<div class="sectionbody">
-<div class="paragraph"><p>Git has grown a set of internal API over time. This collection
+<div class="paragraph"><p>Git has grown a set of internal APIs over time. This collection
documents them.</p></div>
<div class="ulist"><ul>
<li>
@@ -776,7 +776,7 @@ documents them.</p></div> <div id="footer">
<div id="footer-text">
Last updated
- 2023-08-21 10:25:12 PDT
+ 2023-10-23 14:43:49 PDT
</div>
</div>
</body>
diff --git a/technical/api-index.txt b/technical/api-index.txt index b73de5539..311479f9f 100644 --- a/technical/api-index.txt +++ b/technical/api-index.txt @@ -1,7 +1,7 @@ Git API Documents ================= -Git has grown a set of internal API over time. This collection +Git has grown a set of internal APIs over time. This collection documents them. //////////////////////////////////////////////////////////////// diff --git a/technical/api-merge.html b/technical/api-merge.html index 47fde9187..bec282e67 100644 --- a/technical/api-merge.html +++ b/technical/api-merge.html @@ -735,7 +735,7 @@ asciidoc.install(); <body class="article">
<div id="header">
<h1>merge API</h1>
-<span id="revdate">2023-10-20</span>
+<span id="revdate">2023-10-23</span>
</div>
<div id="content">
<div id="preamble">
diff --git a/technical/api-parse-options.html b/technical/api-parse-options.html index 421279f4c..38531ea69 100644 --- a/technical/api-parse-options.html +++ b/technical/api-parse-options.html @@ -735,7 +735,7 @@ asciidoc.install(); <body class="article">
<div id="header">
<h1>parse-options API</h1>
-<span id="revdate">2023-10-20</span>
+<span id="revdate">2023-10-23</span>
</div>
<div id="content">
<div id="preamble">
diff --git a/technical/api-simple-ipc.html b/technical/api-simple-ipc.html index 04e0c9dec..5d2e56db2 100644 --- a/technical/api-simple-ipc.html +++ b/technical/api-simple-ipc.html @@ -735,13 +735,13 @@ asciidoc.install(); <body class="article">
<div id="header">
<h1>Simple-IPC API</h1>
-<span id="revdate">2023-10-20</span>
+<span id="revdate">2023-10-23</span>
</div>
<div id="content">
<div id="preamble">
<div class="sectionbody">
<div class="paragraph"><p>The Simple-IPC API is a collection of <code>ipc_</code> prefixed library routines
-and a basic communication protocol that allow an IPC-client process to
+and a basic communication protocol that allows an IPC-client process to
send an application-specific IPC-request message to an IPC-server
process and receive an application-specific IPC-response message.</p></div>
<div class="paragraph"><p>Communication occurs over a named pipe on Windows and a Unix domain
@@ -756,11 +756,11 @@ IPC-server routines then incrementally relay responses back to the IPC-client.</p></div>
<div class="paragraph"><p>The IPC-client routines within a client application process connect
to the IPC-server and send a request message and wait for a response.
-When received, the response is returned back the caller.</p></div>
+When received, the response is returned back to the caller.</p></div>
<div class="paragraph"><p>For example, the <code>fsmonitor--daemon</code> feature will be built as a server
application on top of the IPC-server library routines. It will have
threads watching for file system events and a thread pool waiting for
-client connections. Clients, such as <code>git status</code> will request a list
+client connections. Clients, such as <code>git status</code>, will request a list
of file system events since a point in time and the server will
respond with a list of changed files and directories. The formats of
the request and response are application-specific; the IPC-client and
@@ -772,7 +772,7 @@ IPC-server routines treat them as opaque byte streams.</p></div> <div class="sectionbody">
<div class="paragraph"><p>The Simple-IPC mechanism differs from the existing <code>sub-process.c</code>
model (Documentation/technical/long-running-process-protocol.txt) and
-used by applications like Git-LFS. In the LFS-style sub-process model
+used by applications like Git-LFS. In the LFS-style sub-process model,
the helper is started by the foreground process, communication happens
via a pair of file descriptors bound to the stdin/stdout of the
sub-process, the sub-process only serves the current foreground
@@ -833,7 +833,7 @@ stateless request, receive an application-specific response, and disconnect. It is a one round trip facility for
querying the server. The Simple-IPC routines hide the socket,
named pipe, and thread pool details and allow the application
-layer to focus on the application at hand.</p></div>
+layer to focus on the task at hand.</p></div>
</div>
</div>
</div>
@@ -841,7 +841,7 @@ layer to focus on the application at hand.</p></div> <div id="footer">
<div id="footer-text">
Last updated
- 2022-08-18 14:11:07 PDT
+ 2023-10-23 14:43:46 PDT
</div>
</div>
</body>
diff --git a/technical/api-simple-ipc.txt b/technical/api-simple-ipc.txt index d44ada98e..c4fb152b2 100644 --- a/technical/api-simple-ipc.txt +++ b/technical/api-simple-ipc.txt @@ -2,7 +2,7 @@ Simple-IPC API ============== The Simple-IPC API is a collection of `ipc_` prefixed library routines -and a basic communication protocol that allow an IPC-client process to +and a basic communication protocol that allows an IPC-client process to send an application-specific IPC-request message to an IPC-server process and receive an application-specific IPC-response message. @@ -20,12 +20,12 @@ IPC-client. The IPC-client routines within a client application process connect to the IPC-server and send a request message and wait for a response. -When received, the response is returned back the caller. +When received, the response is returned back to the caller. For example, the `fsmonitor--daemon` feature will be built as a server application on top of the IPC-server library routines. It will have threads watching for file system events and a thread pool waiting for -client connections. Clients, such as `git status` will request a list +client connections. Clients, such as `git status`, will request a list of file system events since a point in time and the server will respond with a list of changed files and directories. The formats of the request and response are application-specific; the IPC-client and @@ -37,7 +37,7 @@ Comparison with sub-process model The Simple-IPC mechanism differs from the existing `sub-process.c` model (Documentation/technical/long-running-process-protocol.txt) and -used by applications like Git-LFS. In the LFS-style sub-process model +used by applications like Git-LFS. In the LFS-style sub-process model, the helper is started by the foreground process, communication happens via a pair of file descriptors bound to the stdin/stdout of the sub-process, the sub-process only serves the current foreground @@ -102,4 +102,4 @@ stateless request, receive an application-specific response, and disconnect. It is a one round trip facility for querying the server. The Simple-IPC routines hide the socket, named pipe, and thread pool details and allow the application -layer to focus on the application at hand. +layer to focus on the task at hand. diff --git a/technical/api-trace2.html b/technical/api-trace2.html index c0b5128e5..8dc54b3bc 100644 --- a/technical/api-trace2.html +++ b/technical/api-trace2.html @@ -735,7 +735,7 @@ asciidoc.install(); <body class="article">
<div id="header">
<h1>Trace2 API</h1>
-<span id="revdate">2023-10-20</span>
+<span id="revdate">2023-10-23</span>
</div>
<div id="content">
<div id="preamble">
diff --git a/technical/bitmap-format.html b/technical/bitmap-format.html index b56808f2e..e8fa24b42 100644 --- a/technical/bitmap-format.html +++ b/technical/bitmap-format.html @@ -735,7 +735,7 @@ asciidoc.install(); <body class="article">
<div id="header">
<h1>GIT bitmap v1 format</h1>
-<span id="revdate">2023-10-20</span>
+<span id="revdate">2023-10-23</span>
</div>
<div id="content">
<div class="sect1">
@@ -944,7 +944,7 @@ result in an empty bitmap (no bits set).</p></div> <p>
N entries with compressed bitmaps, one for each indexed commit
</p>
-<div class="paragraph"><p>Where <code>N</code> is the total amount of entries in this bitmap index.
+<div class="paragraph"><p>Where <code>N</code> is the total number of entries in this bitmap index.
Each entry contains the following:</p></div>
<div class="ulist"><ul>
<li>
@@ -973,7 +973,7 @@ Each entry contains the following:</p></div> <dd>
<p>
The xor offset used to compress this bitmap. For an entry
- in position <code>x</code>, a XOR offset of <code>y</code> means that the actual
+ in position <code>x</code>, an XOR offset of <code>y</code> means that the actual
bitmap representing this commit is composed by XORing the
bitmap for this entry with the bitmap in entry <code>x-y</code> (i.e.
the bitmap <code>y</code> entries before this one).
@@ -1154,7 +1154,7 @@ the desired bitmap from the entries without parsing previous unnecessary bitmaps.</p></div>
<div class="paragraph"><p>For a <code>.bitmap</code> containing <code>nr_entries</code> reachability bitmaps, the table
contains a list of <code>nr_entries</code> <commit_pos, offset, xor_row> triplets
-(sorted in the ascending order of <code>commit_pos</code>). The content of i’th
+(sorted in the ascending order of <code>commit_pos</code>). The content of the i’th
triplet is -</p></div>
<div class="ulist"><ul>
<li>
@@ -1209,7 +1209,7 @@ xor_row (4 byte integer, network byte order): <div id="footer">
<div id="footer-text">
Last updated
- 2022-09-05 18:35:54 PDT
+ 2023-10-23 14:43:46 PDT
</div>
</div>
</body>
diff --git a/technical/bitmap-format.txt b/technical/bitmap-format.txt index c2e652b71..f5d200939 100644 --- a/technical/bitmap-format.txt +++ b/technical/bitmap-format.txt @@ -114,7 +114,7 @@ result in an empty bitmap (no bits set). * N entries with compressed bitmaps, one for each indexed commit + -Where `N` is the total amount of entries in this bitmap index. +Where `N` is the total number of entries in this bitmap index. Each entry contains the following: ** {empty} @@ -126,7 +126,7 @@ Each entry contains the following: ** {empty} 1-byte XOR-offset: :: The xor offset used to compress this bitmap. For an entry - in position `x`, a XOR offset of `y` means that the actual + in position `x`, an XOR offset of `y` means that the actual bitmap representing this commit is composed by XORing the bitmap for this entry with the bitmap in entry `x-y` (i.e. the bitmap `y` entries before this one). @@ -239,7 +239,7 @@ bitmaps. For a `.bitmap` containing `nr_entries` reachability bitmaps, the table contains a list of `nr_entries` <commit_pos, offset, xor_row> triplets -(sorted in the ascending order of `commit_pos`). The content of i'th +(sorted in the ascending order of `commit_pos`). The content of the i'th triplet is - * {empty} diff --git a/technical/bundle-uri.html b/technical/bundle-uri.html index b3cfae0eb..f5b25cd78 100644 --- a/technical/bundle-uri.html +++ b/technical/bundle-uri.html @@ -735,7 +735,7 @@ asciidoc.install(); <body class="article">
<div id="header">
<h1>Bundle URIs</h1>
-<span id="revdate">2023-10-20</span>
+<span id="revdate">2023-10-23</span>
</div>
<div id="content">
<div id="preamble">
diff --git a/technical/commit-graph.txt b/technical/commit-graph.txt index 86fed0de0..2c26e95e5 100644 --- a/technical/commit-graph.txt +++ b/technical/commit-graph.txt @@ -136,7 +136,7 @@ Design Details - Commit grafts and replace objects can change the shape of the commit history. The latter can also be enabled/disabled on the fly using - `--no-replace-objects`. This leads to difficultly storing both possible + `--no-replace-objects`. This leads to difficulty storing both possible interpretations of a commit id, especially when computing generation numbers. The commit-graph will not be read or written when replace-objects or grafts are present. diff --git a/technical/hash-function-transition.html b/technical/hash-function-transition.html index 3e61d6670..4af821f8f 100644 --- a/technical/hash-function-transition.html +++ b/technical/hash-function-transition.html @@ -735,7 +735,7 @@ asciidoc.install(); <body class="article">
<div id="header">
<h1>Git hash function transition</h1>
-<span id="revdate">2023-10-20</span>
+<span id="revdate">2023-10-23</span>
</div>
<div id="content">
<div class="sect1">
diff --git a/technical/long-running-process-protocol.html b/technical/long-running-process-protocol.html index 679d121ad..67cb5c10d 100644 --- a/technical/long-running-process-protocol.html +++ b/technical/long-running-process-protocol.html @@ -735,7 +735,7 @@ asciidoc.install(); <body class="article">
<div id="header">
<h1>Long-running process protocol</h1>
-<span id="revdate">2023-10-20</span>
+<span id="revdate">2023-10-23</span>
</div>
<div id="content">
<div id="preamble">
diff --git a/technical/multi-pack-index.html b/technical/multi-pack-index.html index 0fb666126..0f786b110 100644 --- a/technical/multi-pack-index.html +++ b/technical/multi-pack-index.html @@ -735,7 +735,7 @@ asciidoc.install(); <body class="article">
<div id="header">
<h1>Multi-Pack-Index (MIDX) Design Notes</h1>
-<span id="revdate">2023-10-20</span>
+<span id="revdate">2023-10-23</span>
</div>
<div id="content">
<div id="preamble">
diff --git a/technical/pack-heuristics.html b/technical/pack-heuristics.html index 0bfae5555..b7e390854 100644 --- a/technical/pack-heuristics.html +++ b/technical/pack-heuristics.html @@ -735,7 +735,7 @@ asciidoc.install(); <body class="article">
<div id="header">
<h1>Concerning Git’s Packing Heuristics</h1>
-<span id="revdate">2023-10-20</span>
+<span id="revdate">2023-10-23</span>
</div>
<div id="content">
<div id="preamble">
diff --git a/technical/parallel-checkout.html b/technical/parallel-checkout.html index 549672296..f830cf28e 100644 --- a/technical/parallel-checkout.html +++ b/technical/parallel-checkout.html @@ -735,7 +735,7 @@ asciidoc.install(); <body class="article">
<div id="header">
<h1>Parallel Checkout Design Notes</h1>
-<span id="revdate">2023-10-20</span>
+<span id="revdate">2023-10-23</span>
</div>
<div id="content">
<div id="preamble">
@@ -826,7 +826,7 @@ improvements over the sequential code, but there was still too much lock contention. A <code>perf</code> profiling indicated that around 20% of the runtime
during a local Linux clone (on an SSD) was spent in locking functions.
For this reason this approach was rejected in favor of using multiple
-child processes, which led to a better performance.</p></div>
+child processes, which led to better performance.</p></div>
</div>
</div>
<div class="sect1">
@@ -916,7 +916,7 @@ W5: Writes the result to the file descriptor opened at W2. </li>
<li>
<p>
-W6: Calls <code>fstat()</code> or lstat()` on the just-written path, and sends
+W6: Calls <code>fstat()</code> or <code>lstat()</code> on the just-written path, and sends
the result back to the main process, together with the end status of
the operation and the item’s identification number.
</p>
@@ -939,7 +939,7 @@ information, the main process handles the results in two steps:</p></div> <p>
First, it updates the in-memory index with the <code>lstat()</code> information
sent by the workers. (This must be done first as this information
- might me required in the following step.)
+ might be required in the following step.)
</p>
</li>
<li>
@@ -981,7 +981,7 @@ quite straightforward: for each parallel-eligible entry, the main process must remove all files that prevent this entry from being written
(before enqueueing it). This includes any non-directory file in the
leading path of the entry. Later, when a worker gets assigned the entry,
-it looks again for the non-directories files and for an already existing
+it looks again for the non-directory files and for an already existing
file at the entry’s path. If any of these checks finds something, the
worker knows that there was a path collision.</p></div>
<div class="paragraph"><p>Because parallel checkout can distinguish path collisions from the case
@@ -1032,7 +1032,7 @@ conversion and re-encoding, are eligible for parallel checkout.</p></div> </ul></div>
<div class="paragraph"><p>Ineligible entries are checked out by the classic sequential codepath
<strong>before</strong> spawning workers.</p></div>
-<div class="paragraph"><p>Note: submodules’s files are also eligible for parallel checkout (as
+<div class="paragraph"><p>Note: submodules' files are also eligible for parallel checkout (as
long as they don’t fall into any of the excluding categories mentioned
above). But since each submodule is checked out in its own child
process, we don’t mix the superproject’s and the submodules' files in
@@ -1076,7 +1076,7 @@ err |= run_parallel_checkout(&state, pc_workers, pc_threshold, NULL, NULL);< <div id="footer">
<div id="footer-text">
Last updated
- 2022-11-11 23:55:30 PST
+ 2023-10-23 14:43:46 PDT
</div>
</div>
</body>
diff --git a/technical/parallel-checkout.txt b/technical/parallel-checkout.txt index 47c9b6183..b4a144e5f 100644 --- a/technical/parallel-checkout.txt +++ b/technical/parallel-checkout.txt @@ -63,7 +63,7 @@ improvements over the sequential code, but there was still too much lock contention. A `perf` profiling indicated that around 20% of the runtime during a local Linux clone (on an SSD) was spent in locking functions. For this reason this approach was rejected in favor of using multiple -child processes, which led to a better performance. +child processes, which led to better performance. Multi-Process Solution ---------------------- @@ -126,7 +126,7 @@ Then, for each assigned item, each worker: * W5: Writes the result to the file descriptor opened at W2. -* W6: Calls `fstat()` or lstat()` on the just-written path, and sends +* W6: Calls `fstat()` or `lstat()` on the just-written path, and sends the result back to the main process, together with the end status of the operation and the item's identification number. @@ -148,7 +148,7 @@ information, the main process handles the results in two steps: - First, it updates the in-memory index with the `lstat()` information sent by the workers. (This must be done first as this information - might me required in the following step.) + might be required in the following step.) - Then it writes the items which collided on disk (i.e. items marked with `PC_ITEM_COLLIDED`). More on this below. @@ -185,7 +185,7 @@ quite straightforward: for each parallel-eligible entry, the main process must remove all files that prevent this entry from being written (before enqueueing it). This includes any non-directory file in the leading path of the entry. Later, when a worker gets assigned the entry, -it looks again for the non-directories files and for an already existing +it looks again for the non-directory files and for an already existing file at the entry's path. If any of these checks finds something, the worker knows that there was a path collision. @@ -232,7 +232,7 @@ conversion and re-encoding, are eligible for parallel checkout. Ineligible entries are checked out by the classic sequential codepath *before* spawning workers. -Note: submodules's files are also eligible for parallel checkout (as +Note: submodules' files are also eligible for parallel checkout (as long as they don't fall into any of the excluding categories mentioned above). But since each submodule is checked out in its own child process, we don't mix the superproject's and the submodules' files in diff --git a/technical/partial-clone.html b/technical/partial-clone.html index 728b1998d..2d454599a 100644 --- a/technical/partial-clone.html +++ b/technical/partial-clone.html @@ -735,14 +735,14 @@ asciidoc.install(); <body class="article">
<div id="header">
<h1>Partial Clone Design Notes</h1>
-<span id="revdate">2023-10-20</span>
+<span id="revdate">2023-10-23</span>
</div>
<div id="content">
<div id="preamble">
<div class="sectionbody">
<div class="paragraph"><p>The "Partial Clone" feature is a performance optimization for Git that
allows Git to function without having a complete copy of the repository.
-The goal of this work is to allow Git better handle extremely large
+The goal of this work is to allow Git to better handle extremely large
repositories.</p></div>
<div class="paragraph"><p>During clone and fetch operations, Git downloads the complete contents
and history of the repository. This includes all commits, trees, and
@@ -1083,7 +1083,7 @@ Dynamic object fetching invokes fetch-pack once <strong>for each item</strong> Dynamic object fetching currently uses the existing pack protocol V0
which means that each object is requested via fetch-pack. The server
will send a full set of info/refs when the connection is established.
- If there are large number of refs, this may incur significant overhead.
+ If there are a large number of refs, this may incur significant overhead.
</p>
</li>
</ul></div>
@@ -1098,7 +1098,7 @@ Dynamic object fetching currently uses the existing pack protocol V0 Improve the way to specify the order in which promisor remotes are
tried.
</p>
-<div class="paragraph"><p>For example this could allow to specify explicitly something like:
+<div class="paragraph"><p>For example this could allow specifying explicitly something like:
"When fetching from this remote, I want to use these promisor remotes
in this order, though, when pushing or fetching to that remote, I want
to use those promisor remotes in that order."</p></div>
@@ -1172,7 +1172,7 @@ for a dynamic object fetch), but we are not building on that.</p></div> <div class="sectionbody">
<div class="paragraph"><p>[a] expensive-to-modify list of missing objects: Earlier in the design of
partial clone we discussed the need for a single list of missing objects.
- This would essentially be a sorted linear list of OIDs that the were
+ This would essentially be a sorted linear list of OIDs that were
omitted by the server during a clone or subsequent fetches.</p></div>
<div class="paragraph"><p>This file would need to be loaded into memory on every object lookup.
It would need to be read, updated, and re-written (like the .git/index)
@@ -1214,7 +1214,7 @@ type of packfile that references it.</p></div> <div id="footer">
<div id="footer-text">
Last updated
- 2022-08-18 14:11:07 PDT
+ 2023-10-23 14:43:46 PDT
</div>
</div>
</body>
diff --git a/technical/partial-clone.txt b/technical/partial-clone.txt index 92fcee2bf..cd948b007 100644 --- a/technical/partial-clone.txt +++ b/technical/partial-clone.txt @@ -3,7 +3,7 @@ Partial Clone Design Notes The "Partial Clone" feature is a performance optimization for Git that allows Git to function without having a complete copy of the repository. -The goal of this work is to allow Git better handle extremely large +The goal of this work is to allow Git to better handle extremely large repositories. During clone and fetch operations, Git downloads the complete contents @@ -256,7 +256,7 @@ remote in a specific order. - Dynamic object fetching currently uses the existing pack protocol V0 which means that each object is requested via fetch-pack. The server will send a full set of info/refs when the connection is established. - If there are large number of refs, this may incur significant overhead. + If there are a large number of refs, this may incur significant overhead. Future Work @@ -265,7 +265,7 @@ Future Work - Improve the way to specify the order in which promisor remotes are tried. + -For example this could allow to specify explicitly something like: +For example this could allow specifying explicitly something like: "When fetching from this remote, I want to use these promisor remotes in this order, though, when pushing or fetching to that remote, I want to use those promisor remotes in that order." @@ -322,7 +322,7 @@ Footnotes [a] expensive-to-modify list of missing objects: Earlier in the design of partial clone we discussed the need for a single list of missing objects. - This would essentially be a sorted linear list of OIDs that the were + This would essentially be a sorted linear list of OIDs that were omitted by the server during a clone or subsequent fetches. This file would need to be loaded into memory on every object lookup. diff --git a/technical/racy-git.html b/technical/racy-git.html index d2a7193b9..50b13cfaa 100644 --- a/technical/racy-git.html +++ b/technical/racy-git.html @@ -735,7 +735,7 @@ asciidoc.install(); <body class="article">
<div id="header">
<h1>Use of index and Racy Git problem</h1>
-<span id="revdate">2023-10-20</span>
+<span id="revdate">2023-10-23</span>
</div>
<div id="content">
<div class="sect1">
@@ -747,7 +747,7 @@ paths and their object names and serves as a staging area to write out the next tree object to be committed. The state is
"virtual" in the sense that it does not necessarily have to, and
often does not, match the files in the working tree.</p></div>
-<div class="paragraph"><p>There are cases Git needs to examine the differences between the
+<div class="paragraph"><p>There are cases where Git needs to examine the differences between the
virtual working tree state in the index and the files in the
working tree. The most obvious case is when the user asks <code>git
diff</code> (or its low level implementation, <code>git diff-files</code>) or
@@ -908,9 +908,9 @@ of the cached stat information.</p></div> <div class="sectionbody">
<div class="paragraph"><p>In order to avoid the above runtime penalty, post 1.4.2 Git used
to have a code that made sure the index file
-got timestamp newer than the youngest files in the index when
-there are many young files with the same timestamp as the
-resulting index file would otherwise would have by waiting
+got a timestamp newer than the youngest files in the index when
+there were many young files with the same timestamp as the
+resulting index file otherwise would have by waiting
before finishing writing the index file out.</p></div>
<div class="paragraph"><p>I suspected that in practice the situation where many paths in the
index are all racily clean was quite rare. The only code paths
@@ -938,7 +938,7 @@ out can become racily clean.</p></div> however, the initial computation of all object names in the
index takes more than one second, and the index file is written
out after all that happens. Therefore the timestamp of the
-index file will be more than one seconds later than the
+index file will be more than one second later than the
youngest file in the working tree. This means that in these
cases there actually will not be any racily clean entry in
the resulting index.</p></div>
@@ -953,7 +953,7 @@ practice anymore. This was done with commit 0fc82cff on Aug 15, <div id="footer">
<div id="footer-text">
Last updated
- 2020-03-10 15:02:33 PDT
+ 2023-10-23 14:43:46 PDT
</div>
</div>
</body>
diff --git a/technical/racy-git.txt b/technical/racy-git.txt index ceda4bbfd..59bea66c0 100644 --- a/technical/racy-git.txt +++ b/technical/racy-git.txt @@ -11,7 +11,7 @@ write out the next tree object to be committed. The state is "virtual" in the sense that it does not necessarily have to, and often does not, match the files in the working tree. -There are cases Git needs to examine the differences between the +There are cases where Git needs to examine the differences between the virtual working tree state in the index and the files in the working tree. The most obvious case is when the user asks `git diff` (or its low level implementation, `git diff-files`) or @@ -165,9 +165,9 @@ Avoiding runtime penalty In order to avoid the above runtime penalty, post 1.4.2 Git used to have a code that made sure the index file -got timestamp newer than the youngest files in the index when -there are many young files with the same timestamp as the -resulting index file would otherwise would have by waiting +got a timestamp newer than the youngest files in the index when +there were many young files with the same timestamp as the +resulting index file otherwise would have by waiting before finishing writing the index file out. I suspected that in practice the situation where many paths in the @@ -190,7 +190,7 @@ In a large project where raciness avoidance cost really matters, however, the initial computation of all object names in the index takes more than one second, and the index file is written out after all that happens. Therefore the timestamp of the -index file will be more than one seconds later than the +index file will be more than one second later than the youngest file in the working tree. This means that in these cases there actually will not be any racily clean entry in the resulting index. diff --git a/technical/reftable.html b/technical/reftable.html index 16c612f24..d226a686c 100644 --- a/technical/reftable.html +++ b/technical/reftable.html @@ -802,7 +802,7 @@ reference storage. References are sorted, enabling linear scans, binary search lookup, and range scans.</p></div>
<div class="paragraph"><p>Storage in the file is organized into variable sized blocks. Prefix
compression is used within a single block to reduce disk space. Block
-size and alignment is tunable by the writer.</p></div>
+size and alignment are tunable by the writer.</p></div>
</div>
<div class="sect3">
<h4 id="_performance">Performance</h4>
@@ -974,7 +974,7 @@ to. This is analogous to storage in the packed-refs format.</p></div> <h4 id="_varint_encoding">Varint encoding</h4>
<div class="paragraph"><p>Varint encoding is identical to the ofs-delta encoding method used
within pack files.</p></div>
-<div class="paragraph"><p>Decoder works such as:</p></div>
+<div class="paragraph"><p>Decoder works as follows:</p></div>
<div class="literalblock">
<div class="content">
<pre><code>val = buf[ptr] & 0x7f
@@ -1028,7 +1028,7 @@ log_block* log_index*
footer</code></pre>
</div></div>
-<div class="paragraph"><p>in a log-only file the first log block immediately follows the file
+<div class="paragraph"><p>In a log-only file, the first log block immediately follows the file
header, without padding to block alignment.</p></div>
</div>
<div class="sect3">
@@ -1089,7 +1089,7 @@ uint64( max_update_index ) uint32( hash_id )</code></pre>
</div></div>
<div class="paragraph"><p>The header is identical to <code>version_number=1</code>, with the 4-byte hash ID
-("sha1" for SHA1 and "s256" for SHA-256) append to the header.</p></div>
+("sha1" for SHA1 and "s256" for SHA-256) appended to the header.</p></div>
<div class="paragraph"><p>For maximum backward compatibility, it is recommended to use version 1 when
writing SHA1 reftables.</p></div>
</div>
@@ -1123,7 +1123,7 @@ the file header.</p></div> <code>restart_offset</code> list, which must not be empty. Readers can use
<code>restart_count</code> to binary search between restarts before starting a
linear scan.</p></div>
-<div class="paragraph"><p>Exactly <code>restart_count</code> 3-byte <code>restart_offset</code> values precedes the
+<div class="paragraph"><p>Exactly <code>restart_count</code> 3-byte <code>restart_offset</code> values precede the
<code>restart_count</code>. Offsets are relative to the start of the block and
refer to the first byte of any <code>ref_record</code> whose name has not been
prefix compressed. Entries in the <code>restart_offset</code> list must be sorted,
@@ -2056,7 +2056,7 @@ impossible.</p></div> <div id="footer">
<div id="footer-text">
Last updated
- 2022-03-09 14:17:38 PST
+ 2023-10-23 14:43:46 PDT
</div>
</div>
</body>
diff --git a/technical/reftable.txt b/technical/reftable.txt index 6a67cc417..dd0b37c4e 100644 --- a/technical/reftable.txt +++ b/technical/reftable.txt @@ -46,7 +46,7 @@ search lookup, and range scans. Storage in the file is organized into variable sized blocks. Prefix compression is used within a single block to reduce disk space. Block -size and alignment is tunable by the writer. +size and alignment are tunable by the writer. Performance ^^^^^^^^^^^ @@ -115,7 +115,7 @@ Varint encoding Varint encoding is identical to the ofs-delta encoding method used within pack files. -Decoder works such as: +Decoder works as follows: .... val = buf[ptr] & 0x7f @@ -175,7 +175,7 @@ log_index* footer .... -in a log-only file the first log block immediately follows the file +In a log-only file, the first log block immediately follows the file header, without padding to block alignment. Block size @@ -247,7 +247,7 @@ uint32( hash_id ) .... The header is identical to `version_number=1`, with the 4-byte hash ID -("sha1" for SHA1 and "s256" for SHA-256) append to the header. +("sha1" for SHA1 and "s256" for SHA-256) appended to the header. For maximum backward compatibility, it is recommended to use version 1 when writing SHA1 reftables. @@ -288,7 +288,7 @@ The 2-byte `restart_count` stores the number of entries in the `restart_count` to binary search between restarts before starting a linear scan. -Exactly `restart_count` 3-byte `restart_offset` values precedes the +Exactly `restart_count` 3-byte `restart_offset` values precede the `restart_count`. Offsets are relative to the start of the block and refer to the first byte of any `ref_record` whose name has not been prefix compressed. Entries in the `restart_offset` list must be sorted, diff --git a/technical/repository-version.txt b/technical/repository-version.txt index 8ef664b0b..045a76756 100644 --- a/technical/repository-version.txt +++ b/technical/repository-version.txt @@ -96,7 +96,7 @@ The value of this key is the name of the promisor remote. ==== `worktreeConfig` If set, by default "git config" reads from both "config" and -"config.worktree" file from GIT_DIR in that order. In +"config.worktree" files from GIT_DIR in that order. In multiple working directory mode, "config" file is shared while "config.worktree" is per-working directory (i.e., it's in GIT_COMMON_DIR/worktrees/<id>/config.worktree) diff --git a/technical/rerere.txt b/technical/rerere.txt index be58f1bee..580f23360 100644 --- a/technical/rerere.txt +++ b/technical/rerere.txt @@ -60,7 +60,7 @@ By resolving this conflict, to leave line D, the user declares: what AB and AC wanted to do. As branch AC2 refers to the same commit as AC, the above implies that -this is also compatible what AB and AC2 wanted to do. +this is also compatible with what AB and AC2 wanted to do. By extension, this means that rerere should recognize that the above conflicts are the same. To do this, the labels on the conflict @@ -76,7 +76,7 @@ examples would both result in the following normalized conflict: Sorting hunks ~~~~~~~~~~~~~ -As before, lets imagine that a common ancestor had a file with line A +As before, let's imagine that a common ancestor had a file with line A its early part, and line X in its late part. And then four branches are forked that do these things: @@ -145,7 +145,7 @@ Nested conflicts Nested conflicts are handled very similarly to "simple" conflicts. Similar to simple conflicts, the conflict is first normalized by stripping the labels from conflict markers, stripping the common ancestor -version, and the sorting the conflict hunks, both for the outer and the +version, and sorting the conflict hunks, both for the outer and the inner conflict. This is done recursively, so any number of nested conflicts can be handled. diff --git a/technical/scalar.html b/technical/scalar.html index 11fab097e..b5ec55e9c 100644 --- a/technical/scalar.html +++ b/technical/scalar.html @@ -735,7 +735,7 @@ asciidoc.install(); <body class="article">
<div id="header">
<h1>Scalar</h1>
-<span id="revdate">2023-10-20</span>
+<span id="revdate">2023-10-23</span>
</div>
<div id="content">
<div id="preamble">
diff --git a/technical/send-pack-pipeline.html b/technical/send-pack-pipeline.html index 2ab7ba8ca..51bd9c198 100644 --- a/technical/send-pack-pipeline.html +++ b/technical/send-pack-pipeline.html @@ -735,7 +735,7 @@ asciidoc.install(); <body class="article">
<div id="header">
<h1>Git-send-pack internals</h1>
-<span id="revdate">2023-10-20</span>
+<span id="revdate">2023-10-23</span>
</div>
<div id="content">
<div class="sect1">
diff --git a/technical/shallow.html b/technical/shallow.html index 35b1c67be..2e975c966 100644 --- a/technical/shallow.html +++ b/technical/shallow.html @@ -735,7 +735,7 @@ asciidoc.install(); <body class="article">
<div id="header">
<h1>Shallow commits</h1>
-<span id="revdate">2023-10-20</span>
+<span id="revdate">2023-10-23</span>
</div>
<div id="content">
<div id="preamble">
diff --git a/technical/trivial-merge.html b/technical/trivial-merge.html index 2adb6b979..10cfc7b89 100644 --- a/technical/trivial-merge.html +++ b/technical/trivial-merge.html @@ -735,7 +735,7 @@ asciidoc.install(); <body class="article">
<div id="header">
<h1>Trivial merge rules</h1>
-<span id="revdate">2023-10-20</span>
+<span id="revdate">2023-10-23</span>
</div>
<div id="content">
<div id="preamble">
|