{"thread":{"id":"19046","subject":"[PATCH 2/2] Documentation: replace SHA1 by SHA-1","startedAt":"2009-04-24T14:49:33Z","lastAt":"2009-04-25T12:13:07Z","messageCount":12,"participants":["Michael J Gruber","Johannes Sixt","Wincent Colaiuta","Jeff King","Junio C Hamano","Felipe Contreras","Dmitry Potapov"],"isPatch":true,"patchVersion":1,"patchTotal":2},"messages":[{"id":"112194","messageId":"1240584575-5702-1-git-send-email-git@drmicha.warpmail.net","threadId":"19046","inReplyTo":null,"subject":"[PATCH 0/2] Unify use of [sha,SHA][,-]1","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2009-04-24T14:49:33Z","receivedAt":"2009-04-24T14:49:33Z","isPatch":true,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"a6e5ef7 (user-manual: the name of the hash function is SHA-1, not sha1,\n2009-04-04) made sure the user manual names the hash \"SHA-1\" only. This\nseries achieves the same for the rest of the documentation.\n\nI split it into two parts for replacing \"sha1\" and \"SHA1\". The form\n\"sha-1\" did not appear anywhere.\n\nI went through each replacement manually: code samples etc. should not be\ntransformed. Each commit messsage lists the exceptions.\n\nThe diffstat may look a bit frightening but the patch can be reviewed\nmost easily with --color-words. I'd be happy to be split it up further\nbut didn't see any obvious splitting boundaries. (I would point to\nhttp://repo.or.cz/w/git/mjg.git?h=refs/heads/doc-use-SHA-1 if gitweb\nhad commitdiff-colorwords.)\n\nCheers,\nMichael\n\nSuggested by: Ulrich Windl\n\nMichael J Gruber (2):\n  Documentation: replace sha1 by SHA-1\n  Documentation: replace SHA1 by SHA-1\n\n Documentation/config.txt                           |    2 +-\n Documentation/diff-format.txt                      |    8 ++--\n Documentation/git-blame.txt                        |    4 +-\n Documentation/git-branch.txt                       |    8 ++--\n Documentation/git-cat-file.txt                     |   10 +++---\n Documentation/git-cherry.txt                       |    4 +-\n Documentation/git-cvsexportcommit.txt              |    4 +-\n Documentation/git-describe.txt                     |    2 +-\n Documentation/git-diff-index.txt                   |    8 ++--\n Documentation/git-filter-branch.txt                |    6 ++--\n Documentation/git-fsck.txt                         |   12 ++++----\n Documentation/git-index-pack.txt                   |    2 +-\n Documentation/git-init.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-name-rev.txt                     |    2 +-\n Documentation/git-pack-objects.txt                 |    2 +-\n Documentation/git-patch-id.txt                     |    2 +-\n Documentation/git-receive-pack.txt                 |   32 ++++++++++----------\n Documentation/git-reflog.txt                       |    4 +-\n Documentation/git-rev-parse.txt                    |    8 ++--\n Documentation/git-show-branch.txt                  |    4 +-\n Documentation/git-show-index.txt                   |    2 +-\n Documentation/git-show-ref.txt                     |    4 +-\n Documentation/git-svn.txt                          |    4 +-\n Documentation/git-tag.txt                          |    2 +-\n Documentation/git-unpack-file.txt                  |    2 +-\n Documentation/git-update-index.txt                 |   14 ++++----\n Documentation/git-update-ref.txt                   |    8 ++--\n Documentation/git-verify-pack.txt                  |    4 +-\n Documentation/git-verify-tag.txt                   |    2 +-\n Documentation/git.txt                              |   12 ++++----\n Documentation/gitcore-tutorial.txt                 |    8 ++--\n Documentation/gitdiffcore.txt                      |    2 +-\n Documentation/githooks.txt                         |    2 +-\n Documentation/gittutorial-2.txt                    |   16 +++++-----\n Documentation/glossary-content.txt                 |    8 ++--\n .../howto/recover-corrupted-blob-object.txt        |    6 ++--\n Documentation/howto/update-hook-example.txt        |    6 ++--\n Documentation/pretty-formats.txt                   |   16 +++++-----\n Documentation/technical/pack-format.txt            |   14 ++++----\n Documentation/technical/pack-protocol.txt          |   20 ++++++------\n Documentation/technical/shallow.txt                |    4 +-\n 44 files changed, 144 insertions(+), 144 deletions(-)\n"},{"id":"112193","messageId":"1240584575-5702-2-git-send-email-git@drmicha.warpmail.net","threadId":"19046","inReplyTo":"1240584575-5702-1-git-send-email-git@drmicha.warpmail.net","subject":"[PATCH 1/2] Documentation: replace sha1 by SHA-1","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2009-04-24T14:49:34Z","receivedAt":"2009-04-24T14:49:34Z","isPatch":true,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Replace sha1 by SHA-1 with the following exceptions:\n\n* code samples\n* irc conversations contained as documentation\n  (Documentation/technical/pack-heuristics.txt)\n\nSigned-off-by: Michael J Gruber <git@drmicha.warpmail.net>\n---\n Documentation/diff-format.txt               |    8 +++---\n Documentation/git-blame.txt                 |    4 +-\n Documentation/git-branch.txt                |    8 +++---\n Documentation/git-cat-file.txt              |    4 +-\n Documentation/git-cherry.txt                |    4 +-\n Documentation/git-cvsexportcommit.txt       |    4 +-\n Documentation/git-diff-index.txt            |    8 +++---\n Documentation/git-filter-branch.txt         |    6 ++--\n Documentation/git-fsck.txt                  |    8 +++---\n Documentation/git-init.txt                  |    2 +-\n Documentation/git-mktag.txt                 |    2 +-\n Documentation/git-name-rev.txt              |    2 +-\n Documentation/git-receive-pack.txt          |   32 +++++++++++++-------------\n Documentation/git-reflog.txt                |    4 +-\n Documentation/git-svn.txt                   |    4 +-\n Documentation/git-unpack-file.txt           |    2 +-\n Documentation/git-update-index.txt          |   12 +++++-----\n Documentation/git-update-ref.txt            |    8 +++---\n Documentation/git.txt                       |    2 +-\n Documentation/howto/update-hook-example.txt |    6 ++--\n Documentation/pretty-formats.txt            |   14 ++++++------\n 21 files changed, 72 insertions(+), 72 deletions(-)\n\ndiff --git a/Documentation/diff-format.txt b/Documentation/diff-format.txt\nindex 1eeb1c7..53da361 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@@ -62,7 +62,7 @@ Status letters C and R are always followed by a score (denoting the\n percentage of similarity between the source and target of the move or\n copy), and are the only ones to be so.\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@@ -84,7 +84,7 @@ to generate diff output also for merge commits.  The output differs\n from the format described above in the following way:\n \n . there is a colon for each parent\n-. there are more \"src\" modes and \"src\" sha1\n+. there are more \"src\" modes and \"src\" SHA-1\n . status is concatenated status characters for each parent\n . no optional \"score\" number\n . single path, only for \"dst\"\ndiff --git a/Documentation/git-blame.txt b/Documentation/git-blame.txt\nindex 8c7b7b0..139a05f 100644\n--- a/Documentation/git-blame.txt\n+++ b/Documentation/git-blame.txt\n@@ -158,7 +158,7 @@ annotated.\n \n . Each blame entry always starts with a line of:\n \n-\t<40-byte hex sha1> <sourceline> <resultline> <num_lines>\n+\t<40-byte hex SHA-1> <sourceline> <resultline> <num_lines>\n +\n Line numbers count from 1.\n \n@@ -177,7 +177,7 @@ parser (which should be quite natural for most scripting languages).\n +\n [NOTE]\n For people who do parsing: to make it more robust, just ignore any\n-lines between the first and last one (\"<sha1>\" and \"filename\" lines)\n+lines between the first and last one (\"<SHA-1>\" and \"filename\" lines)\n where you do not recognize the tag words (or care about that particular\n one) at the beginning of the \"extended information\" lines. That way, if\n there is ever added information (like the commit encoding or extended\ndiff --git a/Documentation/git-branch.txt b/Documentation/git-branch.txt\nindex cbd4275..15650c8 100644\n--- a/Documentation/git-branch.txt\n+++ b/Documentation/git-branch.txt\n@@ -73,7 +73,7 @@ OPTIONS\n -l::\n \tCreate the branch's reflog.  This activates recording of\n \tall changes made to 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 \tReset <branchname> to <startpoint> if <branchname> exists\n@@ -100,16 +100,16 @@ OPTIONS\n \n -v::\n --verbose::\n-\tShow sha1 and commit subject line for each head, along with\n+\tShow SHA-1 and commit subject line for each head, along with\n \trelationship to upstream branch (if any). If given twice, print\n \tthe name of the upstream branch, as well.\n \n --abbrev=<length>::\n-\tAlter the sha1's minimum display length in the output listing.\n+\tAlter the SHA-1's minimum display length in the output listing.\n \tThe default value is 7.\n \n --no-abbrev::\n-\tDisplay the full sha1s in the output listing rather than abbreviating them.\n+\tDisplay the full SHA-1s in the output listing rather than abbreviating them.\n \n --track::\n \tWhen creating a new branch, set up configuration to mark the\ndiff --git a/Documentation/git-cat-file.txt b/Documentation/git-cat-file.txt\nindex b191276..db56d6e 100644\n--- a/Documentation/git-cat-file.txt\n+++ b/Documentation/git-cat-file.txt\n@@ -76,7 +76,7 @@ If '--batch' is specified, output of the following form is printed for each\n object specified on stdin:\n \n ------------\n-<sha1> SP <type> SP <size> LF\n+<SHA-1> SP <type> SP <size> LF\n <contents> LF\n ------------\n \n@@ -84,7 +84,7 @@ If '--batch-check' is specified, output of the following form is printed for\n each object specified on stdin:\n \n ------------\n-<sha1> SP <type> SP <size> LF\n+<SHA-1> SP <type> SP <size> LF\n ------------\n \n For both '--batch' and '--batch-check', output of the following form is printed\ndiff --git a/Documentation/git-cherry.txt b/Documentation/git-cherry.txt\nindex 7deefda..b6fd758 100644\n--- a/Documentation/git-cherry.txt\n+++ b/Documentation/git-cherry.txt\n@@ -17,7 +17,7 @@ The commits are compared with their 'patch id', obtained from\n the 'git-patch-id' program.\n \n Every commit that doesn't exist in the <upstream> branch\n-has its id (sha1) reported, prefixed by a symbol.  The ones that have\n+has its id (SHA-1) reported, prefixed by a symbol.  The ones that have\n equivalent change already\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@@ -38,7 +38,7 @@ to and including <limit> are not reported:\n \n \n Because 'git-cherry' compares the changeset rather than the commit id\n-(sha1), you can use 'git-cherry' to find out if a commit you made locally\n+(SHA-1), you can use 'git-cherry' to find out if a commit you made locally\n has been applied <upstream> under a different commit id.  For example,\n this will happen if you're feeding patches <upstream> via email rather\n than pushing or pulling commits directly.\ndiff --git a/Documentation/git-cvsexportcommit.txt b/Documentation/git-cvsexportcommit.txt\nindex 2da8588..01d69bf 100644\n--- a/Documentation/git-cvsexportcommit.txt\n+++ b/Documentation/git-cvsexportcommit.txt\n@@ -90,14 +90,14 @@ Merge one patch into CVS::\n ------------\n $ export GIT_DIR=~/project/.git\n $ cd ~/project_cvs_checkout\n-$ git cvsexportcommit -v <commit-sha1>\n+$ git cvsexportcommit -v <commit-SHA-1>\n $ cvs commit -F .msg <files>\n ------------\n \n Merge one patch into CVS (-c and -w options). The working directory is within the Git Repo::\n +\n ------------\n-\t$ git cvsexportcommit -v -c -w ~/project_cvs_checkout <commit-sha1>\n+\t$ git cvsexportcommit -v -c -w ~/project_cvs_checkout <commit-SHA-1>\n ------------\n \n Merge pending patches into CVS automatically -- only if you really know what you are doing::\ndiff --git a/Documentation/git-diff-index.txt b/Documentation/git-diff-index.txt\nindex 26920d4..cc34cb8 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 matches the 'git-diff-tree -r'\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-index' on it yet - there is no\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 that you need to\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-filter-branch.txt b/Documentation/git-filter-branch.txt\nindex ab527b5..e8ffe2f 100644\n--- a/Documentation/git-filter-branch.txt\n+++ b/Documentation/git-filter-branch.txt\n@@ -66,9 +66,9 @@ of these variables after the filters have run, are used for the new commit.\n If any evaluation of <command> returns a non-zero exit status, the whole\n operation will be aborted.\n \n-A 'map' function is available that takes an \"original sha1 id\" argument\n-and outputs a \"rewritten sha1 id\" if the commit has been already\n-rewritten, and \"original sha1 id\" otherwise; the 'map' function can\n+A 'map' function is available that takes an \"original SHA-1 id\" argument\n+and outputs a \"rewritten SHA-1 id\" if the commit has been already\n+rewritten, and \"original SHA-1 id\" otherwise; the 'map' function can\n return several ids on separate lines if your commit filter emitted\n multiple commits.\n \ndiff --git a/Documentation/git-fsck.txt b/Documentation/git-fsck.txt\nindex 287c4fc..73e1dc4 100644\n--- a/Documentation/git-fsck.txt\n+++ b/Documentation/git-fsck.txt\n@@ -103,8 +103,8 @@ expect dangling commits - potential heads - due to lack of head information::\n \tpossible to differentiate between un-parented commits and\n \troot nodes.\n \n-missing sha1 directory '<dir>'::\n-\tThe directory holding the sha1 objects is missing.\n+missing SHA-1 directory '<dir>'::\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@@ -125,8 +125,8 @@ dangling <type> <object>::\n warning: git-fsck: tree <tree> has full pathnames in it::\n \tAnd it shouldn't...\n \n-sha1 mismatch <object>::\n-\tThe database has an object who's sha1 doesn't match the\n+SHA-1 mismatch <object>::\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.txt b/Documentation/git-init.txt\nindex 71749c0..fb19bea 100644\n--- a/Documentation/git-init.txt\n+++ b/Documentation/git-init.txt\n@@ -83,7 +83,7 @@ If the `$GIT_DIR` environment variable is set then it specifies a path\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 Running 'git-init' in an existing repository is safe. It will not overwrite\ndiff --git a/Documentation/git-mktag.txt b/Documentation/git-mktag.txt\nindex 8bcc114..570dc26 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: four lines of\n \n-  object <sha1>\n+  object <SHA-1>\n   type <typename>\n   tag <tagname>\n   tagger <tagger>\ndiff --git a/Documentation/git-name-rev.txt b/Documentation/git-name-rev.txt\nindex 7ca8a7b..519d6a9 100644\n--- a/Documentation/git-name-rev.txt\n+++ b/Documentation/git-name-rev.txt\n@@ -31,7 +31,7 @@ OPTIONS\n \tList all commits reachable from all refs\n \n --stdin::\n-\tRead from stdin, append \"(<rev_name>)\" to all sha1's of nameable\n+\tRead from stdin, append \"(<rev_name>)\" to all SHA-1s of nameable\n \tcommits, and pass to stdout\n \n --name-only::\ndiff --git a/Documentation/git-receive-pack.txt b/Documentation/git-receive-pack.txt\nindex 514f03c..d357024 100644\n--- a/Documentation/git-receive-pack.txt\n+++ b/Documentation/git-receive-pack.txt\n@@ -20,7 +20,7 @@ The UI for the protocol is on the 'git-send-pack' side, and the\n program pair is meant to be used to push updates to remote\n repository.  For pull operations, see linkgit:git-fetch-pack[1].\n \n-The command allows for creation and fast forwarding of sha1 refs\n+The command allows for creation and fast forwarding of SHA-1 refs\n (heads/tags) on the remote end (strictly speaking, it is the\n local end 'git-receive-pack' runs, but to the user who is sitting at\n the send-pack end, it is updating the remote.  Confused?)\n@@ -43,14 +43,14 @@ Before any ref is updated, if $GIT_DIR/hooks/pre-receive file exists\n and is executable, it will be invoked once with no parameters.  The\n standard input of the hook will be one line per ref to be updated:\n \n-       sha1-old SP sha1-new SP refname LF\n+       SHA-1-old SP SHA-1-new SP refname LF\n \n The refname value is relative to $GIT_DIR; e.g. for the master\n-head this is \"refs/heads/master\".  The two sha1 values before\n+head this is \"refs/heads/master\".  The two SHA-1 values before\n each refname are the object names for the refname before and after\n-the update.  Refs to be created will have sha1-old equal to 0\\{40},\n-while refs to be deleted will have sha1-new equal to 0\\{40}, otherwise\n-sha1-old and sha1-new should be valid objects in the repository.\n+the update.  Refs to be created will have SHA-1-old equal to 0\\{40},\n+while refs to be deleted will have SHA-1-new equal to 0\\{40}, otherwise\n+SHA-1-old and SHA-1-new should be valid objects in the repository.\n \n This hook is called before any refname is updated and before any\n fast-forward checks are performed.\n@@ -65,13 +65,13 @@ update Hook\n Before each ref is updated, if $GIT_DIR/hooks/update file exists\n and is executable, it is invoked once per ref, with three parameters:\n \n-       $GIT_DIR/hooks/update refname sha1-old sha1-new\n+       $GIT_DIR/hooks/update refname SHA-1-old SHA-1-new\n \n The refname parameter is relative to $GIT_DIR; e.g. for the master\n-head this is \"refs/heads/master\".  The two sha1 arguments are\n+head this is \"refs/heads/master\".  The two SHA-1 arguments are\n the object names for the refname before and after the update.\n Note that the hook is called before the refname is updated,\n-so either sha1-old is 0\\{40} (meaning there is no such ref yet),\n+so either SHA-1-old is 0\\{40} (meaning there is no such ref yet),\n or it should match what is recorded in refname.\n \n The hook should exit with non-zero status if it wants to disallow\n@@ -90,14 +90,14 @@ file exists and is executable, it will be invoked once with no\n parameters.  The standard input of the hook will be one line\n for each successfully updated ref:\n \n-       sha1-old SP sha1-new SP refname LF\n+       SHA-1-old SP SHA-1-new SP refname LF\n \n The refname value is relative to $GIT_DIR; e.g. for the master\n-head this is \"refs/heads/master\".  The two sha1 values before\n+head this is \"refs/heads/master\".  The two SHA-1 values before\n each refname are the object names for the refname before and after\n-the update.  Refs that were created will have sha1-old equal to\n-0\\{40}, while refs that were deleted will have sha1-new equal to\n-0\\{40}, otherwise sha1-old and sha1-new should be valid objects in\n+the update.  Refs that were created will have SHA-1-old equal to\n+0\\{40}, while refs that were deleted will have SHA-1-new equal to\n+0\\{40}, otherwise SHA-1-old and SHA-1-new should be valid objects in\n the repository.\n \n Using this hook, it is easy to generate mails describing the updates\n@@ -123,10 +123,10 @@ ref listing the commits pushed to the repository:\n The exit code from this hook invocation is ignored, however a\n non-zero exit code will generate an error message.\n \n-Note that it is possible for refname to not have sha1-new when this\n+Note that it is possible for refname to not have SHA-1-new when this\n hook runs.  This can easily occur if another user modifies the ref\n after it was updated by 'git-receive-pack', but before the hook was able\n-to evaluate it.  It is recommended that hooks rely on sha1-new\n+to evaluate it.  It is recommended that hooks rely on SHA-1-new\n rather than the current value of refname.\n \n post-update Hook\ndiff --git a/Documentation/git-reflog.txt b/Documentation/git-reflog.txt\nindex 7f7a544..8d3d2e2 100644\n--- a/Documentation/git-reflog.txt\n+++ b/Documentation/git-reflog.txt\n@@ -81,12 +81,12 @@ them.\n \tInstead of listing <refs> explicitly, prune all refs.\n \n --updateref::\n-\tUpdate the ref with the sha1 of the top reflog entry (i.e.\n+\tUpdate the ref with the SHA-1 of the top reflog entry (i.e.\n \t<ref>@\\{0\\}) after expiring or deleting.\n \n --rewrite::\n \tWhile expiring or deleting, adjust each reflog entry to ensure\n-\tthat the `old` sha1 field points to the `new` sha1 field of the\n+\tthat the `old` SHA-1 field points to the `new` SHA-1 field of the\n \tprevious entry.\n \n --verbose::\ndiff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt\nindex 9229d45..f5be417 100644\n--- a/Documentation/git-svn.txt\n+++ b/Documentation/git-svn.txt\n@@ -232,7 +232,7 @@ New features:\n +\n --\n --show-commit;;\n-\tshows the git commit sha1, as well\n+\tshows the git commit SHA-1, as well\n --oneline;;\n \tour version of --pretty=oneline\n --\n@@ -343,7 +343,7 @@ and lost.\n Only used with the 'set-tree' command.\n \n Read a list of commits from stdin and commit them in reverse\n-order.  Only the leading sha1 is read from each line, so\n+order.  Only the leading SHA-1 is read from each line, so\n 'git-rev-list --pretty=oneline' output can be used.\n \n --rmdir::\ndiff --git a/Documentation/git-unpack-file.txt b/Documentation/git-unpack-file.txt\nindex 995db9f..799e5b4 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 25e0bbe..ab98949 100644\n--- a/Documentation/git-update-index.txt\n+++ b/Documentation/git-update-index.txt\n@@ -149,7 +149,7 @@ you will need to handle the situation manually.\n \n Using --refresh\n ---------------\n-'--refresh' does not calculate a new sha1 file or bring the index\n+'--refresh' does not calculate a new SHA-1 file or bring the index\n up-to-date for mode/content changes. But what it *does* do is to\n \"re-match\" the stat information of a file with the index, so that you\n can refresh the index for a file that hasn't been changed but where\n@@ -164,10 +164,10 @@ Using --cacheinfo or --info-only\n current working directory.  This is useful for minimum-checkout\n merging.\n \n-To pretend you have a file with mode and sha1 at path, say:\n+To pretend you have a file with mode and SHA-1 at path, say:\n \n ----------------\n-$ git update-index --cacheinfo mode sha1 path\n+$ git update-index --cacheinfo mode SHA-1 path\n ----------------\n \n '--info-only' is used to register files without placing them in the object\n@@ -187,19 +187,19 @@ 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\n that is used for phony merge base tree when falling\n back on 3-way merge.\n \n-    . mode SP type SP sha1          TAB path\n+    . mode SP type SP SHA-1          TAB path\n +\n The second format is to stuff 'git-ls-tree' output\n into the index file.\n \n-    . mode         SP sha1 SP stage TAB path\n+    . mode         SP SHA-1 SP stage TAB path\n +\n This format is to put higher order stages into the\n index file and matches 'git-ls-files --stage' output.\ndiff --git a/Documentation/git-update-ref.txt b/Documentation/git-update-ref.txt\nindex 9639f70..7b7492a 100644\n--- a/Documentation/git-update-ref.txt\n+++ b/Documentation/git-update-ref.txt\n@@ -66,16 +66,16 @@ a line to the log file \"$GIT_DIR/logs/<ref>\" (dereferencing all\n symbolic refs before creating the log name) describing the change\n in ref value.  Log lines are formatted as:\n \n-    . oldsha1 SP newsha1 SP committer LF\n+    . SHA-1-old SP SHA-1-new SP committer LF\n +\n-Where \"oldsha1\" is the 40 character hexadecimal value previously\n-stored in <ref>, \"newsha1\" is the 40 character hexadecimal value of\n+Where \"SHA-1-old\" is the 40 character hexadecimal value previously\n+stored in <ref>, \"SHA-1-new\" is the 40 character hexadecimal value of\n <newvalue> and \"committer\" is the committer's name, email address\n and date in the standard GIT committer ident format.\n \n Optionally with -m:\n \n-    . oldsha1 SP newsha1 SP committer TAB message LF\n+    . SHA-1-old SP SHA-1-new SP committer TAB message LF\n +\n Where all fields are as described above and \"message\" is the\n value supplied to the -m option.\ndiff --git a/Documentation/git.txt b/Documentation/git.txt\nindex 470fdc5..5d2d5b7 100644\n--- a/Documentation/git.txt\n+++ b/Documentation/git.txt\n@@ -443,7 +443,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/howto/update-hook-example.txt b/Documentation/howto/update-hook-example.txt\nindex 697d918..baa6484 100644\n--- a/Documentation/howto/update-hook-example.txt\n+++ b/Documentation/howto/update-hook-example.txt\n@@ -14,13 +14,13 @@ section of the documentation:\n     Before each ref is updated, if $GIT_DIR/hooks/update file exists\n     and executable, it is called with three parameters:\n \n-           $GIT_DIR/hooks/update refname sha1-old sha1-new\n+           $GIT_DIR/hooks/update refname SHA-1-old SHA-1-new\n \n     The refname parameter is relative to $GIT_DIR; e.g. for the\n-    master head this is \"refs/heads/master\".  Two sha1 are the\n+    master head this is \"refs/heads/master\".  Two SHA-1 are the\n     object names for the refname before and after the update.  Note\n     that the hook is called before the refname is updated, so either\n-    sha1-old is 0{40} (meaning there is no such ref yet), or it\n+    SHA-1-old is 0{40} (meaning there is no such ref yet), or it\n     should match what is recorded in refname.\n \n So if your policy is (1) always require fast-forward push\ndiff --git a/Documentation/pretty-formats.txt b/Documentation/pretty-formats.txt\nindex 2a845b1..fac8ebd 100644\n--- a/Documentation/pretty-formats.txt\n+++ b/Documentation/pretty-formats.txt\n@@ -4,7 +4,7 @@ PRETTY FORMATS\n If the commit is a merge, and if the pretty-format\n is not 'oneline', 'email' or 'raw', an additional line is\n inserted before the 'Author:' line.  This line begins with\n-\"Merge: \" and the sha1s of ancestral commits are printed,\n+\"Merge: \" and the SHA-1s of ancestral commits are printed,\n separated by spaces.  Note that the listed commits may not\n necessarily be the list of the *direct* parent commits if you\n have limited your view of history: for example, if you are\n@@ -15,20 +15,20 @@ Here are some additional details for each format:\n \n * 'oneline'\n \n-\t  <sha1> <title line>\n+\t  <SHA-1> <title line>\n +\n This is designed to be as compact as possible.\n \n * 'short'\n \n-\t  commit <sha1>\n+\t  commit <SHA-1>\n \t  Author: <author>\n \n \t      <title line>\n \n * 'medium'\n \n-\t  commit <sha1>\n+\t  commit <SHA-1>\n \t  Author: <author>\n \t  Date:   <author date>\n \n@@ -38,7 +38,7 @@ This is designed to be as compact as possible.\n \n * 'full'\n \n-\t  commit <sha1>\n+\t  commit <SHA-1>\n \t  Author: <author>\n \t  Commit: <committer>\n \n@@ -48,7 +48,7 @@ This is designed to be as compact as possible.\n \n * 'fuller'\n \n-\t  commit <sha1>\n+\t  commit <SHA-1>\n \t  Author:     <author>\n \t  AuthorDate: <author date>\n \t  Commit:     <committer>\n@@ -60,7 +60,7 @@ This is designed to be as compact as possible.\n \n * 'email'\n \n-\t  From <sha1> <date>\n+\t  From <SHA-1> <date>\n \t  From: <author>\n \t  Date: <author date>\n \t  Subject: [PATCH] <title line>\n-- \n1.6.3.rc1.51.gea0b7\n"},{"id":"112192","messageId":"1240584575-5702-3-git-send-email-git@drmicha.warpmail.net","threadId":"19046","inReplyTo":"1240584575-5702-2-git-send-email-git@drmicha.warpmail.net","subject":"[PATCH 2/2] Documentation: replace SHA1 by SHA-1","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2009-04-24T14:49:35Z","receivedAt":"2009-04-24T14:49:35Z","isPatch":true,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Replace SHA1 by SHA-1 with the following exceptions:\n\n* asciidoc anchor definitions\n* irc conversations contained as documentation\n  (Documentation/technical/pack-heuristics.txt)\n\nSigned-off-by: Michael J Gruber <git@drmicha.warpmail.net>\n---\n Documentation/config.txt                           |    2 +-\n Documentation/git-cat-file.txt                     |    6 +++---\n Documentation/git-describe.txt                     |    2 +-\n Documentation/git-fsck.txt                         |    4 ++--\n Documentation/git-index-pack.txt                   |    2 +-\n Documentation/git-ls-files.txt                     |    2 +-\n Documentation/git-merge-index.txt                  |    2 +-\n Documentation/git-pack-objects.txt                 |    2 +-\n Documentation/git-patch-id.txt                     |    2 +-\n Documentation/git-rev-parse.txt                    |    8 ++++----\n Documentation/git-show-branch.txt                  |    4 ++--\n Documentation/git-show-index.txt                   |    2 +-\n Documentation/git-show-ref.txt                     |    4 ++--\n Documentation/git-tag.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                              |   10 +++++-----\n Documentation/gitcore-tutorial.txt                 |    8 ++++----\n Documentation/gitdiffcore.txt                      |    2 +-\n Documentation/githooks.txt                         |    2 +-\n Documentation/gittutorial-2.txt                    |   16 ++++++++--------\n Documentation/glossary-content.txt                 |    8 ++++----\n .../howto/recover-corrupted-blob-object.txt        |    6 +++---\n Documentation/pretty-formats.txt                   |    2 +-\n Documentation/technical/pack-format.txt            |   14 +++++++-------\n Documentation/technical/pack-protocol.txt          |   20 ++++++++++----------\n Documentation/technical/shallow.txt                |    4 ++--\n 28 files changed, 72 insertions(+), 72 deletions(-)\n\ndiff --git a/Documentation/config.txt b/Documentation/config.txt\nindex f3ebd2f..4deac24 100644\n--- a/Documentation/config.txt\n+++ b/Documentation/config.txt\n@@ -271,7 +271,7 @@ core.worktree::\n core.logAllRefUpdates::\n \tEnable the reflog. Updates to a ref <ref> is logged to the file\n \t\"$GIT_DIR/logs/<ref>\", by appending the new and old\n-\tSHA1, the date/time and the reason of the update, but\n+\tSHA-1, the date/time and the reason of the update, but\n \tonly when the file exists.  If this configuration\n \tvariable is set to true, missing \"$GIT_DIR/logs/<ref>\"\n \tfile is automatically created for branch heads.\ndiff --git a/Documentation/git-cat-file.txt b/Documentation/git-cat-file.txt\nindex db56d6e..c9385f7 100644\n--- a/Documentation/git-cat-file.txt\n+++ b/Documentation/git-cat-file.txt\n@@ -19,7 +19,7 @@ the repository. The type is required unless '-t' or '-p' is used to find the\n object type, or '-s' is used to find the object size.\n \n In the second form, a list of objects (separated by linefeeds) is provided on\n-stdin, and the SHA1, type, and size of each object is printed on stdout.\n+stdin, and the SHA-1, type, and size of each object is printed on stdout.\n \n OPTIONS\n -------\n@@ -52,11 +52,11 @@ OPTIONS\n \tpoints at it.\n \n --batch::\n-\tPrint the SHA1, type, size, and contents of each object provided on\n+\tPrint the SHA-1, type, size, and contents of each object provided on\n \tstdin. May not be combined with any other options or arguments.\n \n --batch-check::\n-\tPrint the SHA1, type, and size of each object provided on stdin. May not\n+\tPrint the SHA-1, type, and size of each object provided on stdin. May not\n \tbe combined with any other options or arguments.\n \n OUTPUT\ndiff --git a/Documentation/git-describe.txt b/Documentation/git-describe.txt\nindex b231dbb..c051b5c 100644\n--- a/Documentation/git-describe.txt\n+++ b/Documentation/git-describe.txt\n@@ -129,7 +129,7 @@ is found, its name will be output and searching will stop.\n If an exact match was not found, 'git-describe' will walk back\n through the commit history to locate an ancestor commit which\n has been tagged.  The ancestor's tag will be output along with an\n-abbreviation of the input committish's SHA1.\n+abbreviation of the input committish's SHA-1.\n \n If multiple tags were found during the walk then the tag which\n has the fewest commits different from the input committish will be\ndiff --git a/Documentation/git-fsck.txt b/Documentation/git-fsck.txt\nindex 73e1dc4..88d12fc 100644\n--- a/Documentation/git-fsck.txt\n+++ b/Documentation/git-fsck.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' defaults to using the\n-index file, all SHA1 references in .git/refs/*, and all reflogs (unless\n+index file, all SHA-1 references in .git/refs/*, and all reflogs (unless\n --no-reflogs is given) as heads.\n \n --unreachable::\n@@ -71,7 +71,7 @@ index file, all SHA1 references in .git/refs/*, and all reflogs (unless\n \ta blob, the contents are written into the file, rather than\n \tits object name.\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\ndiff --git a/Documentation/git-index-pack.txt b/Documentation/git-index-pack.txt\nindex 4b5c743..3f499a2 100644\n--- a/Documentation/git-index-pack.txt\n+++ b/Documentation/git-index-pack.txt\n@@ -83,7 +83,7 @@ Note\n ----\n \n Once the index has been created, the list of object names is sorted\n-and the SHA1 hash of that list is printed to stdout. If --stdin was\n+and the SHA-1 hash of that list is printed to stdout. If --stdin was\n also used then this is prefixed by either \"pack\\t\", or \"keep\\t\" if a\n new .keep file was successfully created. This is useful to remove a\n .keep file used as a lock to prevent the race with 'git-repack'\ndiff --git a/Documentation/git-ls-files.txt b/Documentation/git-ls-files.txt\nindex 057a021..1f1ce15 100644\n--- a/Documentation/git-ls-files.txt\n+++ b/Documentation/git-ls-files.txt\n@@ -146,7 +146,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 index 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 123e6d0..d7262ff 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-pack-objects.txt b/Documentation/git-pack-objects.txt\nindex 7d4c1a7..fbbea99 100644\n--- a/Documentation/git-pack-objects.txt\n+++ b/Documentation/git-pack-objects.txt\n@@ -47,7 +47,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 the sorted object names to make the resulting filename\n \tbased on the pack content, and written to the standard\n \toutput of the command.\ndiff --git a/Documentation/git-patch-id.txt b/Documentation/git-patch-id.txt\nindex 253fc0f..e37c815 100644\n--- a/Documentation/git-patch-id.txt\n+++ b/Documentation/git-patch-id.txt\n@@ -11,7 +11,7 @@ SYNOPSIS\n \n DESCRIPTION\n -----------\n-A \"patch ID\" is nothing but a SHA1 of the diff associated with a patch, with\n+A \"patch ID\" is nothing but a SHA-1 of the diff associated with a patch, with\n whitespace and line numbers ignored.  As such, it's \"reasonably stable\", but at\n the same time also reasonably unique, i.e., two patches that have the same \"patch\n ID\" are almost guaranteed to be the same thing.\ndiff --git a/Documentation/git-rev-parse.txt b/Documentation/git-rev-parse.txt\nindex 5ed2bc8..9fa0622 100644\n--- a/Documentation/git-rev-parse.txt\n+++ b/Documentation/git-rev-parse.txt\n@@ -72,7 +72,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@@ -122,7 +122,7 @@ OPTIONS\n \n --short::\n --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@@ -144,12 +144,12 @@ 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.  Here are various ways to spell object names.  The\n ones listed near the end of this list are to name trees and\n blobs contained in a commit.\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 7e9ff37..1259058 100644\n--- a/Documentation/git-show-branch.txt\n+++ b/Documentation/git-show-branch.txt\n@@ -29,7 +29,7 @@ no <rev> nor <glob> is given on the command line.\n OPTIONS\n -------\n <rev>::\n-\tArbitrary extended SHA1 expression (see linkgit:git-rev-parse[1])\n+\tArbitrary extended SHA-1 expression (see linkgit:git-rev-parse[1])\n \tthat typically names a branch head or a tag.\n \n <glob>::\n@@ -123,7 +123,7 @@ displayed, indented N places.  If a commit is on the I-th\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-show-index.txt b/Documentation/git-show-index.txt\nindex e3285aa..d30dd25 100644\n--- a/Documentation/git-show-index.txt\n+++ b/Documentation/git-show-index.txt\n@@ -18,7 +18,7 @@ Reads given idx file for packed git archive created with\n \n The information it outputs is subset of what you can get from\n 'git-verify-pack -v'; this command only shows the packfile\n-offset and SHA1 of each object.\n+offset and SHA-1 of each object.\n \n \n Author\ndiff --git a/Documentation/git-show-ref.txt b/Documentation/git-show-ref.txt\nindex 2f173ff..5dedffb 100644\n--- a/Documentation/git-show-ref.txt\n+++ b/Documentation/git-show-ref.txt\n@@ -50,8 +50,8 @@ OPTIONS\n -s::\n --hash::\n \n-\tOnly show the SHA1 hash, not the reference name. When also using\n-\t--dereference the dereferenced tag will still be shown after the SHA1.\n+\tOnly show the SHA-1 hash, not the reference name. When also using\n+\t--dereference the dereferenced tag will still be shown after the SHA-1.\n \n --verify::\n \ndiff --git a/Documentation/git-tag.txt b/Documentation/git-tag.txt\nindex fa73321..b93248c 100644\n--- a/Documentation/git-tag.txt\n+++ b/Documentation/git-tag.txt\n@@ -30,7 +30,7 @@ in the tag message.\n If `-m <msg>` or `-F <file>` is given and `-a`, `-s`, and `-u <key-id>`\n are absent, `-a` is implied.\n \n-Otherwise just the SHA1 object name of the commit object is\n+Otherwise just the SHA-1 object name of the commit object is\n written (i.e. a lightweight tag).\n \n A GnuPG signed tag object will be created when `-s` or `-u\ndiff --git a/Documentation/git-update-index.txt b/Documentation/git-update-index.txt\nindex ab98949..b946b02 100644\n--- a/Documentation/git-update-index.txt\n+++ b/Documentation/git-update-index.txt\n@@ -225,7 +225,7 @@ $ git update-index --index-info\n ------------\n \n The first line of the input feeds 0 as the mode to remove the\n-path; the SHA1 does not matter as long as it is well formatted.\n+path; the SHA-1 does not matter as long as it is well formatted.\n Then the second and third line feeds stage 1 and stage 2 entries\n for that path.  After the above, we would end up with this:\n \ndiff --git a/Documentation/git-verify-pack.txt b/Documentation/git-verify-pack.txt\nindex c861163..1942cd0 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 size-in-pack-file offset-in-packfile\n+\tSHA-1 type size size-in-pack-file offset-in-packfile\n \n for objects that are not deltified in the pack, and\n \n-\tSHA1 type size size-in-packfile offset-in-packfile depth base-SHA1\n+\tSHA-1 type size size-in-packfile 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 84e70a0..fa92728 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 'git-tag'.\n OPTIONS\n -------\n <tag>...::\n-\tSHA1 identifiers of git tag objects.\n+\tSHA-1 identifiers of git tag objects.\n \n Author\n ------\ndiff --git a/Documentation/git.txt b/Documentation/git.txt\nindex 5d2d5b7..af12570 100644\n--- a/Documentation/git.txt\n+++ b/Documentation/git.txt\n@@ -505,7 +505,7 @@ where:\n \n \t<old|new>-file:: are files GIT_EXTERNAL_DIFF can use to read the\n                          contents of <old|new>,\n-\t<old|new>-hex:: are the 40-hexdigit SHA1 hashes,\n+\t<old|new>-hex:: are the 40-hexdigit SHA-1 hashes,\n \t<old|new>-mode:: are the octal representation of the file modes.\n \n +\n@@ -595,7 +595,7 @@ The commit, equivalent to what other systems call a \"changeset\" or\n represents an immediately preceding step.  Commits with more than one\n parent represent merges of independent lines of development.\n \n-All objects are named by the SHA1 hash of their contents, normally\n+All objects are named by the SHA-1 hash of their contents, normally\n written as a string of 40 hex digits.  Such names are globally unique.\n The entire history leading up to a commit can be vouched for by signing\n just that commit.  A fourth object type, the tag, is provided for this\n@@ -605,9 +605,9 @@ When first created, objects are stored in individual files, but for\n efficiency may later be compressed together into \"pack files\".\n \n Named pointers called refs mark interesting points in history.  A ref\n-may contain the SHA1 name of an object or the name of another ref.  Refs\n-with names beginning `ref/head/` contain the SHA1 name of the most\n-recent commit (or \"head\") of a branch under development.  SHA1 names of\n+may contain the SHA-1 name of an object or the name of another ref.  Refs\n+with names beginning `ref/head/` contain the SHA-1 name of the most\n+recent commit (or \"head\") of a branch under development.  SHA-1 names of\n tags of interest are stored under `ref/tags/`.  A special ref named\n `HEAD` contains the name of the currently checked-out branch.\n \ndiff --git a/Documentation/gitcore-tutorial.txt b/Documentation/gitcore-tutorial.txt\nindex 7ba5e58..a204fdf 100644\n--- a/Documentation/gitcore-tutorial.txt\n+++ b/Documentation/gitcore-tutorial.txt\n@@ -98,9 +98,9 @@ branch. A number of the git tools will assume that `.git/HEAD` is\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@@ -755,7 +755,7 @@ already discussed, the `HEAD` branch is nothing but a symlink to one of\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@@ -1226,7 +1226,7 @@ file (the first tree goes to stage 1, the second to stage 2,\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/gitdiffcore.txt b/Documentation/gitdiffcore.txt\nindex e8041bc..a36e8d8 100644\n--- a/Documentation/gitdiffcore.txt\n+++ b/Documentation/gitdiffcore.txt\n@@ -107,7 +107,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/githooks.txt b/Documentation/githooks.txt\nindex 1c73673..4862044 100644\n--- a/Documentation/githooks.txt\n+++ b/Documentation/githooks.txt\n@@ -96,7 +96,7 @@ given); `template` (if a `-t` option was given or the\n configuration option `commit.template` is set); `merge` (if the\n commit is a merge or a `.git/MERGE_MSG` file exists); `squash`\n (if a `.git/SQUASH_MSG` file exists); or `commit`, followed by\n-a commit SHA1 (if a `-c`, `-C` or `\\--amend` option was given).\n+a commit SHA-1 (if a `-c`, `-C` or `\\--amend` option was given).\n \n If the exit status is non-zero, 'git-commit' will abort.\n \ndiff --git a/Documentation/gittutorial-2.txt b/Documentation/gittutorial-2.txt\nindex dc8fc3a..4fb0275 100644\n--- a/Documentation/gittutorial-2.txt\n+++ b/Documentation/gittutorial-2.txt\n@@ -45,9 +45,9 @@ What are the 7 digits of hex that git responded to the commit 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-a 40-digit hex name.  That name is the SHA1 hash of the object's\n+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). The 7 char hex strings\n here are simply the abbreviation of such 40 character long strings.\n@@ -55,7 +55,7 @@ Abbreviations can be used everywhere where the 40 character strings\n can be used, so long as they are unambiguous.\n \n It is expected that the content of the commit object you created while\n-following the example above generates a different SHA1 hash than\n+following the example above generates a different SHA-1 hash than\n the one shown above because the commit object records the time when\n it was created and the name of the person performing the commit.\n \n@@ -79,14 +79,14 @@ A tree can refer to one or more \"blob\" objects, each corresponding to\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@@ -105,7 +105,7 @@ Note that this is the old file data; so the object that git named in\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@@ -141,7 +141,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@@ -207,7 +207,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 \ndiff --git a/Documentation/glossary-content.txt b/Documentation/glossary-content.txt\nindex 572374f..558107f 100644\n--- a/Documentation/glossary-content.txt\n+++ b/Documentation/glossary-content.txt\n@@ -229,7 +229,7 @@ This commit is referred to as a \"merge commit\", or sometimes just a\n \n [[def_object]]object::\n \tThe unit of storage in git. It is uniquely identified by the\n-\t<<def_SHA1,SHA1>> of its contents. Consequently, an\n+\t<<def_SHA1,SHA-1>> of its contents. Consequently, an\n \tobject can not be changed.\n \n [[def_object_database]]object database::\n@@ -326,7 +326,7 @@ This commit is referred to as a \"merge commit\", or sometimes just a\n \tto the result.\n \n [[def_ref]]ref::\n-\tA 40-byte hex representation of a <<def_SHA1,SHA1>> or a name that\n+\tA 40-byte hex representation of a <<def_SHA1,SHA-1>> or a name that\n \tdenotes a particular <<def_object,object>>. These may be stored in\n \t`$GIT_DIR/refs/`.\n \n@@ -373,7 +373,7 @@ This commit is referred to as a \"merge commit\", or sometimes just a\n [[def_SCM]]SCM::\n \tSource code management (tool).\n \n-[[def_SHA1]]SHA1::\n+[[def_SHA1]]SHA-1::\n \tSynonym for <<def_object_name,object name>>.\n \n [[def_shallow_repository]]shallow repository::\n@@ -388,7 +388,7 @@ This commit is referred to as a \"merge commit\", or sometimes just a\n \tits history can be later deepened with linkgit:git-fetch[1].\n \n [[def_symref]]symref::\n-\tSymbolic reference: instead of containing the <<def_SHA1,SHA1>>\n+\tSymbolic reference: instead of containing the <<def_SHA1,SHA-1>>\n \tid itself, it is of the format 'ref: refs/some/thing' and when\n \treferenced, it recursively dereferences to this reference.\n \t'<<def_HEAD,HEAD>>' is a prime example of a symref. Symbolic\ndiff --git a/Documentation/howto/recover-corrupted-blob-object.txt b/Documentation/howto/recover-corrupted-blob-object.txt\nindex 323b513..0fc7013 100644\n--- a/Documentation/howto/recover-corrupted-blob-object.txt\n+++ b/Documentation/howto/recover-corrupted-blob-object.txt\n@@ -9,7 +9,7 @@ On Fri, 9 Nov 2007, Yossi Leybovich wrote:\n > Did not help still the repository look for this object?\n > Any one know how can I track this object and understand which file is it\n \n-So exactly *because* the SHA1 hash is cryptographically secure, the hash\n+So exactly *because* the SHA-1 hash is cryptographically secure, the hash\n itself doesn't actually tell you anything, in order to fix a corrupt\n object you basically have to find the \"original source\" for it.\n \n@@ -36,7 +36,7 @@ So:\n > ib]$ mv .git/objects/4b/9458b3786228369c63936db65827de3cc06200 ../\n \n This is the right thing to do, although it's usually best to save it under\n-it's full SHA1 name (you just dropped the \"4b\" from the result ;).\n+it's full SHA-1 name (you just dropped the \"4b\" from the result ;).\n \n Let's see what that tells us:\n \n@@ -79,7 +79,7 @@ working tree, in which case fixing this problem is really simple, just do\n \n \tgit hash-object -w my-magic-file\n \n-again, and if it outputs the missing SHA1 (4b945..) you're now all done!\n+again, and if it outputs the missing SHA-1 (4b945..) you're now all done!\n \n But that's the really lucky case, so let's assume that it was some older\n version that was broken. How do you tell which version it was?\ndiff --git a/Documentation/pretty-formats.txt b/Documentation/pretty-formats.txt\nindex fac8ebd..a480ea8 100644\n--- a/Documentation/pretty-formats.txt\n+++ b/Documentation/pretty-formats.txt\n@@ -70,7 +70,7 @@ This is designed to be as compact as possible.\n * 'raw'\n +\n The 'raw' format shows the entire commit exactly as\n-stored in the commit object.  Notably, the SHA1s are\n+stored in the commit object.  Notably, the SHA-1s are\n displayed in full, regardless of whether --abbrev or\n --no-abbrev are used, and 'parents' information show the\n true parent commits, without taking grafts nor history\ndiff --git a/Documentation/technical/pack-format.txt b/Documentation/technical/pack-format.txt\nindex 1803e64..4ce3534 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 = Original (version 1) pack-*.idx files have the following format:\n \n@@ -53,10 +53,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@@ -104,7 +104,7 @@ 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 REF_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.\n \tIf it is OFS_DELTA, then\n@@ -133,7 +133,7 @@ Pack file entry: <+\n \n   - A 256-entry fan-out table just like v1.\n \n-  - A table of sorted 20-byte SHA1 object names.  These are\n+  - A table of sorted 20-byte SHA-1 object names.  These are\n     packed together without offset values to reduce the cache\n     footprint of the binary search for a specific object name.\n \n@@ -154,7 +154,7 @@ Pack file entry: <+\n \n   - The same trailer as a v1 pack file:\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.\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) protocol:\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.\ndiff --git a/Documentation/technical/shallow.txt b/Documentation/technical/shallow.txt\nindex 559263a..73214c3 100644\n--- a/Documentation/technical/shallow.txt\n+++ b/Documentation/technical/shallow.txt\n@@ -2,7 +2,7 @@ Def.: Shallow commits do have parents, but not in the shallow\n repo, and therefore grafts are introduced pretending that\n these commits have no parents.\n \n-The basic idea is to write the SHA1s of shallow commits into\n+The basic idea is to write the SHA-1s of shallow commits into\n $GIT_DIR/shallow, and handle its contents like the contents\n of $GIT_DIR/info/grafts (with the difference that shallow\n cannot contain parent information).\n@@ -12,7 +12,7 @@ even the config, since the user should not touch that file\n at all (even throughout development of the shallow clone, it\n was never manually edited!).\n \n-Each line contains exactly one SHA1. When read, a commit_graft\n+Each line contains exactly one SHA-1. When read, a commit_graft\n will be constructed, which has nr_parent < 0 to make it easier\n to discern from user provided grafts.\n \n-- \n1.6.3.rc1.51.gea0b7\n"},{"id":"112198","messageId":"49F1D857.7060100@viscovery.net","threadId":"19046","inReplyTo":"1240584575-5702-2-git-send-email-git@drmicha.warpmail.net","subject":"Re: [PATCH 1/2] Documentation: replace sha1 by SHA-1","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2009-04-24T15:18:47Z","receivedAt":"2009-04-24T15:18:47Z","isPatch":true,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Michael J Gruber schrieb:\n> diff --git a/Documentation/git-fsck.txt b/Documentation/git-fsck.txt\n> index 287c4fc..73e1dc4 100644\n> --- a/Documentation/git-fsck.txt\n> +++ b/Documentation/git-fsck.txt\n\nThese hunks are in a section that talks about fsck's diagnostics.\n\n> +missing SHA-1 directory '<dir>'::\n> +\tThe directory holding the SHA-1 objects is missing.\n\nThis message does not present in the code anywhere; it could be removed\nfrom this list.\n\n> +SHA-1 mismatch <object>::\n\nAnd this one occurs in the code, and so it should be changed as well.\n\n> +\tThe database has an object who's SHA-1 doesn't match the\n\n-- Hannes\n"},{"id":"112201","messageId":"5A5A3681-08E7-4343-BBB1-B1CB52D8B492@wincent.com","threadId":"19046","inReplyTo":"49F1D857.7060100@viscovery.net","subject":"Re: [PATCH 1/2] Documentation: replace sha1 by SHA-1","fromName":"Wincent Colaiuta","fromEmail":"win@wincent.com","sentAt":"2009-04-24T15:23:21Z","receivedAt":"2009-04-24T15:23:21Z","isPatch":true,"sender":{"key":"greg@hurrell.net","avatar":"https://avatars.githubusercontent.com/u/7074?v=4"},"body":"El 24/4/2009, a las 17:18, Johannes Sixt escribió:\n\n> Michael J Gruber schrieb:\n>>\n>> +\tThe database has an object who's SHA-1 doesn't match the\n\nNot related to SHA1 vs SHA-1, but:\n\ns/who's/whose/\n\nCheers,\nWincent\n"},{"id":"112204","messageId":"49F1DB26.1070605@drmicha.warpmail.net","threadId":"19046","inReplyTo":"49F1D857.7060100@viscovery.net","subject":"Re: [PATCH 1/2] Documentation: replace sha1 by SHA-1","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2009-04-24T15:30:46Z","receivedAt":"2009-04-24T15:30:46Z","isPatch":true,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Johannes Sixt venit, vidit, dixit 24.04.2009 17:18:\n> Michael J Gruber schrieb:\n>> diff --git a/Documentation/git-fsck.txt b/Documentation/git-fsck.txt\n>> index 287c4fc..73e1dc4 100644\n>> --- a/Documentation/git-fsck.txt\n>> +++ b/Documentation/git-fsck.txt\n> \n> These hunks are in a section that talks about fsck's diagnostics.\n\nYes. I didn't notice they were actual warning message quotes though.\nThanks for catching it.\n\n> \n>> +missing SHA-1 directory '<dir>'::\n>> +\tThe directory holding the SHA-1 objects is missing.\n> \n> This message does not present in the code anywhere; it could be removed\n> from this list.\n\nYes, that should be a patch before 1/2 then.\n\n> \n>> +SHA-1 mismatch <object>::\n> \n> And this one occurs in the code, and so it should be changed as well.\n\nIt comes from object.c rather than builtin-fsck.c, right?\n\nI guess it shows that I should go through the code as well. But it's not\na good time for that now... (rc) I'll revert that specific change then.\n\nMichael\n"},{"id":"112206","messageId":"49F1DBC5.4070305@drmicha.warpmail.net","threadId":"19046","inReplyTo":"5A5A3681-08E7-4343-BBB1-B1CB52D8B492@wincent.com","subject":"Re: [PATCH 1/2] Documentation: replace sha1 by SHA-1","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2009-04-24T15:33:25Z","receivedAt":"2009-04-24T15:33:25Z","isPatch":true,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Wincent Colaiuta venit, vidit, dixit 24.04.2009 17:23:\n> El 24/4/2009, a las 17:18, Johannes Sixt escribió:\n> \n>> Michael J Gruber schrieb:\n>>>\n>>> +\tThe database has an object who's SHA-1 doesn't match the\n> \n> Not related to SHA1 vs SHA-1, but:\n> \n> s/who's/whose/\n\nYes, but I refrained from doing \"while we're at it\" stuff. The only\nother changes besides sha1/SHA-1 etc. are replacing e.g. \"oldsha1\" by\n\"SHA-1-old\" and \"sha1's\" by \"SHA-1s\" for the plural.\n\nMichael\n"},{"id":"112238","messageId":"20090424212856.GB14435@coredump.intra.peff.net","threadId":"19046","inReplyTo":"1240584575-5702-2-git-send-email-git@drmicha.warpmail.net","subject":"Re: [PATCH 1/2] Documentation: replace sha1 by SHA-1","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-04-24T21:28:56Z","receivedAt":"2009-04-24T21:28:56Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Apr 24, 2009 at 04:49:34PM +0200, Michael J Gruber wrote:\n\n> --- a/Documentation/git-cat-file.txt\n> +++ b/Documentation/git-cat-file.txt\n> @@ -76,7 +76,7 @@ If '--batch' is specified, output of the following form is printed for each\n>  object specified on stdin:\n>  \n>  ------------\n> -<sha1> SP <type> SP <size> LF\n> +<SHA-1> SP <type> SP <size> LF\n>  <contents> LF\n>  ------------\n\nMaybe it is just me, but I find the original for this one easier to\nread. Perhaps because <sha1> is really a variable name here (but for a\nhuman reader to interpret instead of a compiler), so I find the\npunctuation and capitalization distracting.\n\nI wonder if all <sha1> should simply be left as-is.\n\n-Peff\n"},{"id":"112239","messageId":"20090424213056.GC14435@coredump.intra.peff.net","threadId":"19046","inReplyTo":"1240584575-5702-3-git-send-email-git@drmicha.warpmail.net","subject":"Re: [PATCH 2/2] Documentation: replace SHA1 by SHA-1","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-04-24T21:30:56Z","receivedAt":"2009-04-24T21:30:56Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Apr 24, 2009 at 04:49:35PM +0200, Michael J Gruber wrote:\n\n> --- a/Documentation/git-pack-objects.txt\n> +++ b/Documentation/git-pack-objects.txt\n> @@ -47,7 +47,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 the sorted object names to make the resulting filename\n>  \tbased on the pack content, and written to the standard\n>  \toutput of the command.\n\nSame complaint as the last patch. The extra hyphen is really\ndistracting, as it is in the midst of an already hyphenated filename.\nInterestingly, I don't find <base-name> as bad. I think it is because\nthe single numeric character with the punctuation is just hard on the\neyes.\n\n-Peff\n"},{"id":"112251","messageId":"7vzle5ad8n.fsf@gitster.siamese.dyndns.org","threadId":"19046","inReplyTo":"20090424212856.GB14435@coredump.intra.peff.net","subject":"Re: [PATCH 1/2] Documentation: replace sha1 by SHA-1","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-04-24T22:38:48Z","receivedAt":"2009-04-24T22:38:48Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> On Fri, Apr 24, 2009 at 04:49:34PM +0200, Michael J Gruber wrote:\n>\n>> --- a/Documentation/git-cat-file.txt\n>> +++ b/Documentation/git-cat-file.txt\n>> @@ -76,7 +76,7 @@ If '--batch' is specified, output of the following form is printed for each\n>>  object specified on stdin:\n>>  \n>>  ------------\n>> -<sha1> SP <type> SP <size> LF\n>> +<SHA-1> SP <type> SP <size> LF\n>>  <contents> LF\n>>  ------------\n>\n> Maybe it is just me, but I find the original for this one easier to\n> read. Perhaps because <sha1> is really a variable name here (but for a\n> human reader to interpret instead of a compiler), so I find the\n> punctuation and capitalization distracting.\n>\n> I wonder if all <sha1> should simply be left as-is.\n\nOr spell them using their official terminology \"object name\".\n\nIn all places in the documentation these two patches touch, that is what\nmatters.  They are computed by taking a hash over a defined format, and\nthe hash function we use happens to be SHA-1, but that is not important to\nsomebody who wants to use \"cat-file\" nor even to somebody who wants to\nreimplement it.  I think hash-object should mention what the actual hash\nfunction is, but even that should not stress the SHA-1-ness of the hash.\nThat's just too much implementation detail.\n\nAnd sha1 and SHA1 are both accepted colloquial forms of \"object name\" in\nthe git world.  I think it is Ok to leave it in the IRC transcript \"pack\nheuristics\" documentation (and I'd prefer that particular one left\nuntouched).  If we want to go formal in the documentation, I think\nrewriting them to SHA-1 misses the point.\n"},{"id":"112291","messageId":"94a0d4530904250347s55a66f47gbaaf5ea42d0c4eac@mail.gmail.com","threadId":"19046","inReplyTo":"7vzle5ad8n.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH 1/2] Documentation: replace sha1 by SHA-1","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2009-04-25T10:47:42Z","receivedAt":"2009-04-25T10:47:42Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Sat, Apr 25, 2009 at 1:38 AM, Junio C Hamano <gitster@pobox.com> wrote:\n> Jeff King <peff@peff.net> writes:\n>\n>> On Fri, Apr 24, 2009 at 04:49:34PM +0200, Michael J Gruber wrote:\n>>\n>>> --- a/Documentation/git-cat-file.txt\n>>> +++ b/Documentation/git-cat-file.txt\n>>> @@ -76,7 +76,7 @@ If '--batch' is specified, output of the following form is printed for each\n>>>  object specified on stdin:\n>>>\n>>>  ------------\n>>> -<sha1> SP <type> SP <size> LF\n>>> +<SHA-1> SP <type> SP <size> LF\n>>>  <contents> LF\n>>>  ------------\n>>\n>> Maybe it is just me, but I find the original for this one easier to\n>> read. Perhaps because <sha1> is really a variable name here (but for a\n>> human reader to interpret instead of a compiler), so I find the\n>> punctuation and capitalization distracting.\n>>\n>> I wonder if all <sha1> should simply be left as-is.\n>\n> Or spell them using their official terminology \"object name\".\n\nWhy is the \"official\" terminology \"object name\", wouldn't \"id\" work better?\n\nSHA-1 is simply one hash function, what git has been referring to\n\"sha1\" is actually the SHA-1 digest. This digest has been used as a\nchecksum (or hash sum) but also as a unique identifier, therefore \"id\"\nwould work just fine.\n\n-- \nFelipe Contreras\n"},{"id":"112299","messageId":"20090425121307.GA20459@dpotapov.dyndns.org","threadId":"19046","inReplyTo":"1240584575-5702-2-git-send-email-git@drmicha.warpmail.net","subject":"Re: [PATCH 1/2] Documentation: replace sha1 by SHA-1","fromName":"Dmitry Potapov","fromEmail":"dpotapov@gmail.com","sentAt":"2009-04-25T12:13:07Z","receivedAt":"2009-04-25T12:13:07Z","isPatch":true,"sender":{"key":"dpotapov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/6568595?v=4"},"body":"On Fri, Apr 24, 2009 at 04:49:34PM +0200, Michael J Gruber wrote:\n> Replace sha1 by SHA-1 with the following exceptions:\n\nI seriously doubt that mentioning any particular hash algorithm (which\nis implementation detail) in so many places make much sense.  IMHO, it\nwould be much better to use some general name as hash-id or something.\n\nBesides, mentioning SHA-1 may lead to confusion. Take a look at the\nfollowing text:\n\n> @@ -164,10 +164,10 @@ Using --cacheinfo or --info-only\n>  current working directory.  This is useful for minimum-checkout\n>  merging.\n>  \n> -To pretend you have a file with mode and sha1 at path, say:\n> +To pretend you have a file with mode and SHA-1 at path, say:\n>  \n>  ----------------\n> -$ git update-index --cacheinfo mode sha1 path\n> +$ git update-index --cacheinfo mode SHA-1 path\n>  ----------------\n\nThis is incorrect, and here is why:\n\n$ touch empty\n$ git hash-object empty\ne69de29bb2d1d6434b8b29ae775ad8c2e48c5391\n$ sha1sum empty\nda39a3ee5e6b4b0d3255bfef95601890afd80709  empty\n\nWhat should be given to git update-index is the hash produced by git\nhash-object and NOT SHA-1 of the file. (Yes, git hash-object does use\nSHA-1, but I seriously doubt that any Git user needs to know how git\nhash-object calculates the hash.)\n\nSo, I hardly see how a mechanical replacement of sha1 with SHA-1 can be\nany improvement. While, at least, sha1 can be interpreted as SHA-1 based\nhash value returned by git-hash-object, your patch only enforces the\nmisconception that we are dealing with SHA-1 of the file here.\n\n\nDmitry\n"}]}