:Git Horror Story s/fourth/forth/

Thanks to Thien-Thi Nguyen <ttn@gnu.org> for pointing this out.
master
Mike Gerwitz 2016-05-28 20:36:31 -04:00
parent 9858f6112c
commit 4b75b82b4e
No known key found for this signature in database
GPG Key ID: F22BB8158EE30EAB
1 changed files with 3 additions and 3 deletions

View File

@ -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