From 4b75b82b4e67a27a163a5daa405821bcadee57f6 Mon Sep 17 00:00:00 2001 From: Mike Gerwitz Date: Sat, 28 May 2016 20:36:31 -0400 Subject: [PATCH] :Git Horror Story s/fourth/forth/ Thanks to Thien-Thi Nguyen for pointing this out. --- docs/papers/git-horror-story.txt | 6 +++--- 1 file 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 --- a/docs/papers/git-horror-story.txt +++ b/docs/papers/git-horror-story.txt @@ -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