d5fa1f1a69 · matheusbsbs/matheus-bagliano

Documentation/config.txt

+1 -1

@@ -412,7 +412,7 @@ repository's usual working tree).

412 core.logAllRefUpdates::

413 Enable the reflog. Updates to a ref <ref> is logged to the file

414 "$GIT_DIR/logs/<ref>", by appending the new and old

415 - SHA1, the date/time and the reason of the update, but

415 + SHA-1, the date/time and the reason of the update, but

416 only when the file exists. If this configuration

417 variable is set to true, missing "$GIT_DIR/logs/<ref>"

418 file is automatically created for branch heads (i.e. under

Documentation/git-cat-file.txt

+3 -3

@@ -20,7 +20,7 @@ object type, or '-s' is used to find the object size, or '--textconv' is used

20 (which implies type "blob").

21

22 In the second form, a list of objects (separated by linefeeds) is provided on

23 -stdin, and the SHA1, type, and size of each object is printed on stdout.

23 +stdin, and the SHA-1, type, and size of each object is printed on stdout.

24

25 OPTIONS

26 -------

@@ -58,11 +58,11 @@ OPTIONS

58 to apply the filter to the content recorded in the index at <path>.

59

60 --batch::

61 - Print the SHA1, type, size, and contents of each object provided on

61 + Print the SHA-1, type, size, and contents of each object provided on

62 stdin. May not be combined with any other options or arguments.

63

64 --batch-check::

65 - Print the SHA1, type, and size of each object provided on stdin. May not

65 + Print the SHA-1, type, and size of each object provided on stdin. May not

66 be combined with any other options or arguments.

67

68 OUTPUT

Documentation/git-describe.txt

+1 -1

@@ -149,7 +149,7 @@ is found, its name will be output and searching will stop.

149 If an exact match was not found, 'git describe' will walk back

150 through the commit history to locate an ancestor commit which

151 has been tagged. The ancestor's tag will be output along with an

152 -abbreviation of the input committish's SHA1.

152 +abbreviation of the input committish's SHA-1.

153

154 If multiple tags were found during the walk then the tag which

155 has the fewest commits different from the input committish will be

Documentation/git-fsck.txt

+2 -2

@@ -23,7 +23,7 @@ OPTIONS

23 An object to treat as the head of an unreachability trace.

24 +

25 If no objects are given, 'git fsck' defaults to using the

26 -index file, all SHA1 references in `refs` namespace, and all reflogs

26 +index file, all SHA-1 references in `refs` namespace, and all reflogs

27 (unless --no-reflogs is given) as heads.

28

29 --unreachable::

@@ -89,7 +89,7 @@ index file, all SHA1 references in `refs` namespace, and all reflogs

89 DISCUSSION

90 ----------

91

92 -git-fsck tests SHA1 and general object sanity, and it does full tracking

92 +git-fsck tests SHA-1 and general object sanity, and it does full tracking

93 of the resulting reachability and everything else. It prints out any

94 corruption it finds (missing or bad objects), and if you use the

95 '--unreachable' flag it will also print out objects that exist but that

Documentation/git-index-pack.txt

+1 -1

@@ -89,7 +89,7 @@ Note

89 ----

90

91 Once the index has been created, the list of object names is sorted

92 -and the SHA1 hash of that list is printed to stdout. If --stdin was

92 +and the SHA-1 hash of that list is printed to stdout. If --stdin was

93 also used then this is prefixed by either "pack\t", or "keep\t" if a

94 new .keep file was successfully created. This is useful to remove a

95 .keep file used as a lock to prevent the race with 'git repack'

Documentation/git-ls-files.txt

+1 -1

@@ -164,7 +164,7 @@ which case it outputs:

164 'git ls-files --unmerged' and 'git ls-files --stage' can be used to examine

165 detailed information on unmerged paths.

166

167 -For an unmerged path, instead of recording a single mode/SHA1 pair,

167 +For an unmerged path, instead of recording a single mode/SHA-1 pair,

168 the index records up to three such pairs; one from tree O in stage

169 1, A in stage 2, and B in stage 3. This information can be used by

170 the user (or the porcelain) to see what should eventually be recorded at the

Documentation/git-merge-index.txt

+1 -1

@@ -14,7 +14,7 @@ SYNOPSIS

14 DESCRIPTION

15 -----------

16 This looks up the <file>(s) in the index and, if there are any merge

17 -entries, passes the SHA1 hash for those files as arguments 1, 2, 3 (empty

17 +entries, passes the SHA-1 hash for those files as arguments 1, 2, 3 (empty

18 argument if no file), and <file> as argument 4. File modes for the three

19 files are passed as arguments 5, 6 and 7.

20

Documentation/git-pack-objects.txt

+1 -1

@@ -50,7 +50,7 @@ base-name::

50 Write into a pair of files (.pack and .idx), using

51 <base-name> to determine the name of the created file.

52 When this option is used, the two files are written in

53 - <base-name>-<SHA1>.{pack,idx} files. <SHA1> is a hash

53 + <base-name>-<SHA-1>.{pack,idx} files. <SHA-1> is a hash

54 of the sorted object names to make the resulting filename

55 based on the pack content, and written to the standard

56 output of the command.

Documentation/git-patch-id.txt

+1 -1

@@ -12,7 +12,7 @@ SYNOPSIS

12

13 DESCRIPTION

14 -----------

15 -A "patch ID" is nothing but a SHA1 of the diff associated with a patch, with

15 +A "patch ID" is nothing but a SHA-1 of the diff associated with a patch, with

16 whitespace and line numbers ignored. As such, it's "reasonably stable", but at

17 the same time also reasonably unique, i.e., two patches that have the same "patch

18 ID" are almost guaranteed to be the same thing.

Documentation/git-replace.txt

+2 -2

@@ -16,8 +16,8 @@ DESCRIPTION

16 -----------

17 Adds a 'replace' reference in `refs/replace/` namespace.

18

19 -The name of the 'replace' reference is the SHA1 of the object that is

20 -replaced. The content of the 'replace' reference is the SHA1 of the

19 +The name of the 'replace' reference is the SHA-1 of the object that is

20 +replaced. The content of the 'replace' reference is the SHA-1 of the

21 replacement object.

22

23 Unless `-f` is given, the 'replace' reference must not yet exist.

Documentation/git-rev-parse.txt

+2 -2

@@ -84,7 +84,7 @@ OPTIONS

84 one.

85

86 --symbolic::

87 - Usually the object names are output in SHA1 form (with

87 + Usually the object names are output in SHA-1 form (with

88 possible '{caret}' prefix); this option makes them output in a

89 form as close to the original input as possible.

90

@@ -169,7 +169,7 @@ print a message to stderr and exit with nonzero status.

169

170 --short::

171 --short=number::

172 - Instead of outputting the full SHA1 values of object names try to

172 + Instead of outputting the full SHA-1 values of object names try to

173 abbreviate them to a shorter unique name. When no length is specified

174 7 is used. The minimum length is 4.

175

Documentation/git-show-branch.txt

+2 -2

@@ -31,7 +31,7 @@ no <rev> nor <glob> is given on the command line.

31 OPTIONS

32 -------

33 <rev>::

34 - Arbitrary extended SHA1 expression (see linkgit:gitrevisions[7])

34 + Arbitrary extended SHA-1 expression (see linkgit:gitrevisions[7])

35 that typically names a branch head or a tag.

36

37 <glob>::

@@ -142,7 +142,7 @@ displayed, indented N places. If a commit is on the I-th

142 branch, the I-th indentation character shows a `+` sign;

143 otherwise it shows a space. Merge commits are denoted by

144 a `-` sign. Each commit shows a short name that

145 -can be used as an extended SHA1 to name that commit.

145 +can be used as an extended SHA-1 to name that commit.

146

147 The following example shows three branches, "master", "fixes"

148 and "mhf":

Documentation/git-show-index.txt

+1 -1

@@ -19,7 +19,7 @@ Reads given idx file for packed Git archive created with

19

20 The information it outputs is subset of what you can get from

21 'git verify-pack -v'; this command only shows the packfile

22 -offset and SHA1 of each object.

22 +offset and SHA-1 of each object.

23

24 GIT

25 ---

Documentation/git-show-ref.txt

+2 -2

@@ -50,8 +50,8 @@ OPTIONS

50 -s::

51 --hash[=<n>]::

52

53 - Only show the SHA1 hash, not the reference name. When combined with

54 - --dereference the dereferenced tag will still be shown after the SHA1.

53 + Only show the SHA-1 hash, not the reference name. When combined with

54 + --dereference the dereferenced tag will still be shown after the SHA-1.

55

56 --verify::

57

Documentation/git-tag.txt

+1 -1

@@ -33,7 +33,7 @@ in the tag message.

33 If `-m <msg>` or `-F <file>` is given and `-a`, `-s`, and `-u <key-id>`

34 are absent, `-a` is implied.

35

36 -Otherwise just a tag reference for the SHA1 object name of the commit object is

36 +Otherwise just a tag reference for the SHA-1 object name of the commit object is

37 created (i.e. a lightweight tag).

38

39 A GnuPG signed tag object will be created when `-s` or `-u

Documentation/git-update-index.txt

+1 -1

@@ -247,7 +247,7 @@ $ git update-index --index-info

247 ------------

248

249 The first line of the input feeds 0 as the mode to remove the

250 -path; the SHA1 does not matter as long as it is well formatted.

250 +path; the SHA-1 does not matter as long as it is well formatted.

251 Then the second and third line feeds stage 1 and stage 2 entries

252 for that path. After the above, we would end up with this:

253

Documentation/git-verify-pack.txt

+2 -2

@@ -40,11 +40,11 @@ OUTPUT FORMAT

40 -------------

41 When specifying the -v option the format used is:

42

43 - SHA1 type size size-in-pack-file offset-in-packfile

43 + SHA-1 type size size-in-pack-file offset-in-packfile

44

45 for objects that are not deltified in the pack, and

46

47 - SHA1 type size size-in-packfile offset-in-packfile depth base-SHA1

47 + SHA-1 type size size-in-packfile offset-in-packfile depth base-SHA-1

48

49 for objects that are deltified.

50

Documentation/git-verify-tag.txt

+1 -1

@@ -21,7 +21,7 @@ OPTIONS

21 Print the contents of the tag object before validating it.

22

23 <tag>...::

24 - SHA1 identifiers of Git tag objects.

24 + SHA-1 identifiers of Git tag objects.

25

26 GIT

27 ---

Documentation/git.txt

+5 -5

@@ -741,7 +741,7 @@ where:

741

742 <old|new>-file:: are files GIT_EXTERNAL_DIFF can use to read the

743 contents of <old|new>,

744 - <old|new>-hex:: are the 40-hexdigit SHA1 hashes,

744 + <old|new>-hex:: are the 40-hexdigit SHA-1 hashes,

745 <old|new>-mode:: are the octal representation of the file modes.

746 +

747 The file parameters can point at the user's working file

@@ -864,7 +864,7 @@ The commit, equivalent to what other systems call a "changeset" or

864 represents an immediately preceding step. Commits with more than one

865 parent represent merges of independent lines of development.

866

867 -All objects are named by the SHA1 hash of their contents, normally

867 +All objects are named by the SHA-1 hash of their contents, normally

868 written as a string of 40 hex digits. Such names are globally unique.

869 The entire history leading up to a commit can be vouched for by signing

870 just that commit. A fourth object type, the tag, is provided for this

@@ -874,9 +874,9 @@ When first created, objects are stored in individual files, but for

874 efficiency may later be compressed together into "pack files".

875

876 Named pointers called refs mark interesting points in history. A ref

877 -may contain the SHA1 name of an object or the name of another ref. Refs

878 -with names beginning `ref/head/` contain the SHA1 name of the most

879 -recent commit (or "head") of a branch under development. SHA1 names of

877 +may contain the SHA-1 name of an object or the name of another ref. Refs

878 +with names beginning `ref/head/` contain the SHA-1 name of the most

879 +recent commit (or "head") of a branch under development. SHA-1 names of

880 tags of interest are stored under `ref/tags/`. A special ref named

881 `HEAD` contains the name of the currently checked-out branch.

882

Documentation/gitcore-tutorial.txt

+4 -4

@@ -106,9 +106,9 @@ branch. A number of the Git tools will assume that `.git/HEAD` is

106 valid, though.

107

108 [NOTE]

109 -An 'object' is identified by its 160-bit SHA1 hash, aka 'object name',

109 +An 'object' is identified by its 160-bit SHA-1 hash, aka 'object name',

110 and a reference to an object is always the 40-byte hex

111 -representation of that SHA1 name. The files in the `refs`

111 +representation of that SHA-1 name. The files in the `refs`

112 subdirectory are expected to contain these hex references

113 (usually with a final `\n` at the end), and you should thus

114 expect to see a number of 41-byte files containing these

@@ -763,7 +763,7 @@ already discussed, the `HEAD` branch is nothing but a symlink to one of

763 these object pointers.

764

765 You can at any time create a new branch by just picking an arbitrary

766 -point in the project history, and just writing the SHA1 name of that

766 +point in the project history, and just writing the SHA-1 name of that

767 object into a file under `.git/refs/heads/`. You can use any filename you

768 want (and indeed, subdirectories), but the convention is that the

769 "normal" branch is called `master`. That's just a convention, though,

@@ -1233,7 +1233,7 @@ file (the first tree goes to stage 1, the second to stage 2,

1233 etc.). After reading three trees into three stages, the paths

1234 that are the same in all three stages are 'collapsed' into stage

1235 0. Also paths that are the same in two of three stages are

1236 -collapsed into stage 0, taking the SHA1 from either stage 2 or

1236 +collapsed into stage 0, taking the SHA-1 from either stage 2 or

1237 stage 3, whichever is different from stage 1 (i.e. only one side

1238 changed from the common ancestor).

1239

Documentation/gitdiffcore.txt

+1 -1

@@ -108,7 +108,7 @@ it changes it to:

108 For the purpose of breaking a filepair, diffcore-break examines

109 the extent of changes between the contents of the files before

110 and after modification (i.e. the contents that have "bcd1234..."

111 -and "0123456..." as their SHA1 content ID, in the above

111 +and "0123456..." as their SHA-1 content ID, in the above

112 example). The amount of deletion of original contents and

113 insertion of new material are added together, and if it exceeds

114 the "break score", the filepair is broken into two. The break

Documentation/githooks.txt

+5 -5

@@ -99,7 +99,7 @@ given); `template` (if a `-t` option was given or the

99 configuration option `commit.template` is set); `merge` (if the

100 commit is a merge or a `.git/MERGE_MSG` file exists); `squash`

101 (if a `.git/SQUASH_MSG` file exists); or `commit`, followed by

102 -a commit SHA1 (if a `-c`, `-C` or `--amend` option was given).

102 +a commit SHA-1 (if a `-c`, `-C` or `--amend` option was given).

103

104 If the exit status is non-zero, 'git commit' will abort.

105

@@ -196,11 +196,11 @@ hook would receive a line like the following:

196

197 refs/heads/master 67890 refs/heads/foreign 12345

198

199 -although the full, 40-character SHA1s would be supplied. If the foreign ref

200 -does not yet exist the `<remote SHA1>` will be 40 `0`. If a ref is to be

199 +although the full, 40-character SHA-1s would be supplied. If the foreign ref

200 +does not yet exist the `<remote SHA-1>` will be 40 `0`. If a ref is to be

201 deleted, the `<local ref>` will be supplied as `(delete)` and the `<local

202 -SHA1>` will be 40 `0`. If the local commit was specified by something other

203 -than a name which could be expanded (such as `HEAD~`, or a SHA1) it will be

202 +SHA-1>` will be 40 `0`. If the local commit was specified by something other

203 +than a name which could be expanded (such as `HEAD~`, or a SHA-1) it will be

204 supplied as it was originally given.

205

206 If this hook exits with a non-zero status, 'git push' will abort without

Documentation/gitrepository-layout.txt

+1 -1

@@ -106,7 +106,7 @@ refs/remotes/`name`::

106 from a remote repository.

107

108 refs/replace/`<obj-sha1>`::

109 - records the SHA1 of the object that replaces `<obj-sha1>`.

109 + records the SHA-1 of the object that replaces `<obj-sha1>`.

110 This is similar to info/grafts and is internally used and

111 maintained by linkgit:git-replace[1]. Such refs can be exchanged

112 between repositories while grafts are not.

Documentation/gittutorial-2.txt

+8 -8

@@ -46,9 +46,9 @@ What are the 7 digits of hex that Git responded to the commit with?

46

47 We saw in part one of the tutorial that commits have names like this.

48 It turns out that every object in the Git history is stored under

49 -a 40-digit hex name. That name is the SHA1 hash of the object's

49 +a 40-digit hex name. That name is the SHA-1 hash of the object's

50 contents; among other things, this ensures that Git will never store

51 -the same data twice (since identical data is given an identical SHA1

51 +the same data twice (since identical data is given an identical SHA-1

52 name), and that the contents of a Git object will never change (since

53 that would change the object's name as well). The 7 char hex strings

54 here are simply the abbreviation of such 40 character long strings.

@@ -56,7 +56,7 @@ Abbreviations can be used everywhere where the 40 character strings

56 can be used, so long as they are unambiguous.

57

58 It is expected that the content of the commit object you created while

59 -following the example above generates a different SHA1 hash than

59 +following the example above generates a different SHA-1 hash than

60 the one shown above because the commit object records the time when

61 it was created and the name of the person performing the commit.

62

@@ -80,14 +80,14 @@ A tree can refer to one or more "blob" objects, each corresponding to

80 a file. In addition, a tree can also refer to other tree objects,

81 thus creating a directory hierarchy. You can examine the contents of

82 any tree using ls-tree (remember that a long enough initial portion

83 -of the SHA1 will also work):

83 +of the SHA-1 will also work):

84

85 ------------------------------------------------

86 $ git ls-tree 92b8b694

87 100644 blob 3b18e512dba79e4c8300dd08aeb37f8e728b8dad file.txt

88 ------------------------------------------------

89

90 -Thus we see that this tree has one file in it. The SHA1 hash is a

90 +Thus we see that this tree has one file in it. The SHA-1 hash is a

91 reference to that file's data:

92

93 ------------------------------------------------

@@ -106,7 +106,7 @@ Note that this is the old file data; so the object that Git named in

106 its response to the initial tree was a tree with a snapshot of the

107 directory state that was recorded by the first commit.

108

109 -All of these objects are stored under their SHA1 names inside the Git

109 +All of these objects are stored under their SHA-1 names inside the Git

110 directory:

111

112 ------------------------------------------------

@@ -142,7 +142,7 @@ ref: refs/heads/master

142

143 As you can see, this tells us which branch we're currently on, and it

144 tells us this by naming a file under the .git directory, which itself

145 -contains a SHA1 name referring to a commit object, which we can

145 +contains a SHA-1 name referring to a commit object, which we can

146 examine with cat-file:

147

148 ------------------------------------------------

@@ -208,7 +208,7 @@ project's history:

208

209 Note, by the way, that lots of commands take a tree as an argument.

210 But as we can see above, a tree can be referred to in many different

211 -ways--by the SHA1 name for that tree, by the name of a commit that

211 +ways--by the SHA-1 name for that tree, by the name of a commit that

212 refers to the tree, by the name of a branch whose head refers to that

213 tree, etc.--and most such commands can accept any of these names.

214

Documentation/howto/recover-corrupted-blob-object.txt

+3 -3

@@ -15,7 +15,7 @@ On Fri, 9 Nov 2007, Yossi Leybovich wrote:

15 > Any one know how can I track this object and understand which file is it

16 -----------------------------------------------------------

17

18 -So exactly *because* the SHA1 hash is cryptographically secure, the hash

18 +So exactly *because* the SHA-1 hash is cryptographically secure, the hash

19 itself doesn't actually tell you anything, in order to fix a corrupt

20 object you basically have to find the "original source" for it.

21

@@ -44,7 +44,7 @@ So:

44 -----------------------------------------------------------

45

46 This is the right thing to do, although it's usually best to save it under

47 -it's full SHA1 name (you just dropped the "4b" from the result ;).

47 +it's full SHA-1 name (you just dropped the "4b" from the result ;).

48

49 Let's see what that tells us:

50

@@ -89,7 +89,7 @@ working tree, in which case fixing this problem is really simple, just do

89

90 git hash-object -w my-magic-file

91

92 -again, and if it outputs the missing SHA1 (4b945..) you're now all done!

92 +again, and if it outputs the missing SHA-1 (4b945..) you're now all done!

93

94 But that's the really lucky case, so let's assume that it was some older

95 version that was broken. How do you tell which version it was?

Documentation/pretty-formats.txt

+1 -1

@@ -75,7 +75,7 @@ This is designed to be as compact as possible.

75 * 'raw'

76 +

77 The 'raw' format shows the entire commit exactly as

78 -stored in the commit object. Notably, the SHA1s are

78 +stored in the commit object. Notably, the SHA-1s are

79 displayed in full, regardless of whether --abbrev or

80 --no-abbrev are used, and 'parents' information show the

81 true parent commits, without taking grafts nor history

Documentation/revisions.txt

+2 -2

@@ -2,13 +2,13 @@ SPECIFYING REVISIONS

2 --------------------

3

4 A revision parameter '<rev>' typically, but not necessarily, names a

5 -commit object. It uses what is called an 'extended SHA1'

5 +commit object. It uses what is called an 'extended SHA-1'

6 syntax. Here are various ways to spell object names. The

7 ones listed near the end of this list name trees and

8 blobs contained in a commit.

9

10 '<sha1>', e.g. 'dae86e1950b1277e545cee180551750029cfe735', 'dae86e'::

11 - The full SHA1 object name (40-byte hexadecimal string), or

11 + The full SHA-1 object name (40-byte hexadecimal string), or

12 a leading substring that is unique within the repository.

13 E.g. dae86e1950b1277e545cee180551750029cfe735 and dae86e both

14 name the same commit object if there is no other object in

Documentation/technical/api-sha1-array.txt

+2 -2

@@ -1,7 +1,7 @@

1 sha1-array API

2 ==============

3

4 -The sha1-array API provides storage and manipulation of sets of SHA1

4 +The sha1-array API provides storage and manipulation of sets of SHA-1

5 identifiers. The emphasis is on storage and processing efficiency,

6 making them suitable for large lists. Note that the ordering of items is

7 not preserved over some operations.

@@ -11,7 +11,7 @@ Data Structures

11

12 `struct sha1_array`::

13

14 - A single array of SHA1 hashes. This should be initialized by

14 + A single array of SHA-1 hashes. This should be initialized by

15 assignment from `SHA1_ARRAY_INIT`. The `sha1` member contains

16 the actual data. The `nr` member contains the number of items in

17 the set. The `alloc` and `sorted` members are used internally,

Documentation/technical/pack-format.txt

+7 -7

@@ -34,7 +34,7 @@ Git pack format

34 Observation: length of each object is encoded in a variable

35 length format and is not constrained to 32-bit or anything.

36

37 - - The trailer records 20-byte SHA1 checksum of all of the above.

37 + - The trailer records 20-byte SHA-1 checksum of all of the above.

38

39 == Original (version 1) pack-*.idx files have the following format:

40

@@ -55,10 +55,10 @@ Git pack format

55

56 - The file is concluded with a trailer:

57

58 - A copy of the 20-byte SHA1 checksum at the end of

58 + A copy of the 20-byte SHA-1 checksum at the end of

59 corresponding packfile.

60

61 - 20-byte SHA1-checksum of all of the above.

61 + 20-byte SHA-1-checksum of all of the above.

62

63 Pack Idx file:

64

@@ -106,7 +106,7 @@ Pack file entry: <+

106 If it is not DELTA, then deflated bytes (the size above

107 is the size before compression).

108 If it is REF_DELTA, then

109 - 20-byte base object name SHA1 (the size above is the

109 + 20-byte base object name SHA-1 (the size above is the

110 size of the delta data that follows).

111 delta data, deflated.

112 If it is OFS_DELTA, then

@@ -135,7 +135,7 @@ Pack file entry: <+

135

136 - A 256-entry fan-out table just like v1.

137

138 - - A table of sorted 20-byte SHA1 object names. These are

138 + - A table of sorted 20-byte SHA-1 object names. These are

139 packed together without offset values to reduce the cache

140 footprint of the binary search for a specific object name.

141

@@ -156,7 +156,7 @@ Pack file entry: <+

156

157 - The same trailer as a v1 pack file:

158

159 - A copy of the 20-byte SHA1 checksum at the end of

159 + A copy of the 20-byte SHA-1 checksum at the end of

160 corresponding packfile.

161

162 - 20-byte SHA1-checksum of all of the above.

162 + 20-byte SHA-1-checksum of all of the above.

Documentation/technical/pack-heuristics.txt

+1 -1

@@ -89,7 +89,7 @@ Ah, grasshopper! And thus the enlightenment begins anew.

89

90 <linus> The "magic" is actually in theory totally arbitrary.

91 ANY order will give you a working pack, but no, it's not

92 - ordered by SHA1.

92 + ordered by SHA-1.

93

94 Before talking about the ordering for the sliding delta

95 window, let's talk about the recency order. That's more

Documentation/technical/shallow.txt

+2 -2

@@ -8,7 +8,7 @@ repo, and therefore grafts are introduced pretending that

8 these commits have no parents.

9 *********************************************************

10

11 -The basic idea is to write the SHA1s of shallow commits into

11 +The basic idea is to write the SHA-1s of shallow commits into

12 $GIT_DIR/shallow, and handle its contents like the contents

13 of $GIT_DIR/info/grafts (with the difference that shallow

14 cannot contain parent information).

@@ -18,7 +18,7 @@ even the config, since the user should not touch that file

18 at all (even throughout development of the shallow clone, it

19 was never manually edited!).

20

21 -Each line contains exactly one SHA1. When read, a commit_graft

21 +Each line contains exactly one SHA-1. When read, a commit_graft

22 will be constructed, which has nr_parent < 0 to make it easier

23 to discern from user provided grafts.

24

The name of the hash function is "SHA-1", not "SHA1"