|author||Mike Gerwitz <firstname.lastname@example.org>||2016-05-28 20:36:31 -0400|
|committer||Mike Gerwitz <email@example.com>||2016-05-28 20:36:31 -0400|
:Git Horror Story s/fourth/forth/
Thanks to Thien-Thi Nguyen <firstname.lastname@example.org> for pointing this out.
1 files changed, 3 insertions, 3 deletions
diff --git a/docs/papers/git-horror-story.txt b/docs/papers/git-horror-story.txt
index ebb998b..2731cbf 100644
@@ -704,7 +704,7 @@ Commit History In a Nutshell
The SHA-1 hashes of each commit in Git are created using the delta _and_ header
information for each commit. This header information includes the commit's
-_parent_, whose header contains its parent---so on and so fourth. In addition,
+_parent_, whose header contains its parent---so on and so forth. In addition,
Git depends on the entire history of the repository leading up to a given commit
to construct the requested revision. Consequently, this means that the history
cannot be altered without someone noticing (well, this is not entirely true;
@@ -738,7 +738,7 @@ to change the expected hash in commit +B+, because the header is used to
generate the SHA-1 hash for the commit, meaning +B+ would then have a different
SHA-1 hash (technically speaking, it would not longer be +B+---it would be an
entirely different commit; we retain the identifier here only for demonstration
-purposes). That would then invalidate any children of +B+, so on and so fourth.
+purposes). That would then invalidate any children of +B+, so on and so forth.
Therefore, in order to rewrite the history for a single commit, _the entire
history after that commit must also be rewritten_ (as is done by `git rebase`).
Should that be done, the SHA-1 hash of +H+ would also need to change. Otherwise,
@@ -1140,7 +1140,7 @@ server or whatever user is being used to perform the signature checks.
Automating Merge Signature Checks
The aforementioned scripts are excellent if you wish to check the validity of
-each individual commit, but not everyone will wish to put fourth that amount of
+each individual commit, but not everyone will wish to put forth that amount of
effort. Instead, maintainers may opt for a workflow that requires the signing
of only the merge commit (xref:merge-2[option #2 above]), rather than each
commit that is introduced by the merge. Let us consider the appropach we would