{"thread":{"id":"4476","subject":"[PATCH] The hash name is SHA-1, use that throughout","startedAt":"2006-06-12T02:04:18Z","lastAt":"2006-06-12T02:04:19Z","messageCount":2,"participants":["Horst H. von Brand"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"21623","messageId":"11500778593947-git-send-email-vonbrand@inf.utfsm.cl","threadId":"4476","inReplyTo":null,"subject":"[PATCH] The name of the hash is SHA-1, use that throughout","fromName":"Horst H. von Brand","fromEmail":"vonbrand@inf.utfsm.cl","sentAt":"2006-06-12T02:04:18Z","receivedAt":"2006-06-12T02:04:18Z","isPatch":true,"sender":{"key":"vonbrand@inf.utfsm.cl","avatar":"https://avatars.githubusercontent.com/u/211384?v=4"},"body":"Signed-off-by: Horst H. von Brand <vonbrand@inf.utfsm.cl>\n---\n Documentation/config.txt           |    2 +-\n Documentation/core-tutorial.txt    |    8 ++++----\n Documentation/diff-format.txt      |    8 ++++----\n Documentation/diffcore.txt         |    2 +-\n Documentation/git-branch.txt       |    2 +-\n Documentation/git-cat-file.txt     |    2 +-\n Documentation/git-checkout.txt     |    2 +-\n Documentation/git-cherry.txt       |    2 +-\n Documentation/git-diff-index.txt   |    8 ++++----\n Documentation/git-fsck-objects.txt |    8 ++++----\n Documentation/git-init-db.txt      |    2 +-\n Documentation/git-ls-files.txt     |    2 +-\n Documentation/git-merge-index.txt  |    2 +-\n Documentation/git-mktag.txt        |    2 +-\n Documentation/git-pack-objects.txt |    2 +-\n Documentation/git-push.txt         |    2 +-\n Documentation/git-rev-parse.txt    |    8 ++++----\n Documentation/git-show-branch.txt  |    4 ++--\n Documentation/git-unpack-file.txt  |    2 +-\n Documentation/git-update-index.txt |    2 +-\n Documentation/git-verify-pack.txt  |    4 ++--\n Documentation/git-verify-tag.txt   |    2 +-\n Documentation/git.txt              |    2 +-\n Documentation/glossary.txt         |    6 +++---\n Documentation/tutorial-2.txt       |   14 +++++++-------\n 25 files changed, 50 insertions(+), 50 deletions(-)\n\ndiff --git a/Documentation/config.txt b/Documentation/config.txt\nindex bb93dc5..4195713 100644\n--- a/Documentation/config.txt\n+++ b/Documentation/config.txt\n@@ -72,7 +72,7 @@ core.preferSymlinkRefs::\n \n core.logAllRefUpdates::\n \tIf true, `git-update-ref` will append a line to\n-\t\"$GIT_DIR/logs/<ref>\" listing the new SHA1 and the date/time\n+\t\"$GIT_DIR/logs/<ref>\" listing the new SHA-1 and the date/time\n \tof the update.\tIf the file does not exist it will be\n \tcreated automatically.\tThis information can be used to\n \tdetermine what commit was the tip of a branch \"2 days ago\".\ndiff --git a/Documentation/core-tutorial.txt b/Documentation/core-tutorial.txt\nindex b59153e..59f86ee 100644\n--- a/Documentation/core-tutorial.txt\n+++ b/Documentation/core-tutorial.txt\n@@ -100,9 +100,9 @@ branch. A number of the git tools will a\n valid, though.\n \n [NOTE]\n-An 'object' is identified by its 160-bit SHA1 hash, aka 'object name',\n+An 'object' is identified by its 160-bit SHA-1 hash, aka 'object name',\n and a reference to an object is always the 40-byte hex\n-representation of that SHA1 name. The files in the `refs`\n+representation of that SHA-1 name. The files in the `refs`\n subdirectory are expected to contain these hex references\n (usually with a final `\\'\\n\\'` at the end), and you should thus\n expect to see a number of 41-byte files containing these\n@@ -772,7 +772,7 @@ already discussed, the `HEAD` branch is \n these object pointers. \n \n You can at any time create a new branch by just picking an arbitrary\n-point in the project history, and just writing the SHA1 name of that\n+point in the project history, and just writing the SHA-1 name of that\n object into a file under `.git/refs/heads/`. You can use any filename you\n want (and indeed, subdirectories), but the convention is that the\n \"normal\" branch is called `master`. That's just a convention, though,\n@@ -1260,7 +1260,7 @@ file (the first tree goes to stage 1, th\n etc.).  After reading three trees into three stages, the paths\n that are the same in all three stages are 'collapsed' into stage\n 0.  Also paths that are the same in two of three stages are\n-collapsed into stage 0, taking the SHA1 from either stage 2 or\n+collapsed into stage 0, taking the SHA-1 from either stage 2 or\n stage 3, whichever is different from stage 1 (i.e. only one side\n changed from the common ancestor).\n \ndiff --git a/Documentation/diff-format.txt b/Documentation/diff-format.txt\nindex 89607c8..859e527 100644\n--- a/Documentation/diff-format.txt\n+++ b/Documentation/diff-format.txt\n@@ -35,9 +35,9 @@ That is, from the left to the right:\n . a space.\n . mode for \"dst\"; 000000 if deletion or unmerged.\n . a space.\n-. sha1 for \"src\"; 0\\{40\\} if creation or unmerged.\n+. SHA-1 for \"src\"; 0\\{40\\} if creation or unmerged.\n . a space.\n-. sha1 for \"dst\"; 0\\{40\\} if creation, unmerged or \"look at work tree\".\n+. SHA-1 for \"dst\"; 0\\{40\\} if creation, unmerged or \"look at work tree\".\n . a space.\n . status, followed by optional \"score\" number.\n . a tab or a NUL when `-z` option is used.\n@@ -46,7 +46,7 @@ That is, from the left to the right:\n . path for \"dst\"; only exists for C or R.\n . an LF or a NUL when `-z` option is used, to terminate the record.\n \n-<sha1> is shown as all 0's if a file is new on the filesystem\n+<SHA-1> is shown as all 0's if a file is new on the filesystem\n and it is out of sync with the index.\n \n Example:\n@@ -97,7 +97,7 @@ where:\n \n      <old|new>-file:: are files GIT_EXTERNAL_DIFF can use to read the\n \t\t      contents of <old|new>,\n-     <old|new>-hex:: are the 40-hexdigit SHA1 hashes,\n+     <old|new>-hex:: are the 40-hexdigit SHA-1 hashes,\n      <old|new>-mode:: are the octal representation of the file modes.\n \n + \ndiff --git a/Documentation/diffcore.txt b/Documentation/diffcore.txt\nindex 5492669..2d45ea0 100644\n--- a/Documentation/diffcore.txt\n+++ b/Documentation/diffcore.txt\n@@ -115,7 +115,7 @@ it changes it to:\n For the purpose of breaking a filepair, `diffcore-break` examines\n the extent of changes between the contents of the files before\n and after modification (i.e. the contents that have \"bcd1234...\"\n-and \"0123456...\" as their SHA1 content ID, in the above\n+and \"0123456...\" as their SHA-1 content ID, in the above\n example).  The amount of deletion of original contents and\n insertion of new material are added together, and if it exceeds\n the \"break score\", the filepair is broken into two.  The break\ndiff --git a/Documentation/git-branch.txt b/Documentation/git-branch.txt\nindex 29b102d..36100c0 100644\n--- a/Documentation/git-branch.txt\n+++ b/Documentation/git-branch.txt\n@@ -38,7 +38,7 @@ OPTIONS\n -l::\n \tCreate the branch's ref log.  This activates recording of\n \tall changes to made the branch ref, enabling use of date\n-\tbased sha1 expressions such as \"<branchname>@{yesterday}\".\n+\tbased SHA-1 expressions such as \"<branchname>@{yesterday}\".\n \n -f::\n \tForce the creation of a new branch even if it means deleting\ndiff --git a/Documentation/git-cat-file.txt b/Documentation/git-cat-file.txt\nindex 85fb9ae..760d4b3 100644\n--- a/Documentation/git-cat-file.txt\n+++ b/Documentation/git-cat-file.txt\n@@ -19,7 +19,7 @@ or `-s` is used to find the object size.\n OPTIONS\n -------\n <object>::\n-\tThe sha1 identifier of the object.\n+\tThe SHA-1 identifier of the object.\n \n -t::\n \tInstead of the content, show the object type identified by\ndiff --git a/Documentation/git-checkout.txt b/Documentation/git-checkout.txt\nindex 90fc318..9b6c719 100644\n--- a/Documentation/git-checkout.txt\n+++ b/Documentation/git-checkout.txt\n@@ -43,7 +43,7 @@ OPTIONS\n -l::\n \tCreate the new branch's ref log.  This activates recording of\n \tall changes to made the branch ref, enabling use of date\n-\tbased sha1 expressions such as \"<branchname>@{yesterday}\".\n+\tbased SHA-1 expressions such as \"<branchname>@{yesterday}\".\n \n -m::\n \tIf you have local modifications to one or more files that\ndiff --git a/Documentation/git-cherry.txt b/Documentation/git-cherry.txt\nindex cccb781..35f11cd 100644\n--- a/Documentation/git-cherry.txt\n+++ b/Documentation/git-cherry.txt\n@@ -15,7 +15,7 @@ The changeset (or \"diff\") of each commit\n is compared against each commit between the fork-point and <upstream>.\n \n Every commit with a changeset that doesn't exist in the other branch\n-has its id (sha1) reported, prefixed by a symbol.  Those existing only\n+has its id (SHA-1) reported, prefixed by a symbol.  Those existing only\n in the <upstream> branch are prefixed with a minus (-) sign, and those\n that only exist in the <head> branch are prefixed with a plus (+) symbol.\n \ndiff --git a/Documentation/git-diff-index.txt b/Documentation/git-diff-index.txt\nindex 39d3b99..cdace11 100644\n--- a/Documentation/git-diff-index.txt\n+++ b/Documentation/git-diff-index.txt\n@@ -93,7 +93,7 @@ you *could* commit. Again, the output ma\n output to a tee, but with a twist.\n \n The twist is that if some file doesn't match the index, we don't have\n-a backing store thing for it, and we use the magic \"all-zero\" sha1 to\n+a backing store thing for it, and we use the magic \"all-zero\" SHA-1 to\n show that. So let's say that you have edited `kernel/sched.c`, but\n have not actually done a `git update-index` on it yet - there is no\n \"object\" associated with the new state, and you get:\n@@ -102,7 +102,7 @@ have not actually done a `git update-ind\n   *100644->100664 blob    7476bb......->000000......      kernel/sched.c\n \n i.e., it shows that the tree has changed, and that `kernel/sched.c` has is\n-not up-to-date and may contain new stuff. The all-zero sha1 means that to\n+not up-to-date and may contain new stuff. The all-zero SHA-1 means that to\n get the real diff, you need to look at the object in the working directory\n directly rather than do an object-to-object diff.\n \n@@ -115,8 +115,8 @@ touched it. In either case, it's a note \n NOTE: You can have a mixture of files show up as \"has been updated\"\n and \"is still dirty in the working directory\" together. You can always\n tell which file is in which state, since the \"has been updated\" ones\n-show a valid sha1, and the \"not in sync with the index\" ones will\n-always have the special all-zero sha1.\n+show a valid SHA-1, and the \"not in sync with the index\" ones will\n+always have the special all-zero SHA-1.\n \n \n Author\ndiff --git a/Documentation/git-fsck-objects.txt b/Documentation/git-fsck-objects.txt\nindex e842bfd..1413f77 100644\n--- a/Documentation/git-fsck-objects.txt\n+++ b/Documentation/git-fsck-objects.txt\n@@ -22,7 +22,7 @@ OPTIONS\n \tAn object to treat as the head of an unreachability trace.\n +\n If no objects are given, git-fsck-objects defaults to using the\n-index file and all SHA1 references in .git/refs/* as heads.\n+index file and all SHA-1 references in .git/refs/* as heads.\n \n --unreachable::\n \tPrint out objects that exist but that aren't readable from any\n@@ -55,7 +55,7 @@ index file and all SHA1 references in .g\n \tobjects that triggers this check, but it is recommended\n \tto check new projects with this flag.\n \n-It tests SHA1 and general object sanity, and it does full tracking of\n+It tests SHA-1 and general object sanity, and it does full tracking of\n the resulting reachability and everything else. It prints out any\n corruption it finds (missing or bad objects), and if you use the\n `--unreachable` flag it will also print out objects that exist but\n@@ -87,7 +87,7 @@ expect dangling commits - potential head\n \troot nodes.\n \n missing sha1 directory '<dir>'::\n-\tThe directory holding the sha1 objects is missing.\n+\tThe directory holding the SHA-1 objects is missing.\n \n unreachable <type> <object>::\n \tThe <type> object <object>, isn't actually referred to directly\n@@ -109,7 +109,7 @@ warning: git-fsck-objects: tree <tree> h\n \tAnd it shouldn't...\n \n sha1 mismatch <object>::\n-\tThe database has an object who's sha1 doesn't match the\n+\tThe database has an object who's SHA-1 doesn't match the\n \tdatabase value.\n \tThis indicates a serious data integrity problem.\n \ndiff --git a/Documentation/git-init-db.txt b/Documentation/git-init-db.txt\nindex 6e32f88..7f83f7e 100644\n--- a/Documentation/git-init-db.txt\n+++ b/Documentation/git-init-db.txt\n@@ -39,7 +39,7 @@ If the `$GIT_DIR` environment variable i\n to use instead of `./.git` for the base of the repository.\n \n If the object storage directory is specified via the `$GIT_OBJECT_DIRECTORY`\n-environment variable then the sha1 directories are created underneath -\n+environment variable then the SHA-1 directories are created underneath -\n otherwise the default `$GIT_DIR/objects` directory is used.\n \n A shared repository allows users belonging to the same group to push into that\ndiff --git a/Documentation/git-ls-files.txt b/Documentation/git-ls-files.txt\nindex 7567323..4bb0f5f 100644\n--- a/Documentation/git-ls-files.txt\n+++ b/Documentation/git-ls-files.txt\n@@ -123,7 +123,7 @@ which case it outputs:\n \"git-ls-files --unmerged\" and \"git-ls-files --stage\" can be used to examine\n detailed information on unmerged paths.\n \n-For an unmerged path, instead of recording a single mode/SHA1 pair,\n+For an unmerged path, instead of recording a single mode/SHA-1 pair,\n the dircache records up to three such pairs; one from tree O in stage\n 1, A in stage 2, and B in stage 3.  This information can be used by\n the user (or the porcelain) to see what should eventually be recorded at the\ndiff --git a/Documentation/git-merge-index.txt b/Documentation/git-merge-index.txt\nindex af79688..7348682 100644\n--- a/Documentation/git-merge-index.txt\n+++ b/Documentation/git-merge-index.txt\n@@ -13,7 +13,7 @@ SYNOPSIS\n DESCRIPTION\n -----------\n This looks up the <file>(s) in the index and, if there are any merge\n-entries, passes the SHA1 hash for those files as arguments 1, 2, 3 (empty\n+entries, passes the SHA-1 hash for those files as arguments 1, 2, 3 (empty\n argument if no file), and <file> as argument 4.  File modes for the three\n files are passed as arguments 5, 6 and 7.\n \ndiff --git a/Documentation/git-mktag.txt b/Documentation/git-mktag.txt\nindex ca0f48a..26b2a6e 100644\n--- a/Documentation/git-mktag.txt\n+++ b/Documentation/git-mktag.txt\n@@ -21,7 +21,7 @@ Tag Format\n ----------\n A tag signature file has a very simple fixed format: three lines of\n \n-  object <sha1>\n+  object <SHA-1>\n   type <typename>\n   tag <tagname>\n \ndiff --git a/Documentation/git-pack-objects.txt b/Documentation/git-pack-objects.txt\nindex d968afe..bbe2afa 100644\n--- a/Documentation/git-pack-objects.txt\n+++ b/Documentation/git-pack-objects.txt\n@@ -46,7 +46,7 @@ base-name::\n \tWrite into a pair of files (.pack and .idx), using\n \t<base-name> to determine the name of the created file.\n \tWhen this option is used, the two files are written in\n-\t<base-name>-<SHA1>.{pack,idx} files.  <SHA1> is a hash\n+\t<base-name>-<SHA-1>.{pack,idx} files.  <SHA-1> is a hash\n \tof object names (currently in random order so it does\n \tnot have any useful meaning) to make the resulting\n \tfilename reasonably unique, and written to the standard\ndiff --git a/Documentation/git-push.txt b/Documentation/git-push.txt\nindex 52be715..b299045 100644\n--- a/Documentation/git-push.txt\n+++ b/Documentation/git-push.txt\n@@ -34,7 +34,7 @@ OPTIONS\n \tthe destination ref.\n +\n The <src> side can be an\n-arbitrary \"SHA1 expression\" that can be used as an\n+arbitrary \"SHA-1 expression\" that can be used as an\n argument to `git-cat-file -t`.  E.g. `master~4` (push\n four parents before the current master head).\n +\ndiff --git a/Documentation/git-rev-parse.txt b/Documentation/git-rev-parse.txt\nindex 5a4e6b5..6235834 100644\n--- a/Documentation/git-rev-parse.txt\n+++ b/Documentation/git-rev-parse.txt\n@@ -59,7 +59,7 @@ OPTIONS\n \tone.\n \n --symbolic::\n-\tUsually the object names are output in SHA1 form (with\n+\tUsually the object names are output in SHA-1 form (with\n \tpossible '{caret}' prefix); this option makes them output in a\n \tform as close to the original input as possible.\n \n@@ -90,7 +90,7 @@ OPTIONS\n \tShow `$GIT_DIR` if defined else show the path to the .git directory.\n \n --short, --short=number::\n-\tInstead of outputting the full SHA1 values of object names try to\n+\tInstead of outputting the full SHA-1 values of object names try to\n \tabbreviate them to a shorter unique name. When no length is specified\n \t7 is used. The minimum length is 4.\n \n@@ -110,10 +110,10 @@ SPECIFYING REVISIONS\n --------------------\n \n A revision parameter typically, but not necessarily, names a\n-commit object.  They use what is called an 'extended SHA1'\n+commit object.  They use what is called an 'extended SHA-1'\n syntax.\n \n-* The full SHA1 object name (40-byte hexadecimal string), or\n+* The full SHA-1 object name (40-byte hexadecimal string), or\n   a substring of such that is unique within the repository.\n   E.g. dae86e1950b1277e545cee180551750029cfe735 and dae86e both\n   name the same commit object if there are no other object in\ndiff --git a/Documentation/git-show-branch.txt b/Documentation/git-show-branch.txt\nindex 424b97b..7afdea3 100644\n--- a/Documentation/git-show-branch.txt\n+++ b/Documentation/git-show-branch.txt\n@@ -28,7 +28,7 @@ no <rev> nor <glob> is given on the comm\n OPTIONS\n -------\n <rev>::\n-\tArbitrary extended SHA1 expression (see `git-rev-parse`)\n+\tArbitrary extended SHA-1 expression (see `git-rev-parse`)\n \tthat typically names a branch HEAD or a tag.\n \n <glob>::\n@@ -97,7 +97,7 @@ displayed, indented N places.  If a comm\n branch, the I-th indentation character shows a `+` sign;\n otherwise it shows a space.  Merge commits are denoted by\n a `-` sign.  Each commit shows a short name that\n-can be used as an extended SHA1 to name that commit.\n+can be used as an extended SHA-1 to name that commit.\n \n The following example shows three branches, \"master\", \"fixes\"\n and \"mhf\":\ndiff --git a/Documentation/git-unpack-file.txt b/Documentation/git-unpack-file.txt\nindex 259df2c..c9da258 100644\n--- a/Documentation/git-unpack-file.txt\n+++ b/Documentation/git-unpack-file.txt\n@@ -13,7 +13,7 @@ SYNOPSIS\n \n DESCRIPTION\n -----------\n-Creates a file holding the contents of the blob specified by sha1. It\n+Creates a file holding the contents of the blob specified by SHA-1. It\n returns the name of the temporary file in the following format:\n \t.merge_file_XXXXX\n \ndiff --git a/Documentation/git-update-index.txt b/Documentation/git-update-index.txt\nindex 56a2b15..10eabd7 100644\n--- a/Documentation/git-update-index.txt\n+++ b/Documentation/git-update-index.txt\n@@ -167,7 +167,7 @@ Using --index-info\n multiple entry definitions from the standard input, and designed\n specifically for scripts.  It can take inputs of three formats:\n \n-    . mode         SP sha1          TAB path\n+    . mode         SP SHA-1          TAB path\n +\n The first format is what \"git-apply --index-info\"\n reports, and used to reconstruct a partial tree\ndiff --git a/Documentation/git-verify-pack.txt b/Documentation/git-verify-pack.txt\nindex d10454c..e0e503f 100644\n--- a/Documentation/git-verify-pack.txt\n+++ b/Documentation/git-verify-pack.txt\n@@ -32,11 +32,11 @@ OUTPUT FORMAT\n -------------\n When specifying the -v option the format used is:\n \n-\tSHA1 type size offset-in-packfile\n+\tSHA-1 type size offset-in-packfile\n \n for objects that are not deltified in the pack, and\n \n-\tSHA1 type size offset-in-packfile depth base-SHA1\n+\tSHA-1 type size offset-in-packfile depth base-SHA-1\n \n for objects that are deltified.\n \ndiff --git a/Documentation/git-verify-tag.txt b/Documentation/git-verify-tag.txt\nindex 1a150f6..7c9835c 100644\n--- a/Documentation/git-verify-tag.txt\n+++ b/Documentation/git-verify-tag.txt\n@@ -16,7 +16,7 @@ Validates the gpg signature created by g\n OPTIONS\n -------\n <tag>::\n-\tSHA1 identifier of a git tag object.\n+\tSHA-1 identifier of a git tag object.\n \n Author\n ------\ndiff --git a/Documentation/git.txt b/Documentation/git.txt\nindex d4472b5..2d454f8 100644\n--- a/Documentation/git.txt\n+++ b/Documentation/git.txt\n@@ -585,7 +585,7 @@ git so take care if using Cogito etc.\n \n 'GIT_OBJECT_DIRECTORY'::\n \tIf the object storage directory is specified via this\n-\tenvironment variable then the sha1 directories are created\n+\tenvironment variable then the SHA-1 directories are created\n \tunderneath - otherwise the default `$GIT_DIR/objects`\n \tdirectory is used.\n \ndiff --git a/Documentation/glossary.txt b/Documentation/glossary.txt\nindex 116ddb7..3a0215c 100644\n--- a/Documentation/glossary.txt\n+++ b/Documentation/glossary.txt\n@@ -163,7 +163,7 @@ merge::\n \n object::\n \tThe unit of storage in git. It is uniquely identified by\n-\tthe SHA1 of its contents. Consequently, an object can not\n+\tthe SHA-1 of its contents. Consequently, an object can not\n \tbe changed.\n \n object database::\n@@ -243,7 +243,7 @@ rebase::\n \tchanges from that branch.\n \n ref::\n-\tA 40-byte hex representation of a SHA1 or a name that denotes\n+\tA 40-byte hex representation of a SHA-1 or a name that denotes\n \ta particular object. These may be stored in `$GIT_DIR/refs/`.\n \n refspec::\n@@ -279,7 +279,7 @@ rewind::\n SCM::\n \tSource code management (tool).\n \n-SHA1::\n+SHA-1::\n \tSynonym for object name.\n \n topic branch::\ndiff --git a/Documentation/tutorial-2.txt b/Documentation/tutorial-2.txt\nindex 894ca5e..0dc91e7 100644\n--- a/Documentation/tutorial-2.txt\n+++ b/Documentation/tutorial-2.txt\n@@ -32,9 +32,9 @@ with?\n \n We saw in part one of the tutorial that commits have names like this.\n It turns out that every object in the git history is stored under\n-such a 40-digit hex name.  That name is the SHA1 hash of the object's\n+such a 40-digit hex name.  That name is the SHA-1 hash of the object's\n contents; among other things, this ensures that git will never store\n-the same data twice (since identical data is given an identical SHA1\n+the same data twice (since identical data is given an identical SHA-1\n name), and that the contents of a git object will never change (since\n that would change the object's name as well).\n \n@@ -51,14 +51,14 @@ A tree can refer to one or more \"blob\" o\n a file.  In addition, a tree can also refer to other tree objects,\n thus creating a directory hierarchy.  You can examine the contents of\n any tree using ls-tree (remember that a long enough initial portion\n-of the SHA1 will also work):\n+of the SHA-1 will also work):\n \n ------------------------------------------------\n $ git ls-tree 92b8b694\n 100644 blob 3b18e512dba79e4c8300dd08aeb37f8e728b8dad    file.txt\n ------------------------------------------------\n \n-Thus we see that this tree has one file in it.  The SHA1 hash is a\n+Thus we see that this tree has one file in it.  The SHA-1 hash is a\n reference to that file's data:\n \n ------------------------------------------------\n@@ -77,7 +77,7 @@ Note that this is the old file data; so \n its response to the initial tree was a tree with a snapshot of the\n directory state that was recorded by the first commit.\n \n-All of these objects are stored under their SHA1 names inside the git\n+All of these objects are stored under their SHA-1 names inside the git\n directory:\n \n ------------------------------------------------\n@@ -114,7 +114,7 @@ ref: refs/heads/master\n \n As you can see, this tells us which branch we're currently on, and it\n tells us this by naming a file under the .git directory, which itself\n-contains a SHA1 name referring to a commit object, which we can\n+contains a SHA-1 name referring to a commit object, which we can\n examine with cat-file:\n \n ------------------------------------------------\n@@ -180,7 +180,7 @@ project's history:\n \n Note, by the way, that lots of commands take a tree as an argument.\n But as we can see above, a tree can be referred to in many different\n-ways--by the SHA1 name for that tree, by the name of a commit that\n+ways--by the SHA-1 name for that tree, by the name of a commit that\n refers to the tree, by the name of a branch whose head refers to that\n tree, etc.--and most such commands can accept any of these names.\n \n-- \n1.4.0.g1b2d\n"},{"id":"21622","messageId":"1150077861580-git-send-email-vonbrand@inf.utfsm.cl","threadId":"4476","inReplyTo":"11500778593947-git-send-email-vonbrand@inf.utfsm.cl","subject":"[PATCH] The hash name is SHA-1, use that throughout","fromName":"Horst H. von Brand","fromEmail":"vonbrand@inf.utfsm.cl","sentAt":"2006-06-12T02:04:19Z","receivedAt":"2006-06-12T02:04:19Z","isPatch":true,"sender":{"key":"vonbrand@inf.utfsm.cl","avatar":"https://avatars.githubusercontent.com/u/211384?v=4"},"body":"Signed-off-by: Horst H. von Brand <vonbrand@inf.utfsm.cl>\n---\n Documentation/technical/pack-format.txt     |    8 ++++----\n Documentation/technical/pack-heuristics.txt |    4 ++--\n Documentation/technical/pack-protocol.txt   |   20 ++++++++++----------\n 3 files changed, 16 insertions(+), 16 deletions(-)\n\ndiff --git a/Documentation/technical/pack-format.txt b/Documentation/technical/pack-format.txt\nindex 0e1ffb2..8823dce 100644\n--- a/Documentation/technical/pack-format.txt\n+++ b/Documentation/technical/pack-format.txt\n@@ -32,7 +32,7 @@ GIT pack format\n      Observation: length of each object is encoded in a variable\n      length format and is not constrained to 32-bit or anything.\n \n-  - The trailer records 20-byte SHA1 checksum of all of the above.\n+  - The trailer records 20-byte SHA-1 checksum of all of the above.\n \n = pack-*.idx file has the following format:\n \n@@ -61,10 +61,10 @@ GIT pack format\n \n   - The file is concluded with a trailer:\n \n-    A copy of the 20-byte SHA1 checksum at the end of\n+    A copy of the 20-byte SHA-1 checksum at the end of\n     corresponding packfile.\n \n-    20-byte SHA1-checksum of all of the above.\n+    20-byte SHA-1-checksum of all of the above.\n \n Pack Idx file:\n \n@@ -111,6 +111,6 @@ Pack file entry: <+\n         If it is not DELTA, then deflated bytes (the size above\n \t\tis the size before compression).\n \tIf it is DELTA, then\n-\t  20-byte base object name SHA1 (the size above is the\n+\t  20-byte base object name SHA-1 (the size above is the\n \t  \tsize of the delta data that follows).\n           delta data, deflated.\ndiff --git a/Documentation/technical/pack-heuristics.txt b/Documentation/technical/pack-heuristics.txt\nindex 9aadd5c..458677e 100644\n--- a/Documentation/technical/pack-heuristics.txt\n+++ b/Documentation/technical/pack-heuristics.txt\n@@ -77,7 +77,7 @@ And Bable-like confusion flowed.\n \n     <njs`> oh, hmm, and I'm not sure what this sliding window means either\n \n-    <pasky> iirc, it appeared to me to be just the sha1 of the object\n+    <pasky> iirc, it appeared to me to be just the SHA-1 of the object\n         when reading the code casually ...\n \n         ... which simply doesn't sound as a very good heuristics, though ;)\n@@ -89,7 +89,7 @@ Ah, grasshopper!  And thus the enlighten\n \n     <linus> The \"magic\" is actually in theory totally arbitrary.\n         ANY order will give you a working pack, but no, it's not\n-        ordered by SHA1.\n+        ordered by SHA-1.\n \n         Before talking about the ordering for the sliding delta\n         window, let's talk about the recency order. That's more\ndiff --git a/Documentation/technical/pack-protocol.txt b/Documentation/technical/pack-protocol.txt\nindex 9cd48b4..9df76e3 100644\n--- a/Documentation/technical/pack-protocol.txt\n+++ b/Documentation/technical/pack-protocol.txt\n@@ -6,22 +6,22 @@ There are two Pack push-pull protocols.\n upload-pack (S) | fetch/clone-pack (C) protocol:\n \n \t# Tell the puller what commits we have and what their names are\n-\tS: SHA1 name\n+\tS: SHA-1 name\n \tS: ...\n-\tS: SHA1 name\n+\tS: SHA-1 name\n \tS: # flush -- it's your turn\n \t# Tell the pusher what commits we want, and what we have\n \tC: want name\n \tC: ..\n \tC: want name\n-\tC: have SHA1\n-\tC: have SHA1\n+\tC: have SHA-1\n+\tC: have SHA-1\n \tC: ...\n \tC: # flush -- occasionally ask \"had enough?\"\n \tS: NAK\n-\tC: have SHA1\n+\tC: have SHA-1\n \tC: ...\n-\tC: have SHA1\n+\tC: have SHA-1\n \tS: ACK\n \tC: done\n \tS: XXXXXXX -- packfile contents.\n@@ -29,13 +29,13 @@ upload-pack (S) | fetch/clone-pack (C) p\n send-pack | receive-pack protocol.\n \n \t# Tell the pusher what commits we have and what their names are\n-\tC: SHA1 name\n+\tC: SHA-1 name\n \tC: ...\n-\tC: SHA1 name\n+\tC: SHA-1 name\n \tC: # flush -- it's your turn\n \t# Tell the puller what the pusher has\n-\tS: old-SHA1 new-SHA1 name\n-\tS: old-SHA1 new-SHA1 name\n+\tS: old-SHA-1 new-SHA-1 name\n+\tS: old-SHA-1 new-SHA-1 name\n \tS: ...\n \tS: # flush -- done with the list\n \tS: XXXXXXX --- packfile contents.\n-- \n1.4.0.g1b2d\n"}]}