summaryrefslogtreecommitdiff
path: root/Documentation/technical
diff options
context:
space:
mode:
Diffstat (limited to 'Documentation/technical')
-rw-r--r--Documentation/technical/api-sha1-array.txt4
-rw-r--r--Documentation/technical/pack-format.txt14
-rw-r--r--Documentation/technical/pack-heuristics.txt2
-rw-r--r--Documentation/technical/shallow.txt4
4 files changed, 12 insertions, 12 deletions
diff --git a/Documentation/technical/api-sha1-array.txt b/Documentation/technical/api-sha1-array.txt
index 45d1c51..3e75497 100644
--- a/Documentation/technical/api-sha1-array.txt
+++ b/Documentation/technical/api-sha1-array.txt
@@ -1,7 +1,7 @@
sha1-array API
==============
-The sha1-array API provides storage and manipulation of sets of SHA1
+The sha1-array API provides storage and manipulation of sets of SHA-1
identifiers. The emphasis is on storage and processing efficiency,
making them suitable for large lists. Note that the ordering of items is
not preserved over some operations.
@@ -11,7 +11,7 @@ Data Structures
`struct sha1_array`::
- A single array of SHA1 hashes. This should be initialized by
+ A single array of SHA-1 hashes. This should be initialized by
assignment from `SHA1_ARRAY_INIT`. The `sha1` member contains
the actual data. The `nr` member contains the number of items in
the set. The `alloc` and `sorted` members are used internally,
diff --git a/Documentation/technical/pack-format.txt b/Documentation/technical/pack-format.txt
index a37f137..8e5bf60 100644
--- a/Documentation/technical/pack-format.txt
+++ b/Documentation/technical/pack-format.txt
@@ -34,7 +34,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.
== Original (version 1) pack-*.idx files have the following format:
@@ -55,10 +55,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:
@@ -106,7 +106,7 @@ Pack file entry: <+
If it is not DELTA, then deflated bytes (the size above
is the size before compression).
If it is REF_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.
If it is OFS_DELTA, then
@@ -135,7 +135,7 @@ Pack file entry: <+
- A 256-entry fan-out table just like v1.
- - A table of sorted 20-byte SHA1 object names. These are
+ - A table of sorted 20-byte SHA-1 object names. These are
packed together without offset values to reduce the cache
footprint of the binary search for a specific object name.
@@ -156,7 +156,7 @@ Pack file entry: <+
- The same trailer as a v1 pack file:
- 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.
diff --git a/Documentation/technical/pack-heuristics.txt b/Documentation/technical/pack-heuristics.txt
index dbdf7ba..8b7ae1c 100644
--- a/Documentation/technical/pack-heuristics.txt
+++ b/Documentation/technical/pack-heuristics.txt
@@ -89,7 +89,7 @@ Ah, grasshopper! And thus the enlightenment begins anew.
<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/shallow.txt b/Documentation/technical/shallow.txt
index ea2f69f..5183b15 100644
--- a/Documentation/technical/shallow.txt
+++ b/Documentation/technical/shallow.txt
@@ -8,7 +8,7 @@ repo, and therefore grafts are introduced pretending that
these commits have no parents.
*********************************************************
-The basic idea is to write the SHA1s of shallow commits into
+The basic idea is to write the SHA-1s of shallow commits into
$GIT_DIR/shallow, and handle its contents like the contents
of $GIT_DIR/info/grafts (with the difference that shallow
cannot contain parent information).
@@ -18,7 +18,7 @@ even the config, since the user should not touch that file
at all (even throughout development of the shallow clone, it
was never manually edited!).
-Each line contains exactly one SHA1. When read, a commit_graft
+Each line contains exactly one SHA-1. When read, a commit_graft
will be constructed, which has nr_parent < 0 to make it easier
to discern from user provided grafts.