a6e5ef7d9c · matheusbsbs/matheus-bagliano

@@ -188,7 +188,7 @@ As you can see, a commit shows who made the latest change, what they

188 did, and why.

189

190 Every commit has a 40-hexdigit id, sometimes called the "object name" or the

191 -"SHA1 id", shown on the first line of the "git show" output. You can usually

191 +"SHA-1 id", shown on the first line of the "git show" output. You can usually

192 refer to a commit by a shorter name, such as a tag or a branch name, but this

193 longer name can also be useful. Most importantly, it is a globally unique

194 name for this commit: so if you tell somebody else the object name (for

@@ -320,7 +320,7 @@ If you want to create a new branch from this checkout, you may do so

320 HEAD is now at 427abfa... Linux v2.6.17

321 ------------------------------------------------

322

323 -The HEAD then refers to the SHA1 of the commit instead of to a branch,

323 +The HEAD then refers to the SHA-1 of the commit instead of to a branch,

324 and git branch shows that you are no longer on a branch:

325

326 ------------------------------------------------

@@ -739,7 +739,7 @@ $ git log --pretty=oneline origin..mybranch | wc -l

739 -------------------------------------------------

740

741 Alternatively, you may often see this sort of thing done with the

742 -lower-level command linkgit:git-rev-list[1], which just lists the SHA1's

742 +lower-level command linkgit:git-rev-list[1], which just lists the SHA-1's

743 of all the given commits:

744

745 -------------------------------------------------

@@ -2865,8 +2865,8 @@ The Object Database

2865 We already saw in <<understanding-commits>> that all commits are stored

2866 under a 40-digit "object name". In fact, all the information needed to

2867 represent the history of a project is stored in objects with such names.

2868 -In each case the name is calculated by taking the SHA1 hash of the

2869 -contents of the object. The SHA1 hash is a cryptographic hash function.

2868 +In each case the name is calculated by taking the SHA-1 hash of the

2869 +contents of the object. The SHA-1 hash is a cryptographic hash function.

2870 What that means to us is that it is impossible to find two different

2871 objects with the same name. This has a number of advantages; among

2872 others:

@@ -2877,10 +2877,10 @@ others:

2877 same content stored in two repositories will always be stored under

2878 the same name.

2879 - Git can detect errors when it reads an object, by checking that the

2880 - object's name is still the SHA1 hash of its contents.

2880 + object's name is still the SHA-1 hash of its contents.

2881

2882 (See <<object-details>> for the details of the object formatting and

2883 -SHA1 calculation.)

2883 +SHA-1 calculation.)

2884

2885 There are four different types of objects: "blob", "tree", "commit", and

2886 "tag".

@@ -2926,9 +2926,9 @@ committer Junio C Hamano <gitster@pobox.com> 1187591163 -0700

2926

2927 As you can see, a commit is defined by:

2928

2929 -- a tree: The SHA1 name of a tree object (as defined below), representing

2929 +- a tree: The SHA-1 name of a tree object (as defined below), representing

2930 the contents of a directory at a certain point in time.

2931 -- parent(s): The SHA1 name of some number of commits which represent the

2931 +- parent(s): The SHA-1 name of some number of commits which represent the

2932 immediately previous step(s) in the history of the project. The

2933 example above has one parent; merge commits may have more than

2934 one. A commit with no parents is called a "root" commit, and

@@ -2977,13 +2977,13 @@ $ git ls-tree fb3a8bdd0ce

2977 ------------------------------------------------

2978

2979 As you can see, a tree object contains a list of entries, each with a

2980 -mode, object type, SHA1 name, and name, sorted by name. It represents

2980 +mode, object type, SHA-1 name, and name, sorted by name. It represents

2981 the contents of a single directory tree.

2982

2983 The object type may be a blob, representing the contents of a file, or

2984 another tree, representing the contents of a subdirectory. Since trees

2985 -and blobs, like all other objects, are named by the SHA1 hash of their

2986 -contents, two trees have the same SHA1 name if and only if their

2985 +and blobs, like all other objects, are named by the SHA-1 hash of their

2986 +contents, two trees have the same SHA-1 name if and only if their

2987 contents (including, recursively, the contents of all subdirectories)

2988 are identical. This allows git to quickly determine the differences

2989 between two related tree objects, since it can ignore any entries with

@@ -3029,15 +3029,15 @@ currently checked out.

3029 Trust

3030 ~~~~~

3031

3032 -If you receive the SHA1 name of a blob from one source, and its contents

3032 +If you receive the SHA-1 name of a blob from one source, and its contents

3033 from another (possibly untrusted) source, you can still trust that those

3034 -contents are correct as long as the SHA1 name agrees. This is because

3035 -the SHA1 is designed so that it is infeasible to find different contents

3034 +contents are correct as long as the SHA-1 name agrees. This is because

3035 +the SHA-1 is designed so that it is infeasible to find different contents

3036 that produce the same hash.

3037

3038 -Similarly, you need only trust the SHA1 name of a top-level tree object

3038 +Similarly, you need only trust the SHA-1 name of a top-level tree object

3039 to trust the contents of the entire directory that it refers to, and if

3040 -you receive the SHA1 name of a commit from a trusted source, then you

3040 +you receive the SHA-1 name of a commit from a trusted source, then you

3041 can easily verify the entire history of commits reachable through

3042 parents of that commit, and all of those contents of the trees referred

3043 to by those commits.

@@ -3049,7 +3049,7 @@ that you trust that commit, and the immutability of the history of

3049 commits tells others that they can trust the whole history.

3050

3051 In other words, you can easily validate a whole archive by just

3052 -sending out a single email that tells the people the name (SHA1 hash)

3052 +sending out a single email that tells the people the name (SHA-1 hash)

3053 of the top commit, and digitally sign that email using something

3054 like GPG/PGP.

3055

@@ -3090,7 +3090,7 @@ How git stores objects efficiently: pack files

3090 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

3091

3092 Newly created objects are initially created in a file named after the

3093 -object's SHA1 hash (stored in .git/objects).

3093 +object's SHA-1 hash (stored in .git/objects).

3094

3095 Unfortunately this system becomes inefficient once a project has a

3096 lot of objects. Try this on an old project:

@@ -3297,7 +3297,7 @@ $ git hash-object -w somedirectory/myfile

3297 ------------------------------------------------

3298

3299 which will create and store a blob object with the contents of

3300 -somedirectory/myfile, and output the sha1 of that object. if you're

3300 +somedirectory/myfile, and output the SHA-1 of that object. if you're

3301 extremely lucky it might be 4b9458b3786228369c63936db65827de3cc06200, in

3302 which case you've guessed right, and the corruption is fixed!

3303

@@ -3359,7 +3359,7 @@ The index

3359 -----------

3360

3361 The index is a binary file (generally kept in .git/index) containing a

3362 -sorted list of path names, each with permissions and the SHA1 of a blob

3362 +sorted list of path names, each with permissions and the SHA-1 of a blob

3363 object; linkgit:git-ls-files[1] can show you the contents of the index:

3364

3365 -------------------------------------------------

@@ -3754,7 +3754,7 @@ unsaved state that you might want to restore later!) your current

3754 index. Normal operation is just

3755

3756 -------------------------------------------------

3757 -$ git read-tree <sha1 of tree>

3757 +$ git read-tree <SHA-1 of tree>

3758 -------------------------------------------------

3759

3760 and your index file will now be equivalent to the tree that you saved

@@ -3978,7 +3978,7 @@ $ git ls-files --unmerged

3978 ------------------------------------------------

3979

3980 Each line of the `git ls-files --unmerged` output begins with

3981 -the blob mode bits, blob SHA1, 'stage number', and the

3981 +the blob mode bits, blob SHA-1, 'stage number', and the

3982 filename. The 'stage number' is git's way to say which tree it

3983 came from: stage 1 corresponds to `$orig` tree, stage 2 `HEAD`

3984 tree, and stage3 `$target` tree.

@@ -4045,12 +4045,12 @@ objects). There are currently four different object types: "blob",

4045 Regardless of object type, all objects share the following

4046 characteristics: they are all deflated with zlib, and have a header

4047 that not only specifies their type, but also provides size information

4048 -about the data in the object. It's worth noting that the SHA1 hash

4048 +about the data in the object. It's worth noting that the SHA-1 hash

4049 that is used to name the object is the hash of the original data

4050 plus this header, so `sha1sum` 'file' does not match the object name

4051 for 'file'.

4052 (Historical note: in the dawn of the age of git the hash

4053 -was the sha1 of the 'compressed' object.)

4053 +was the SHA-1 of the 'compressed' object.)

4054

4055 As a result, the general consistency of an object can always be tested

4056 independently of the contents or the type of the object: all objects can

user-manual: the name of the hash function is SHA-1, not sha1