[PATCH] The hash name is SHA-1, use that throughout

["Horst H. von Brand" <vonbrand@inf.utfsm.cl>]

Signed-off-by: Horst H. von Brand <vonbrand@inf.utfsm.cl>
---
 Documentation/technical/pack-format.txt     |    8 ++++----
 Documentation/technical/pack-heuristics.txt |    4 ++--
 Documentation/technical/pack-protocol.txt   |   20 ++++++++++----------
 3 files changed, 16 insertions(+), 16 deletions(-)

diff --git a/Documentation/technical/pack-format.txt b/Documentation/technical/pack-format.txt
index 0e1ffb2..8823dce 100644
--- a/Documentation/technical/pack-format.txt
+++ b/Documentation/technical/pack-format.txt
@@ -32,7 +32,7 @@ GIT pack format
      Observation: length of each object is encoded in a variable
      length format and is not constrained to 32-bit or anything.
 
-  - The trailer records 20-byte SHA1 checksum of all of the above.
+  - The trailer records 20-byte SHA-1 checksum of all of the above.
 
 = pack-*.idx file has the following format:
 
@@ -61,10 +61,10 @@ GIT pack format
 
   - The file is concluded with a trailer:
 
-    A copy of the 20-byte SHA1 checksum at the end of
+    A copy of the 20-byte SHA-1 checksum at the end of
     corresponding packfile.
 
-    20-byte SHA1-checksum of all of the above.
+    20-byte SHA-1-checksum of all of the above.
 
 Pack Idx file:
 
@@ -111,6 +111,6 @@ Pack file entry: <+
         If it is not DELTA, then deflated bytes (the size above
 		is the size before compression).
 	If it is DELTA, then
-	  20-byte base object name SHA1 (the size above is the
+	  20-byte base object name SHA-1 (the size above is the
 	  	size of the delta data that follows).
           delta data, deflated.
diff --git a/Documentation/technical/pack-heuristics.txt b/Documentation/technical/pack-heuristics.txt
index 9aadd5c..458677e 100644
--- a/Documentation/technical/pack-heuristics.txt
+++ b/Documentation/technical/pack-heuristics.txt
@@ -77,7 +77,7 @@ And Bable-like confusion flowed.
 
     <njs`> oh, hmm, and I'm not sure what this sliding window means either
 
-    <pasky> iirc, it appeared to me to be just the sha1 of the object
+    <pasky> iirc, it appeared to me to be just the SHA-1 of the object
         when reading the code casually ...
 
         ... which simply doesn't sound as a very good heuristics, though ;)
@@ -89,7 +89,7 @@ Ah, grasshopper!  And thus the enlighten
 
     <linus> The "magic" is actually in theory totally arbitrary.
         ANY order will give you a working pack, but no, it's not
-        ordered by SHA1.
+        ordered by SHA-1.
 
         Before talking about the ordering for the sliding delta
         window, let's talk about the recency order. That's more
diff --git a/Documentation/technical/pack-protocol.txt b/Documentation/technical/pack-protocol.txt
index 9cd48b4..9df76e3 100644
--- a/Documentation/technical/pack-protocol.txt
+++ b/Documentation/technical/pack-protocol.txt
@@ -6,22 +6,22 @@ There are two Pack push-pull protocols.
 upload-pack (S) | fetch/clone-pack (C) protocol:
 
 	# Tell the puller what commits we have and what their names are
-	S: SHA1 name
+	S: SHA-1 name
 	S: ...
-	S: SHA1 name
+	S: SHA-1 name
 	S: # flush -- it's your turn
 	# Tell the pusher what commits we want, and what we have
 	C: want name
 	C: ..
 	C: want name
-	C: have SHA1
-	C: have SHA1
+	C: have SHA-1
+	C: have SHA-1
 	C: ...
 	C: # flush -- occasionally ask "had enough?"
 	S: NAK
-	C: have SHA1
+	C: have SHA-1
 	C: ...
-	C: have SHA1
+	C: have SHA-1
 	S: ACK
 	C: done
 	S: XXXXXXX -- packfile contents.
@@ -29,13 +29,13 @@ upload-pack (S) | fetch/clone-pack (C) p
 send-pack | receive-pack protocol.
 
 	# Tell the pusher what commits we have and what their names are
-	C: SHA1 name
+	C: SHA-1 name
 	C: ...
-	C: SHA1 name
+	C: SHA-1 name
 	C: # flush -- it's your turn
 	# Tell the puller what the pusher has
-	S: old-SHA1 new-SHA1 name
-	S: old-SHA1 new-SHA1 name
+	S: old-SHA-1 new-SHA-1 name
+	S: old-SHA-1 new-SHA-1 name
 	S: ...
 	S: # flush -- done with the list
 	S: XXXXXXX --- packfile contents.
-- 
1.4.0.g1b2d