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.

The following errata were submitted by our customers and have not yet been approved or disproved by the author or editor. They solely represent the opinion of the customer.

Color Key: Serious technical mistake Minor technical mistake Language or formatting error Typo Question Note Update

Version Location Description Submitted by Date submitted
PDF Page 9
3rd para ("Debian/Ubuntu")

Apparently, an update to what the Git package is actually called in Ubuntu -- as of Vivid Vervet, the list of packages ( claims thusly:

git-core (1:2.1.4-2.1)
fast, scalable, distributed revision control system (obsolete)
virtual package provided by git

So you can decide how (or if) to reword that section.

Robert P. J. Day  Jul 21, 2015 
PDF Page 10
Top pf page

In the latest package list, Ubuntu now mentions a package:

git-cola (2.0.6-1) [universe]
highly caffeinated git GUI

You can decide if you want to mention that at some point.

Robert P. J. Day  Jul 21, 2015 
Printed Page 21
Last line

"Initialized empty Git repository in .git/"
should be
"Initialized empty Git repository in ~/public_html/.git/"
where ~ should be expanded to the absolute path, such as /Users/username/home/public_html/.git/

Cong Liu  Jan 13, 2018 
Printed Page 22
Code snippet at the bottom

$ git status

# On branch master
# Initial commit
# Changes to be committed:
# (use "git rm --cached <file>..." to unstage)
# new file: index.html

should be

$ git status
On branch master

No commits yet

Changes to be committed:
(use "git rm --cached <file>..." to unstage)

new file: index.html


Cong Liu  Jan 13, 2018 
Printed Page 23
Code snippet at the bottom

$ git status

# On branch master
nothing to commit (working directory clean)

should be

$ git status
On branch master
nothing to commit, working tree clean



macOS High Sierra 10.13.2

$ git --version
git version 2.14.1

Cong Liu  Jan 13, 2018 
Printed Page 23
First code snippet

$ git commit -m "Initial contents of public_html" \
--author="Jon Loeliger <>"

Created initial commit 9da581d: Initial contents of public_html
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 index.html

should be

$ git commit -m "Initial contents of public_html" \
> --author="Jon Loeliger <>"
[master (root-commit) d6518a6] Initial contents of public_html
Author: Jon Loeliger <>
1 file changed, 1 insertion(+)
create mode 100644 index.html


In my experiment, the SHA1 hash head is d6518a6 though. It corresponds to 9da581d in the original code snippet.


macOS High Sierra version 10.13.2
git version 2.14.1

Cong Liu  Jan 13, 2018 
PDF Page 24
bottom of page

Isn't it true you have to

git commit -am "comments"

to commit the file? It is said that you already git add the file, but the author also did a commit already, so doesn't he need to git add again, or use git commit -am ?

Kenneth Lum  Feb 13, 2016 
Printed Page 26
Viewing commit differences

The diff doesn't show a difference in the line "My web site is alive!" but the original file (p21) is "My website is alive!" so either p21 or p26 are incorrect.

Jonathan Hunt  Jul 12, 2014 
PDF Page 26
Top pf page

First sentence claims that "show-branch" shows summary only "for the current development branch." Pretty sure that's not true -- man page suggests it does it for all branches:

"git-show-branch - Show branches and their commits"

Certainly seems to work that way.

Robert P. J. Day  Jul 21, 2015 
PDF Page 32
"Git Obejct Types"

That section suggests that the object store contains things like "log messages" ... technically, isn't the object store the directory .git/objects? Because if it is, the log messages are stored in a sibling directory, .git/logs. Or am I missing something here? Just trying to be precise.

Robert P. J. Day  Jul 21, 2015 
Printed Page 34
3rd paragraph

"In fact, Git does not track file or directory names, which are associated with files in secondary ways."

In my opinion, this sentence is not entirely correct, since file and directory names are part of tree objects, and tree objects are tracked.

The sentence is also contradicted on p. 41, paragraph 4: "As mentioned before, Git tracks the pathnames of files through another kind of object called a tree."

Ismail Daif  Mar 22, 2019 
PDF Page 37-8

Not an error so much as that the two figures (4-1 and 4-2) make no mention of the names of the files or subdirectory that is being created, which technically is fine given Git's content-based addressing, but new users might get confused looking for the filenames in those figures.

Robert P. J. Day  Jul 27, 2015 
Printed Page 40
near top

The hash for the file "hello.txt" will change if the end-of-line character is not a linefeed.

I suspect there is an implicit assumption throughout the book that the reader is trying the examples in a linux-like environment. Perhaps a statement to this effect should be made somewhere, say the Preface under "Conventions Used ...".

Michael Soyka  Mar 25, 2016 
Printed Page 41
Line 2

"40 bytes of hexadecimal"
should be
"40 digits of hexadecimal"

Cong Liu  Jan 14, 2018 
PDF Page 42
United States

Such a hash function is sometimes called a digest to emphasize that it serves as a sort of summary of the hashed object.

a function is a function. The above sentence should say:

Such a hash function *result* is sometimes called a digest to emphasize that it serves as a sort of summary of the hashed object.


Such a hash function *result* 3b18e512dba79e4c8300dd08aeb37f8e728b8dad is sometimes called a digest to emphasize that it serves as a sort of summary of the hashed object.

Because the digest is something like 3b18e512dba79e4c8300dd08aeb37f8e728b8dad

It is not correct to say that the "function" is the digest.

Kin Lum  May 02, 2014 
Printed, PDF Page 43
6th paragraph ("But Git also relies...")

This seems a bit confusing:

"Consider the most recent commit (or its associated tree object). Because it contains, as part of its content, the hash of its parent commits and of its tree and that in turn contains the hash of all of its subtrees and blobs recursively through the whole data structure, it follows by induction that the hash of the original commit uniquely identifies the state of the whole data structure rooted at that commit."

What exactly does "the original commit" refer to? For this to make sense to my mind it must refer to "the most recent commit" you begin by asking the reader to consider. But the containing sentence has just constructed an argument based on a sequence of temporally prior 'ancestor' (you say 'parent' explicitly) commits. In this context, I would tend to think of "original commit" as the earliest or "base" commit in the induction. Perhaps naming the original commit would help:

'Consider the most recent commit (C), or, equivalently, its associated tree object.'


' follows by induction that the hash of the original commit (C) uniquely identifies...'

Or is my understanding mistaken?


Phillip Hutto  Mar 16, 2014 
Printed Page 44
First example under "Commits"

The string argument for the "echo" command includes the characters "\n". The example assumes that "echo" will convert them into a single newline character but, for that to happen, the "-e" option needs to be included, at least nowadays.

Michael Soyka  Mar 25, 2016 
Other Digital Version 52
Confirmed Errata

The confirmed errata for page 52 says that the option to commit all files is -A, with a capital A. However, the book is correct: it should be a lowercase -a. Perhaps you were thinking of git add, which uses capital -A to add all files (which is an annoying inconsistency, especially as neither git commit -A nor git add -a are used so there's no reason for the options to differ).

Kristofer Nelson  Sep 27, 2013 
PDF Page 54
code examples

Using epub, but referencing PDF.

On page 54 in the Using git rm section, it would be helpful to tell the reader to switch back to the my_stuff repository created back on page 49. The git status of the work on pages 54-55 shows the state of the my_stuff repository, but if you're following along and doing the work you're still in the commit-all-example from pages 52-53.

Sam Gechter  Mar 27, 2014 
Printed Page 55
trap paragraph

On page 48, a "tracked" file is defined as one already in the repository or currently staged. On page 54, it says that "git rm" removes a file from both the repository and working directory. Then, two paragraphs later, it says that the command does not remove a file from the repository. This sounds like a contradiction.

The trap note on page 55 says that the "rm" command makes a file untracked. But if it does not completely remove the file from the repository, then according to the definition of a tracked file, the file should still be tracked.

I have the suspicion that the index actually contains an entry for every file in the repository, not just the staged ones. It would be helpful to clarify this one way or the other, because having a clear mental model of the index is important.

~~ Paul

Paul C. Anagnostopoulos  Aug 24, 2013 
PDF Page 56
Entire top half of page

The two code examples on that page seem unconnected. This section seems to be talking about officially removing files with "git rm", which is fine. And if one officially removes a file called "data", then the first example, trying to add it back with

$ git add data

will, of course, fail, since the file will no longer exist in your working directory.

But the second example to allegedly fix this:

$ git checkout HEAD -- data

will also surely fail, since that file is no longer part of HEAD. Perhaps you meant "HEAD^"? In any event, that's a very confusing example.

Robert P. J. Day  Sep 18, 2015 
Printed, PDF, ePub, Mobi, , Other Digital Version Page 62
fig 5-4

I may be wrong but I think Figure 5-4 on page 62 is inaccurate. The latest tree node (the triangle on the right) in the object store is pointing to the wrong file. It's pointing to "foo" while it should have been pointing to "quux".

Anonymous  Jul 22, 2013 
Printed Page 65
paragraphs 3 and 6

The third paragraph on page 65 says that Git compares the index to the current commit and creates new blobs for files that have changed. I don't believe this is true. Blobs are created when you perform add commands and the like, not when you commit. All commit does is create a tree object from the index and a corresponding commit object. (commit -a does create blobs, but that is irrelevant.)

Paragraph 6, in parallel, says that a commit is the only way to introduce changes to the repository. But add, rm, etc. also make changes to the repository. A commit is the only way to permanently commit the changes to the current branch.

~~ Paul

Paul C. Anagnostopoulos  Aug 25, 2013 
PDF Page 68
2nd. paragraph of "refs and symrefs" section

It is read:
Local topic branch names, remote tracking branch names, and tag names are all refs.

And should be:
Local topic branch names, remote tracking branch names, and tag names are all symrefs.

Alejandro Hdez. Angeles  Dec 17, 2014 
Printed Page 79

On page 79, there is the phrase "The range M~12..M~10 represents two commits, the 11th and 10th oldest commits, ...", and the word "oldest" should be "newest".

Anonymous  Feb 20, 2015 
Printed, PDF Page 81
United States

Text the says Figure 6-13 'topic' "started as a branch of master but Figure 6-13 shows the commit 'A' on the 'topic' branch existing before commit 'B'

Wayne Stidolph  Dec 07, 2013 
PDF Page 117
3rd paragraph

It is read:
"In this case, git log master..maint represents the five individual commits V , W , ..., Z"

And should be:
"In this case, git log master..maint represents the eleven individual commits V , W , ..., Z and C, D, ..., H".

Alejandro Hdez. Angeles  Dec 18, 2014 
Printed Page 123
2nd paragraph (begins with "Here")

"one commit behind the current head" is mistaken, because the current head *is* alternate, as we just checked it out; the phrase should be instead "one commit behind the master" or "one commit behind previous head".

Enrico Maria De Angelis  Apr 10, 2022 
Printed Page 124
First line

There is a extra "what" in the sentence "You can use another commit graph viewing tool, a part of git log, to see what what's been done"

Anonymous  Feb 12, 2017 
PDF Page 127
The template message Git places in the text editor


should be

# Conflicts:
# file

Anonymous  Feb 13, 2017 
Printed Page 157
Examoke near bottom of page

The git command "rev-parse" is used to display a sha. I believe that this command had not been used in the book prior to this. When I looked up the command, the description does not suggest to me that "rev-parse" would be the logical command for this purpose.

For this reason, the command should have been explained at that point. Also, an inexperienced reader, like myself, would more likely have used the log command to get this information so when the author uses "rev-parse" instead, the reason should be stated.

This same command is used for the same purpose at the top of page 158 as well.

Michael Soyka  Apr 13, 2016 
Printed Page 163
2nd paragraph

It says that the command:

$ git cherry-pick X..Z

". . . would apply new commits X-prime, Y-prime, and Z-prime on the master branch."

I think it should only be two commits cherry picked (Y and Z). This would be all the commits reachable from Z but not from X.

Ross Osborn  Jan 24, 2019 
Printed Page 166
Botton third

The authors write "With an amendment, anyone can see that the original commit has been modified and that it replaces the existing commit." This statement is apparently contradicted by Figures 10-10 and 10-11 on page 167. In those Figures, commit "C" has been amended to be commit "C'" and "C" is not shown in Figure 10-11.

That said, the reader knows of the prior existence of commit "C" because it was created on page 165. However, I don't think that's what the authors meant, or is it?

To summarize, if commit "C" no longer exists in the repository, the authors' statement is wrong. If it does remain, it would seem appropriate to demonstrate how the presence of commit "C" would be revealed.

Michael Soyka  Apr 17, 2016 
PDF Page 188
third-to-last paragraph of (printed) page 188 in pdf format

In the middle of (printed) page 188 in the pdf format, the following paragraph starts out fine, but I'm confused about the second sentence which contains "...tracking branchtracking branches...".

Kenneth A. Wolcott  Nov 19, 2013 
Printed Page 206
last line

The name of the bare repository in the example is not consistent with example in the previous section. Should it end with "/public_html.git" rather than "/public_html"?

MattWette  Dec 18, 2013 
Printed Page 206
4th paragraph

The book has the following on page 206 2nd Ed near the top:

Because you used the --bare option during this clone operation, Git did not introduce the normal, default origin remote.
Here's the configuration int he new, bare repository:
# In /tmp/Depot/public_html.git
$cat config
repositoryformatversion = 0
filemode = true
bare = true

but when I ran the command on my git (version I *do* get the origin remote and my config file looks like the following:

repositoryformatversion = 0
filemode = true
bare = true
[remote "origin"]
url = /root/public_html

Why do I have [remote "origin"] stanza in my result? Did something change in the git version used in the book and my version of What changed and why?

Anonymous  Feb 21, 2015 
Printed Page 209
subsection "pushing your changes"

This comment is a suggested improvement.

On pages 204-208, the authors describe a process for setting up a bare repository based on a pre-existing local repository. On page 209, the command "git push origin master" is used instead of "git push" to send local changes to the remote. As I understand it, the first git command is necessary because the local config file does not have a "branch master" section.

Perhaps there's a good reason for using first command instead of the second but none is given. The reason I bring this up is because on page 206, 3'rd paragraph in subsection "make your own remote", it says "in a sense, you must manually convert your initial repository into a derived clone". If this is one of the aims of the authors, then achieving it would would allow the use of the simpler "git push" and the repository behavior would be the same as if it had been cloned.

When I followed the steps in the text, git would not allow the simpler "git push" command. Instead, it recommends "git push --set-upstream origin master" which apparently adds the "branch master" section to the config file which then allows use of the shorter command thereafter.

Michael Soyka  May 30, 2016 
Printed Page 212
3rd paragraph

In the section 'Getting Repository Updates' there is a line that states "Let's assume you did this after getting Bob's latest changes" (Bob changed the fuzzy.txt file). I've been following the examples but there was no command example given in the book on how to properly pull Bob's change to fuzzy.txt into the 'public_html' repo. I tried the command 'git pull', but this did not bring don the change to fuzzy.txt to my working dir and I got the following from this command:

remote: Counting objects: 5, done.
remote: Compressing objects: 100% (3/3), done.
remote: Total 3 (delta 1), reused 0 (delta 0)
Unpacking objects: 100% (3/3), done.
From /tmp/Depot/public_html
ba0b9d9..d90a85c master -> origin/master
There is no tracking information for the current branch.
Please specify which branch you want to merge with.
See git-pull(1) for details

git pull <remote> <branch>

If you wish to set tracking information for this branch you can do so with:

git branch --set-upstream master origin/<branch>

Why did a simple 'git pull' command fails and what does the above mean?

I did the command 'git pull origin master' and this seemed to do it but I do not know if this was the proper way. Hoping to have clear examples in Ch 12 as this is a critical chapter that I'd like to fully understand.

Anonymous  Feb 23, 2015 
Printed Page 223
2nd paragraph

> The git stash push command will save your current index (when you supply the --staged flag) and working directory stateā€¦

This makes it read like you need to supply the --staged flag to include the working directory. However, the --staged flag will modify git stash so it _only_ saves the state of the index.

Christoph Lupprich  Feb 23, 2023 
Printed Page 224
figure 12-7

In figure 12-7, the commit graph for "Origin" appears to show a branch being created and then merged into "master" even though there is only one branch on "Origin". There is no such confusion in the "Yours" repository because there are two branches: master and origin/master.

I see this as confusing because in most/all similar diagrams prior to this one, multiple "paths" corresponded to different branches. I'm not sure if the example should be changed or if it is an opportunity to explain what I think is a not uncommon occurrence.

Michael Soyka  May 30, 2016 
PDF Page 300
Footnote #4

The protocol in footnote should change from git:// to

Chaz Ubell  Dec 19, 2014 
Printed, PDF Page 360
3rd paragraph

The "too" in the first sentence of the third paragraph should be "to":

Furthermore, although this example only had two hunks in one file, the staging operation generalizes TO many hunks, possibly split, in many files.

admoman  Jun 28, 2013