Version Control with Git

Errata for Version Control with Git

Submit your own errata for this product.


The errata list is a list of errors and their corrections that were found after the product was released. If the error was corrected in a later version or reprint the date of the correction will be displayed in the column titled "Date Corrected".

The following errata were submitted by our customers and approved as valid errors by the author or editor.

Color Key: Serious Technical Mistake Minor Technical Mistake Language or formatting error Typo Question Note Update



Version Location Description Submitted By Date Submitted Date Corrected
Printed, Safari Books Online
Page Section 5.9
Figure 5-4

The newly created tree object (the triangle with the double outline) should be pointing at bd71363 (quux) and not at a23bf (foo); it should look the same as the tree object in the index.

Note from the Author or Editor:
Correct. Adjust the bottom "Object store" portion of Figure 5-4 such that the double-lined triangle points to 9d3a2 (bar) and bd71363 (quux), and doesn't point to a23bf (foo).

Phil Thomas  May 30, 2009 
Safari Books Online
4.2
The text immediately preceeding Figure 4-1

The text immediately preceeding Figure 4-1 reads: "Figure 4-1 captures how all the pieces fit together. This diagram shows the state of a repository after a single, initial commit added two files. Both files are in the top-level directory. Both the master branch and a tag named V1.0 point to the commit with ID 8675309." I believe that should read " ... point to the commit with ID 1492."

Note from the Author or Editor:
Confirmed. That sentence should read: Both the master branch and a tag named V1.0 point to the commit with ID 1492.

Anonymous  Jun 02, 2009 
Printed
Page 22
"Making Another Commit" section

(wrong) $ cat index.html ... <html> (correct) $ cat index.html ... </html> <- should be a closing tag

Note from the Author or Editor:
*sigh* True. To make the HTML valid, it should be a closing </html> tag. The example in the middle of page 22 should have its penultimate line updated: ... My website is alive! </body> </html> Then, to be consistent and correct later, the example at the top of page 24 should have its "index" and final lines changed as well: ... diff --git a/index.html b/index.html index 34217e9..8638631 100644 --- a/index.html +++ b/index.html @@ -1 +1,5 @@ +<html> +<body> My website is alive! +</body> +</html> Note that the final </html> tag has been updated as well as the second partial SHA1 number on the "index" line.

tsuyoshi  Oct 31, 2009 
Printed
Page 23
Last paragraph

"The phrase --more=10 reveals the most recent 10 versions". It should be "11" instead.

Note from the Author or Editor:
Correct. Perhaps rewrite the beginning of the sentence as: The phrase --more=10 reveals up to an additional 10 more versions, but only ...

Anonymous  Aug 09, 2010 
Printed
Page 32
4th paragraph

"If two separate files located in two different directories have exactly the same content, Git stores a sole copy of that content as a blob within the object store". It's true, but it is also true if the files are in the same directory, so the "located in two different directories" should be removed.

Note from the Author or Editor:
Fair point. Perhaps rewrite the sentence as: If two separate files have exactly the same content, whether in the same or different directories, Git stores a sole copy of that content as a blob within the object store.

Anonymous  Aug 09, 2010 
Printed
Page 32
in the box titled "Globally Unique Identifiers"

On pg. 32, in the box titled "Globally Unique Identifiers", the statement is made "Thus, the SHA1 hash ID of a file is a globally unique identifier." This is not exactly true, for if it were it would violate the pigeon hole principal. Multiple files could hash to the same value (and we could just pass around the hash value and be done with it), but the mathematically odds of this are very slim, so the statement should read: "Thus, the SHA1 hash ID of a file is an *effective* globally unique identifier.

Note from the Author or Editor:
Sure. Thus, the SHA1 hash ID of a file is an effective globally unique identifier.

Anonymous  Apr 15, 2011 
Printed
Page 34
4th paragraph

At the end of the following sentence, the ID is wrong: "Both the 'master' branch and a tag named 'v1.0' point to the commit with ID 8675309." The correct commit ID is 1492. (The refer ID 8675309 in the sentence is in fact the tree ID, not the commit ID).

Note from the Author or Editor:
*sigh* Yes, it should read '... point to the commit with ID 1492.'

Sébastien Cabot  Jun 21, 2011 
Printed
Page 42
line 10

The output of the "git cat-file -p 3ede462" command is missing this line: tree 492413269336d21fac079d4a4672e55d5d2147ac This is what connects the commit object with the tree object.

Note from the Author or Editor:
Yep, it certainly is missing. Sorry. The second example sequence on page 42 should look like this: And it will look something like this: $ git cat-file -p 3ede3462 tree 492413269336d21fac079d4a4672e55d5d2147ac author Jon Loeliger <jdl@example.com> 1220233277 -0500 committer Jon Loeliger <jdl@example.com> 1220233277 -0500 Commit a file that says hello That is, just add in the "tree 492..." line as shown.

Gustavo Delfino  Aug 27, 2009 
Printed
Page 50

after $git add ready should go $git add notyet and only after this #modify file "notyet" without $git add notyet the example doesn't make much sense (at least to me)

Note from the Author or Editor:
So, yeah, the setup for this example has been vaguely left absent. Sorry. It does assume that both "ready" and "notyet" have been previously added to the repository, which is what your suggested fix is addressing. To remedy this, let's rewrite the whole first example sequence on page 50 with complete repository initialization like this: Let's see how this works by setting up a few files with different staging characteristics: # Setup test repository $ mkdir /tmp/commit-all-example $ cd /tmp/commit-all-example $ git init Initialized empty Git repository in /tmp/commit-all-example/.git/ $ echo something >> ready $ echo somthing else >> notyet $ git add ready notyet $ git commit -m "Setup" [master (root-commit) 71774a1] Setup 2 files changed, 2 insertions(+), 0 deletions(-) create mode 100644 notyet create mode 100644 ready # Modify the file "ready" and "git add" it to the index $ echo new line >> ready $ git add ready # Modify file "notyet", leaving it unstaged $ echo later >> notyet # Add a new file in a subdirectory, but don't add it $ mkdir sudir $ echo Nope >> subdir/new Use _git status_ to see what.... (and then resume the existing text).

Anonymous  Mar 03, 2010 
Printed
Page 50
1er paragraph after subtitle "Using git commit --all".

The short form for the option '--all' should be '-A' and not '-a'. The paragraph should starts like "The -A or --all option to git commit causes...".

Note from the Author or Editor:
Yes. The paragraph should starts like "The -A or --all option to git commit causes...".

Tomás Abad  Oct 09, 2012 
Printed
Page 53
4th paragraph

"For git rm to work, the file in the working directory must match either the HEAD or the contents of the index." It appears to me that the file must match *both* of these, if they both exist.

Note from the Author or Editor:
Correct. This last sentence of paragraph 4, "For git rm to work.... ...of the index." should just be removed.

John Maxwell  May 13, 2010 
Printed
Page 55
2nd paragraph "A Note on Tracking ..."

"work when tracking when" should be "work tracking when"

Note from the Author or Editor:
Interesting. As I wrote the sentence originally, I said: ...does a lot of work to track when a file is renamed... The copy editor suggested the change to its current form: ...does a lot of work when tracking when a file is renamed... And now the suggestion is: ...does a lot of work tracking when a file is renamed... I'm going to vote for "remove extra words", so let's simplify it: ...does a lot of work when a file is renamed... Other opinions? :-)

Anonymous  Sep 23, 2009 
Printed
Page 56
1st Paragraph in "The .gitignore File"

It would be best if .gitignore was not slip across two lines.

Note from the Author or Editor:
Confirmed. This looks like a bad word-break. Not sure why, but it would be better left unbroken.

Anonymous  Sep 23, 2009 
Printed
Page 62
figure 5-4

The new real tree object should point to 9d3a2 and bd71363, not 9d3a2 and a23bf.

Note from the Author or Editor:
Confirmed, duplicate.

patrik sevallius  Jul 24, 2010 
Printed
Page 109
First paragraph

Two sentences seem to contradict themselves. "At any time during the staging process, the command git diff --cached shows...those changes already staged in the index that will be present in your next commit. When you're finished, git commit captures all changes in your working directory into a new commit." I believe "working directory" should actually be "index".

Note from the Author or Editor:
I'll buy that. So that last sentence should read: When you're finished, git commit captures all changes in your index into a new commit.

Sye van der Veen  May 05, 2011 
PDF
Page 111
2nd paragraph, 2nd sentence

Because file1 is now staged, the working directory and the index are synchronized and should now show any differences. ... should read ... Because file1 is now staged, the working directory and the index are synchronized and should [not] show any differences.

Note from the Author or Editor:
Correct. This is the quintessential typo. Fix as suggested: Because file1 is now staged, the working directory and the index are synchronized and should not show any differences.

Anonymous  Jun 08, 2009 
Printed
Page 114

The output of the "git diff master..bug/pr-1" command should be (I think): diff --git a/ready b/ready index f3b6f0e..abbf9c5 100644 --- a/ready +++ b/ready @@ -1,5 +1,5 @@ stupid znill frot-less -Fix problem report 3 +Fix problem report 1 and not diff --git a/NewStuff b/NewStuff index b4d8596..0f2416e 100644 --- a/NewStuff +++ b/NewStuff @@ -1,2 +1 @@ Something -Fix Problem report 3 diff --git a/ready b/ready index f3b6f0e..abbf9c5 100644 --- a/ready +++ b/ready @@ -1,3 +1,4 @@ stupid znill frot-less +Fix Problem report 1 this is because, as it is written in the same page: '3. Meanwhile, another developer fixes bug pr-3 in the master branch, adding the line "Fix Problem report 3" to the same file in the master branch.' so, the differences are located in the same file (ready), and not in different files (NewStuff and ready). The diff command should show output only for the ready file, and not to the NewStuff, as the latter is supposed to be untouched in this example. Is it right? Thanks, Pedro Flynn

Note from the Author or Editor:
Correct. The example output as written is incorrect and should be replaced as indicated. The output following the text "..only the current state of the files does:" should be changed to this: $ git diff master..bug/pr-1 diff --git a/ready b/ready index c354d22..abbf9c5 100644 --- a/ready +++ b/ready @@ -1,4 +1,4 @@ stupid znill frot-less -Fix Problem report 3 +Fix Problem report 1

Pedro Flynn  Dec 29, 2010 
Printed
Page 129
A bit after the middle

the new git diff output looks [like] this:

Note from the Author or Editor:
The copy editor recommended that sentence be rewritten from: The new <command>git diff</command> output looks this: as: Then the new <command>git diff</command> output is

Geert De Deckere  Jul 17, 2009 
Printed
Page 130
1st paragraph

I think "Where's the diff line about _world_, showing that it was added to the second version, and _worlds_, showing that it was removed in the first version?" should be "Where's the diff line about _world_, showing that it was added to the **first** version, and _worlds_, showing that it was removed in the **first** version?" The merge conflict was resolved in favor of the second version, so it doesn't make sense that there would be diffs with both versions.

Note from the Author or Editor:
So, yeah, this is confusing. I had to draw a 4-part diagram with circles and arrows on the back explaining how each was used to come up with this cryptic sentence. So let's rewrite it being a bit more explicit. Let's rewrite that whole first paragraph on page 130 as: Wait! Something strange happened there. Where does it show where the _world_ line was added to the base version? Where does it show that the _worlds_ line was removed from the _HEAD_ version? As you have resolved the conflict in favor of the MERGE_HEAD version, Git deliberately omits the diff because it thinks you probably don't care about that section anymore.

John Maxwell  May 16, 2010 
Printed
Page 153
4th paragraph

Text reads "In the following example, git status reveals...", but git status is not used in the example.

Note from the Author or Editor:
Yeah, correct. Starting with the 4th paragraph, rewrite it to read: In the following example, _foo.c_ has been accidentally staged in the index. Using _git status_ reveals that it will be committed: $ git add foo.c # Oops! Didn't mean to add foo.c! $ git status # On branch master # Changes to be committed: # (use "git reset HEAD <file>..." to unstage) # # new file: foo.c # and then resume the example text with: $ git ls-files ...

William Pollock  Jun 09, 2010 
Printed
Page 161
Figure 10-7

The top branch in Figure 10-7 should be "master" not "dev".

Note from the Author or Editor:
Correct. The top branch in Figure 10-7 should be "master" not "dev".

Dan Rochat  Nov 04, 2009 
Printed
Page 176
1st paragraph

Text reads "And this looks like the graph in Figure 10-21." This was describing the output of "git show-graph" after using "git rebase --preserve-merges", but Figure 10-21 shows the linearized result of "git rebase" without "--preserve-merges". This text should refer instead to Figure 10-20. Additionally, there should be a reference to Figure 10-21 around p. 175 5th paragraph where the linearization of commits is discussed.

Note from the Author or Editor:
All correct. The text at the top of p176 should read: And this looks like the graph in Figure 10-20. Also as indicated, Figure 10-21 should be referenced. At the end of the 5th paragraph on page 175 which begins "Git needs to...", the figure reference should be added: ...onto the master branch.", as shown in figure 10-21.

William Pollock  Jun 10, 2010 
Printed
Page 182
SSH URLs at the bottom

The first example of a SSH URL contains three slashes which should be only two.

Note from the Author or Editor:
Confirmed. Only two slashes, not three.

Martin  Oct 15, 2009 
Printed
Page 186
2nd paragraph

The final part of this paragraph should be "/tmp/Depot/public_html.git".

Note from the Author or Editor:
Correct. The final path in the paragraph should end with ".git": ...and place it in /tmp/Depot/public_html.git

Fernando Bellas-Permuy  Mar 31, 2010 
Printed
Page 188
4th paragraph

Typo in second sentence, should read: "It is a tracking branch within the origin remote."

Note from the Author or Editor:
Correct. Typo in second sentence. It should read: It is a tracking branch within the origin remote.

Anonymous  Jul 13, 2009 
Printed
Page 189
bottom example

The command *git push origin* should really be git push origin master at least for msysGit 1.7.4.msysgit.0 ("master" is missing).

Note from the Author or Editor:
Yes, this default behavior changed in the newer (1.7.4) versions of Git and so in this case the master branch named must be explicitly used. Change the command to the suggested: $ git push origin master should be sufficient. As another reader observed, adding the remote tracking branch configuration variables into the config file also works.

Hans Salvisberg  Mar 03, 2011 
Printed
Page 190
"Adding A New Developer" paragraphs 1 and 2

Although I can understand that they may be addressing separate developers, I find there is a gender disconnect between the first paragraph and the second. In the first you say: "...it is easy to add a new developer to a project simply by letting _her_ clone...". Then, immediately in the next sentence/paragraph you say: "Let's introduce Bob...". For continuity I think one or the other of these genders should be switched.

Note from the Author or Editor:
Agreed. Change "her" to "him: ...a new developer to a project simply by letting him clone...

Anonymous  Dec 15, 2011 
Printed
Page 197
Figure 11-2

The picture shows a cloned repository that has fewer commits than the original. This directly contradicts the "important result it should illustrate" below on the page that "all the commits from the original repository are copied to your clone"

Note from the Author or Editor:
*sigh* It's true. The "Cloned repository" portion of Figure 11-2 should have two more commit circles added to it so that it is more similar to the "Original repository" portion of the figure.

Holger Hellmuth  Feb 23, 2010 
Printed
Page 198
2nd paragraph

Though the paragraph states that in the relevant diagrams development branches "are distinguished by a lightly shaded background, and tracking branches by darker shaded background", in fact the opposite is correct.

Note from the Author or Editor:
Um, wow. Yeah. So, that second, whole paragraph on a page 198 needs to have "lightly" and "darker" switched in both places where they are mentioned. Let's rewrite that whole paragraph like this: In all of these diagrams, development branches in both the original repository and the derived clone repository, are distinguished by a dark shaded background and tracking branches by a lighter shaded background. It is important to understand that both the development and tracking branches are private and local to their respective repositories. In terms of Git's implementation, however, the dark shaded branch labels belong to the <filename>refs/heads/</filename> namespace while the lighter ones belong to <filename>refs/remotes/</filename>.

Anonymous  Jul 15, 2009 
Printed
Page 198
Second-last paragraph.

I believe an "a" is missing in the second sentence. It reads (in part): "a repository and its clone can diverge into alternate histories as result of separate actions" Perhaps it should be: "...alternate histories as _a_ result of..."

Note from the Author or Editor:
Yeah, so, none of my original sentence, the copy editor's version, nor O'Reilly's printed version of this sentence agree. OK. Time to fix it! Perhaps the version as suggested is best: ... a repository and its clone can diverge into alternate histories as a result of separate actions.

Anonymous  Dec 15, 2011 
Printed
Page 201
Figure 11-5

In the repository labeled "Yours" the label for "origin/master" should point to node D.

Note from the Author or Editor:
Correct. As indicated, in Figure 11-5 on page 201, the label "origin/master" should point to node D, not C.

Anonymous  Jul 15, 2009 
Printed
Page 203
Figure 11-7

In the repository labeled "Yours" the label "origin/master" should point to M to reflect the synchronized nature of the two repositories.

Note from the Author or Editor:
Correct. In the "Yours" repository of Figure 11-7, the origin/master label should also be pointing to node M.

Anonymous  Jul 15, 2009 
Printed
Page 206
very top, 2nd line

In the configuration of the "publish" remote, is the url missing its two forward slashes after "ssh:" and before "git.example.com"?

Note from the Author or Editor:
Yep, that and the .com should be .org. So that lines should be: url = ssh://git.example.org/pub/repo.git

Anonymous  Dec 15, 2011 
Printed
Page 207
4th paragraph

There should be a period between the words "push But" in the middle of the first sentence.

Note from the Author or Editor:
Correct. Simple period addition needed as indicated: ...see the push. But a subsequent...

Anonymous  Jul 18, 2009 
Printed
Page 208
2nd paragraph

The fourth sentence reads "This situation can benefit from large-scale sharing of many the object store by many repositories..." it should be changed to "This situation can benefit from larges-scale sharing of the object store by many repositories..."

Note from the Author or Editor:
Correct. In the last paragraph of the section "Publishing Repositories", on page 208, delete the word "many" to obtain the correct sentence: This situation can benefit from large-scale sharing of the object store by many repositories...

Anonymous  Jul 18, 2009 
Printed
Page 237
Figure 13-1

Commit "B" (revision master~2) is mistakenly marked as "D" in figure 13-1.

Note from the Author or Editor:
Correct. The leftmost circle of Figure 13-1 should be "B".

Pedro Flynn  Dec 31, 2010 
Printed
Page 238
1st line of second paragraph of 1st example

$ echo X >> file ; git commit -mZ file should be $ echo X >> file ; git commit -mX file i.e., change -mZ to -mX

Note from the Author or Editor:
Correct! That first echo line in the example should be: $ echo X >> file ; git commit -mX file

Gary Roth  Aug 26, 2009 
Printed
Page 252
1st paragraph

The sentence "Did you for get to use{git add}?" should be formatted as "Did you forget to use git add?"

Note from the Author or Editor:
Correct. Formatting problem. Braces should be removed, and "git add" should be in a fixed-width font.

Anonymous  Jul 22, 2009 
Printed
Page 263
1st paragraph

Last sentence reads "Output produced by remote hooks still shown to the user..." This should be "Output produced by remote hooks is still shown..."

Note from the Author or Editor:
Confirmed. Rewrite the sentence as suggested: Output produced by remote hooks is still shown...

William Pollock  Jun 28, 2010