Documentation: SHA-1 iso. SHA1

Per https://tools.ietf.org/html/rfc3174, the name of the hash is SHA-1.
The Git man page agrees as well.

Change-Id: I7c7f7a74a8a43a721f6a85f42eb6d92a2c1895cd

Documentation/config-accounts.txt

@@ -293,12 +293,12 @@ identity, to an account in Gerrit.
 External IDs are stored as Git Notes in the `All-Users` repository. The
 name of the notes branch is `refs/meta/external-ids`.
 
-As note key the SHA1 of the external ID key is used, for example the key
+As note key the SHA-1 of the external ID key is used, for example the key
 for the external ID `username:jdoe` is `e0b751ae90ef039f320e097d7d212f490e933706`.
 This ensures that an external ID is used only once (e.g. an external ID can
 never be assigned to multiple accounts at a point in time).
 
-The following commands show how to find the SHA1 of an external ID:
+The following commands show how to find the SHA-1 of an external ID:
 
 ----
 $ echo -n 'gerrit:jdoe' | shasum
@@ -310,7 +310,7 @@ e0b751ae90ef039f320e097d7d212f490e933706  -
 
 [IMPORTANT]
 If the external ID key is changed manually you must adapt the note key
-to the new SHA1, otherwise the external ID becomes inconsistent and is
+to the new SHA-1, otherwise the external ID becomes inconsistent and is
 ignored by Gerrit.
 
 The note content is a Git config file:
@@ -322,7 +322,7 @@ The note content is a Git config file:
   password = bcrypt:4:LCbmSBDivK/hhGVQMfkDpA==:XcWn0pKYSVU/UJgOvhidkEtmqCp6oKB7
 ----
 
-Once SHA1 of an external ID is known the following command can be used to
+Once SHA-1 of an external ID is known the following command can be used to
 show the content of the note:
 
 ----

Documentation/config-gerrit.txt

@@ -2451,7 +2451,7 @@ Optional pattern to use for constructing the gitweb URL when pointing
 at a specific commit when `gitweb.type` is set to `custom`.
 +
 Valid replacements are `${project}` for the project name in Gerrit
-and `${commit}` for the SHA1 hash for the commit.
+and `${commit}` for the SHA-1 hash for the commit.
 
 [[gitweb.project]]gitweb.project::
 +
@@ -2483,7 +2483,7 @@ at the contents of the root tree in a specific commit when `gitweb.type`
 is set to `custom`.
 +
 Valid replacements are `${project}` for the project name in Gerrit
-and `${commit}` for the SHA1 hash for the commit.
+and `${commit}` for the SHA-1 hash for the commit.
 
 [[gitweb.file]]gitweb.file::
 +
@@ -2492,7 +2492,7 @@ at the contents of a file in a specific commit when `gitweb.type` is
 set to `custom`.
 +
 Valid replacements are `${project}` for the project name in Gerrit,
-`${file}` for the file name and `${commit}` for the SHA1 hash for
+`${file}` for the file name and `${commit}` for the SHA-1 hash for
 the commit.
 
 [[gitweb.filehistory]]gitweb.filehistory::
@@ -4196,7 +4196,7 @@ Carrying out this check on gits with many refs and commits can be a
 very CPU-heavy operation. For non public Gerrit-servers this check may
 be overkill.
 +
-Only disable this check if you trust the clients not to forge SHA1
+Only disable this check if you trust the clients not to forge SHA-1
 references to access commits intended to be hidden from the user.
 +
 Default is true.

Documentation/config-groups.txt

@@ -64,7 +64,7 @@ branch with a flat list of files.
 
 The format of this map is as follows:
 
-* keys are the normal SHA1 of the group name
+* keys are the normal SHA-1 of the group name
 * values are blobs that look like
 +
 ----

Documentation/config-labels.txt

@@ -353,7 +353,7 @@ Defaults to false.
 If true, all scores for the label are copied forward when a new patch
 set is uploaded that has the same parent tree, code delta, and commit
 message as the previous patch set. This means that only the patch
-set SHA1 is different. This can be used to enable sticky
+set SHA-1 is different. This can be used to enable sticky
 approvals, reducing turn-around for this special case.
 It is recommended to leave this enabled for both Verified and
 Code-Review labels.

Documentation/dev-design.txt

@@ -182,7 +182,7 @@ has read permission. This means that
   advertisement if the user lacks read permissions
 
 * Uploads through the git wire protocol must refuse commits that are
-  based on SHA1s for data that the user can't see.
+  based on SHA-1s for data that the user can't see.
 
 * Tags are only visible if their commits are visible to user through a
   non-tag reference.
@@ -195,7 +195,7 @@ metadata or allow changes to them.
 === Indexing
 
 Almost all data is stored as Git, but Git only supports fast lookup by
-SHA1 or by ref (branch) name. Therefore Gerrit also has an indexing
+SHA-1 or by ref (branch) name. Therefore Gerrit also has an indexing
 system (powered by Lucene by default) for other types of queries.
 There are 4 indices:
 
@@ -204,8 +204,8 @@ There are 4 indices:
 * Group index - find groups by name, owner, description etc.
 * Change index - find changes by file, status, modification date etc.
 
-The base entities are characterized by SHA1s. Storing the
+The base entities are characterized by SHA-1s. Storing the
-characterizing SHA1s allows detection of stale index entries.
+characterizing SHA-1s allows detection of stale index entries.
 
 == Plug-in architecture
 
@@ -397,7 +397,7 @@ these for latency, using the following techniques:
 * Caching: metadata is stored in Git, which is relatively expensive to
   access. This is sped up by multiple caches. Metadata entities are
   stored in Git, and can therefore be seen as immutable values keyed
-  by SHA1, which is very amenable to caching. All SHA1 keyed caches
+  by SHA-1, which is very amenable to caching. All SHA-1 keyed caches
   can be persisted on local disk.
 
   The size (memory, disk) of these caches should be adapted to the

Documentation/dev-plugins.txt

@@ -2230,7 +2230,7 @@ Gerrit has extension points that enables development of a
 light-weight plugin that links commits to external
 tools (GitBlit, CGit, company specific resources etc).
 
-PatchSetWebLinks will appear to the right of the commit-SHA1 in the UI.
+PatchSetWebLinks will appear to the right of the commit-SHA-1 in the UI.
 
 [source, java]
 ----
@@ -2256,7 +2256,7 @@ public class MyWeblinkPlugin implements PatchSetWebLink {
 }
 ----
 
-ParentWebLinks will appear to the right of the SHA1 of the parent
+ParentWebLinks will appear to the right of the SHA-1 of the parent
 revisions in the UI. The implementation should in most use cases direct
 to the same external service as PatchSetWebLink; it is provided as a
 separate interface because not all users want to have links for the

Documentation/intro-gerrit-walkthrough-github.txt

@@ -206,8 +206,8 @@ you currently have checked out.
 When you `git commit --amend` to iterate on your change, you might be worried that
 you are changing your previous commit and may thus lose that state of your work.
 However, here the Change-Id appended to your commit message comes into play.
-While the SHA1 hash of your change (the commit ID used by Git) might change, the
+While the SHA-1 hash of your change (the commit ID used by Git) might change, the
-Change-Id stays the same (in fact it is the SHA1 hash of the very first version
+Change-Id stays the same (in fact it is the SHA-1 hash of the very first version
 of that commit). When this amended commit is uploaded to the Gerrit server,
 Gerrit knows that this commit is really an iteration of that previous commit
 (and the associated review) and will preserve both, the old and the new state.

Documentation/rest-api-changes.txt

@@ -565,8 +565,8 @@ describes the change.
 ----
 
 Historical state of the change can be retrieved by specifying the
-`meta=SHA1` parameter. This will use a historical NoteDb snapshot to
+`meta=SHA-1` parameter. This will use a historical NoteDb snapshot to
-populate ChangeInfo. If the SHA1 is not reachable as a NoteDb state,
+populate ChangeInfo. If the SHA-1 is not reachable as a NoteDb state,
 status code 412 is returned.
 
 ----
@@ -574,14 +574,14 @@ status code 412 is returned.
 [[get-meta-diff]]
 === Get Meta Diff
 --
-'GET /changes/link:#change-id[\{change-id\}]/meta_diff/?old=SHA1&meta=SHA1'
+'GET /changes/link:#change-id[\{change-id\}]/meta_diff/?old=SHA-1&meta=SHA-1'
 --
 
 Retrieves the difference between two historical states of a change
-by specifying the `old=SHA1` and the `meta=SHA1` parameters.
+by specifying the `old=SHA-1` and the `meta=SHA-1` parameters.
 
 If the `old` parameter is not provided, the parent of the `meta`
-SHA1 is used. If the `meta` parameter is not provided, the current
+SHA-1 is used. If the `meta` parameter is not provided, the current
 state of the change is used. If neither are provided, the
 difference between the current state of the change and its previous
 state is returned.
@@ -627,8 +627,8 @@ Only fields that differ between the change's two states are returned.
   }
 ----
 
-If the provided SHA1 for `meta` is not reachable as a NoteDb
+If the provided SHA-1 for `meta` is not reachable as a NoteDb
-state, the status code 412 is returned. If the SHA1 for `old`
+state, the status code 412 is returned. If the SHA-1 for `old`
 is not reachable, the difference between the change at state
 `meta` and an empty change is returned.
 ----
@@ -1203,7 +1203,7 @@ If the change had no assignee the response is "`204 No Content`".
 --
 
 Check if the given change is a pure revert of the change it references in `revertOf`.
-Optionally, the query parameter `o` can be passed in to specify a commit (SHA1 in
+Optionally, the query parameter `o` can be passed in to specify a commit (SHA-1 in
 40 digit hex representation) to check against. It takes precedence over `revertOf`.
 If the change has no reference in `revertOf`, the parameter is mandatory.
 
@@ -6541,7 +6541,7 @@ Only set if link:#current-revision[the current revision] is requested
 (in which case it will only contain a key for the current revision) or
 if link:#all-revisions[all revisions] are requested.
 |`meta_rev_id`           |optional|
-The SHA1 of the NoteDb meta ref.
+The SHA-1 of the NoteDb meta ref.
 |`tracking_ids`       |optional|
 A list of link:#tracking-id-info[TrackingIdInfo] entities describing
 references to external tracking systems. Only set if
@@ -6779,7 +6779,7 @@ Available with the link:#list-change-comments[list change comments] endpoint.
 Contains the link:rest-api-changes.html#change-message-info[id] of the change
 message that this comment is linked to.
 |`commit_id` |optional|
-Hex commit SHA1 (40 characters string) of the commit of the patchset to which
+Hex commit SHA-1 (40 characters string) of the commit of the patchset to which
 this comment applies.
 |`context_lines` |optional|
 A list of link:#context-line[ContextLine] containing the lines of the source
@@ -7571,7 +7571,7 @@ The `RebaseInput` entity contains information for changing parent when rebasing.
 |===========================
 |Field Name    ||Description
 |`base`        |optional|
-The new parent revision. This can be a ref or a SHA1 to a concrete patchset. +
+The new parent revision. This can be a ref or a SHA-1 to a concrete patchset. +
 Alternatively, a change number can be specified, in which case the current
 patch set is inferred. +
 Empty string is used for rebasing directly on top of the target branch,

Documentation/user-inline-edit.txt

@@ -38,11 +38,11 @@ image::images/inline-edit-create-change.png[width=350]
    *  Select branch for new change: Specify the destination branch of the
       change.
 
-   *  Provide base commit SHA1 for change: Leave this field blank.
+   *  Provide base commit SHA-1 for change: Leave this field blank.
 
 +
-IMPORTANT: Git uses a unique SHA1 value to identify each and every commit (in
+IMPORTANT: Git uses a unique SHA-1 value to identify each and every commit (in
-other words, each Git commit generates a new SHA1 hash). This value differs
+other words, each Git commit generates a new SHA-1 hash). This value differs
 from a Gerrit Change-Id, which is used by Gerrit to uniquely identify a
 change. The Gerrit Change-Id remains static throughout the life of a Gerrit
 change.

Documentation/user-search.txt

@@ -35,7 +35,7 @@ text and let Gerrit figure out the meaning:
 |=============================================================
 
 For change searches (i.e. those using a numerical id, Change-Id, or commit
-SHA1), if the search results in a single change that change will be
+SHA-1), if the search results in a single change that change will be
 presented instead of a list.
 
 For more predictable results, use explicit search operators as described
@@ -173,9 +173,9 @@ reviewerin:'GROUP'::
 Changes that have been, or need to be, reviewed by a user in 'GROUP'.
 
 [[commit]]
-commit:'SHA1'::
+commit:'SHA-1'::
 +
-Changes where 'SHA1' is one of the patch sets of the change.
+Changes where 'SHA-1' is one of the patch sets of the change.
 
 [[project]]
 project:'PROJECT', p:'PROJECT'::