Errata

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
Page 52
First sentence of section "Using git commit --all"

The paragraph should start as:

<para>
The <option>-A</option> or <option>--all</option> option
to <command>git commit</command> causes it to automatically
stage all unstaged,


Note the first option is a capital 'A'.

Jon Loeliger
Jon Loeliger
 
Jun 09, 2013  Jun 21, 2013
Printed
Page 101
2nd paragraph code snippet

git checkout bug/pr-1 should be git checkout -m bug/pr-1

Note from the Author or Editor:
Yes, change that 2nd para code snippet from "git checkout bug/pr-1" to read:
"git checkout -m bug/pr-1" instead.

Alex Krupp  May 12, 2013  Jun 21, 2013
Printed
Page 65
4th paragraph, second sentence

The 2nd sentence in the small, 4th paragraph reads, "Over time, a sequences of changes is represented as a series of commits."

If I'm not mistaken, this sentence should read as, "Over time, a sequence of changes is represented as a series of commits." (Change `sequences' into the singular noun `sequence').

A very minor error but everything counts, I suppose.

Note from the Author or Editor:
Yep, that "sequences" should be "sequence".

David Vernet  Apr 11, 2013  Jun 21, 2013
PDF
Page 363
2nd paragraph

The code lines

$ git commit -m "Add some bar" file
[master 11e0dc9] Add some bar
1 files changed, 1 insertions(+), 0 deletions(-)

are duplicated after line

"And now the ?accident? that causes us to lose a commit:"

The same applies for ePub, I'm referring to PDF as reflow makes difficult stating the right location.

Note from the Author or Editor:
Hmmm.. Yes, I see. Odd indeed.

Let's change the <screen> after "And now the 'accident'... like this:

And now the <quote>accident</quote> that causes us to lose a commit:

<screen>
$ <userinput>git reset --hard HEAD^</userinput>
HEAD is now at f85b097 Add some foo

$ <userinput>git fsck</userinput>
Checking object directories: 100% (256/256), done.
</screen>

Cesare Falco  Mar 17, 2013  Jun 21, 2013
PDF
Page 317
"Examining the Hashes of Submodule Commits" title

"one level deeper than t hey" --> they

The same applies for ePub, I'm referring to PDF as reflow makes difficult stating the right location.

Note from the Author or Editor:
Looks like this typo was introduced at layout. Thanks.

Cesare Falco  Mar 17, 2013  Jun 21, 2013
PDF
Page 145
"Merge Drivers" headline

"A merge diver" --> driver


The same applies for ePub version, I'm referring to PDF as reflow makes difficult stating the right location.

Note from the Author or Editor:
Yep. This typo needs to be fixed twice, actually. First, in the last sentence
on page 145, "merge diver" should be "merge driver". Second, on page 146
para 4,

Cesare Falco  Mar 17, 2013  Jun 21, 2013
Printed
Page 430
rebasing entry

The index entry for rebasing includes p. 416 which does not include anything about it.

Note from the Author or Editor:
Yeah, I don't know where that 416 reference came from.
It certainly doesn't belong there and should be removed.

John Huffman  Feb 14, 2013  Jun 21, 2013
Printed
Page 369
last bullet

I thought "rerere" was a typo. You might want to footnote otherwise clarify that that's really a command. I noticed it on pg 369 but it might need clarity elsewhere too. pg 382 clarifies this command...

Note from the Author or Editor:
Hmm... I did sort of spring that on folks... OK, let's footnote it like this:

<listitem><para>
In the context of <command>git rerere</command><footnote>
<para>
No, that's not a typo.
See <xref linkend="sec-tipstricks-been-here-before" />.
</para>
</footnote>
and you do not need to save the resolutions forever
</para></listitem>

JP Vossen
JP Vossen
 
Jan 02, 2013  Jun 21, 2013
Printed
Page 330
1st bullet, 3rd line

"respectivel" --> respectively

Note from the Author or Editor:
Yep. That typo crept in during layout. Sorry.

JP Vossen
JP Vossen
 
Jan 02, 2013  Jun 21, 2013
Printed
Page 323
2nd bullet

Nitpick:

"...when you check out a SVN project, each subdirectory contains a .svn directory..."

They finally fixed that with SVN 1.7...

http://subversion.apache.org/docs/release-notes/1.7.html#wc-ng
[...]
"A key feature of the changes introduced in Subversion 1.7 is the centralization of working copy metadata storage into a single location. Instead of a .svn directory in every directory in the working copy, Subversion 1.7 working copies have just one .svn directory?in the root of the working copy. [...]"

Note from the Author or Editor:
The times, they are a changing... So, yeah, let's adjust the beginning
of that paragraph like this:

<listitem>
<para>
The working directory lacks <filename>.svn</filename>
directories, but it does have the familiar <filename>.git</filename> directory.
Prior to SVN version 1.7, when you check out an SVN project,
each subdirectory contains a <filename>.svn</filename>
directory for bookkeeping.

JP Vossen
JP Vossen
 
Jan 02, 2013  Jun 21, 2013
Printed
Page 314
1st para

"Although the dedicated chapter of submodules provides..."

Huh??? Isn't that THIS chapter? Or is that supposed to mean ch16? That needs clarification.

In general ch17 seemed to me to be a last-minute addition that doesn't quite integrate or flow with the rest of the book in some vague way I can't define better.

Note from the Author or Editor:
Yeah, I'll fix that sentence to refer to Ch 16 better. How about this:

<para>
Although <xref linkend="chap-Submodules" /> provides an exhaustive list of
commands, a quick recap of the basic submodule actions is
helpful:
</para>

JP Vossen
JP Vossen
 
Jan 02, 2013  Jun 21, 2013
Printed
Page xii
5th para

"...and interacting with Subversion repositories (Chapter 17)." should say "Chapter 18" since ch17 is actually "Submodule Best Practices."

Note from the Author or Editor:
Yeah, and it should mention chapters 17 in with 16. Like this:

<para>
The next four chapters cover advanced topics of interest:
the use of hooks (<xref linkend="chap-Hooks" />),
combining projects and multiple repositories into a superproject
(<xref linkend="chap-Submodules" />
and <xref linkend="chap-SubmoduleBestPractices" />),
and interacting with Subversion repositories
(<xref linkend="chap-Subversion" />).
</para>

JP Vossen
JP Vossen
 
Jan 02, 2013  Jun 21, 2013
Printed
Page 210
Line 22

"Initialized empty Git repository in /tmp/public_html/.git/" should be "Initialized empty Git repository in /tmp/bob/.git/.

Note from the Author or Editor:
Neither is correct with today's Git! With 1.8.0 I get:

$ pwd
/tmp/bob
$ git clone /tmp/Depot/public_html.git
Cloning into 'public_html'...
done.

So yeah, let's update the <screen> in Section "Adding a New Developer" to begin:

<screen>
$ <userinput>cd /tmp/bob</userinput>
$ <userinput>git clone /tmp/Depot/public_html.git</userinput>
Cloning into 'public_html'...
done.

$ <userinput>ls</userinput>
public_html

Kristofer Nelson  Jan 01, 2013  Jun 21, 2013
Printed
Page 207
Lines 16-17

"origin" is wrapped as "ori gin."

Note from the Author or Editor:
Yeah, that's a bad word break for sure. Also see p 198 for another occurrence.

Layout: Can we ensure that this word is kept together?

Kristofer Nelson  Jan 01, 2013  Jun 21, 2013
Printed
Page 198
Lines 13-14

In the last sentence before the heading "Remotes," origin/ is wrapped as ori gin/.

Note from the Author or Editor:
Hmmm... Second occurrence of this bad word break with 'origin'. See p 207.

Layout, can we fix this?

Kristofer Nelson  Jan 01, 2013  Jun 21, 2013
Printed
Page 171
Lines -1 and -2

"master the squash" should be "squash the master".

Note from the Author or Editor:
Wow. Yes. And that's not how it appears in my sources, so that crept in
during layout or printing. It should be:

Thus, you would also like to <firstterm>squash</firstterm> the
<literal>master</literal> and <literal>master^</literal> into
just one commit.

Kristofer Nelson  Jan 01, 2013  Jun 21, 2013
Printed
Page 104
Line 25

The line "! [master] Added Bob's fixes." should be indented four spaces.

Note from the Author or Editor:
Yep. It should look like this:

$ <userinput>git show-branch</userinput>
! [bug/pr-1] Fix Problem Report 1
! [bug/pr-2] Added Bob's fixes.
! [bug/pr-3] Added a bug fix for pr-3.
! [dev] Started developing NewStuff
* [master] Added a bug fix for pr-3.
-----

Kristofer Nelson  Dec 20, 2012  Jun 21, 2013
Printed
Page 102
Line 6

The line "! [master] Added Bob's fixes." should be indented four spaces.

Note from the Author or Editor:
Yes. It should look like this:

$ <userinput>git show-branch</userinput>
! [bug/pr-1] Fix Problem Report 1
! [bug/pr-2] Added Bob's fixes.
* [bug/pr-3] Added Bob's fixes.
! [dev] Started developing NewStuff
! [master] Added Bob's fixes.
-----

Kristofer Nelson  Dec 20, 2012  Jun 21, 2013
Printed
Page 111
5th paragraph

The option "--M" should instead be "-M or --find-renames". Note that "--M" in the book has two hyphens, while the correct option has only one hyphen.

Note from the Author or Editor:
Yep. Both the option and the text should use a single-hyphen.

<term>
<option>-M</option>
</term>
<listitem>
<para>
The <option>-M</option> option

Kristofer Nelson  Dec 20, 2012  Jun 21, 2013
PDF
Page 36
1st paragraph

An astute reader my have formed a lingering question about Git?s data model and its storage of individual files:

In the above sentence, "my have" should be changed to "may have." It is just a typo.

Note from the Author or Editor:
Change "my have" to "may have" in the first sentence of page 36.

Soonbaek Yun  Dec 12, 2012  Jun 21, 2013
Printed
Page 49
3rd non-code paragraph

"Initially, there are no files and the tracked, ignored, and therefore untracked sets are empty."

The word "therefore" seems misplaced.

Note from the Author or Editor:
Well, we can remove it if it clears things some.

So, let's remove the word "therefore" from the sentence beginning "Initially, there are..."

Kristofer Nelson  Dec 02, 2012  Jun 21, 2013
Printed
Page 37
last paragraph

Text says: "... so Git introduces a new tree, cafed00d." which is a repetition of the tree mentioned in the paragraph before and is irritating. The correct text would be: "... so Git introduces a new tree, 1010220.", because that tree ID is the one the paragraph is talking about.

Note from the Author or Editor:
Hmmm... Yeah, that is a little strained. Sorry.

Let's combine the two paragraphs that begin "As in the .." and "Because the top-level..."
into just one paragraph like this:

<para>
As in the previous picture, the new commit has
added one associated tree object to represent
the total state of directory and file structure.
Because the top-level directory is changed by the
addition of the new subdirectory, the <emphasis>content</emphasis>
of the top-level tree object has changed as well,
so Git introduces a new tree, <literal>cafed00d</literal>.
</para>

Roman Bl?th  Nov 27, 2012  Jun 21, 2013
Printed
Page 15
Lines 6-7

msysGit's home page is now at http://msysgit.github.com.

Note from the Author or Editor:
*sigh* It does appear that it has moved...

Let's update the paragraph beginning "First, download..." to read:

<para>
First, download the latest version of the
installer from its home at
<ulink url="http://msysgit.github.com/" />.
The file to collect is usually called something like
<filename>Git-1.8.3-preview20130601.exe</filename>.
</para>

Kristofer Nelson  Nov 17, 2012  Jun 21, 2013
Printed
Page 13
Paragraph -5

The book states that msysGit 1.6.0 does not support git-svn. While this is true, msysGit reintroduced git-svn in version 1.6.2, which was released at the end of 2008. The book states that it is describing Git 1.7.9 on page 11 and mentions msysGit 1.7.10 on page 14, so this paragraph should be updated to remove any mention of git-svn not being supported.

Note from the Author or Editor:
Yeah. So let's rewrite the entire paragraph beginning "Originally, Cygwin.." and
merge it with the following paragraph as:

<para>
Both versions work well
and support an almost identical set of features.
The version you choose is a matter of personal preference.
If you aren't sure which one you want, here are some rules of thumb.
</para>

Kristofer Nelson  Nov 17, 2012  Jun 21, 2013
Printed
Page 4
Line 18 (under Be Free, as in Freedom)

'Nuff should be spelled with a U+2019 (?) instead of a U+2018 (?).

Note from the Author or Editor:
I'm good with that.

So, let's use this:

<varlistentry>
<term>Be Free, as in Freedom</term>
<listitem>
<para>
&rsquo;Nuff said.
</para>
</listitem>
</varlistentry>
</variablelist>

Kristofer Nelson  Nov 17, 2012  Jun 21, 2013
PDF
Page 65
Chapter 6: "Commits"

A list of admittedly pedantic nitpicks throughout Chapter 6 (page numbers reflect PDF version):

65 (second para): "check in" would be better written as either "checkin" or "check-in"
66 (second para): "wellsuited" should be "well-suited"
72 (second para): "work back" should be "working back"
73 ("git log" output): On my system, using "--abbrev-commit" does not add the ellipses after the first 7 digits of the commit SHA1 value. That is, you wouldn't get "commit 6d9878c...", just "commit 6d9878c". Perhaps the ellipses were printed in an earlier version of Git.
78 (footnote): I think the explanation of "gitk" might be confusing -- it's not considered a "subcommand" simply because it *isn't*. In Ubuntu, at least, it's a totally separate package. I think the footnote is adding potential confusion when none is needed -- just point out that gitk is a separate package independent from the base "git" package and let it go at that.

I think that's it.

Note from the Author or Editor:
Yes, "check in" should be "check-in" on p 65 para 2.
Yes, "well suited" should be "well-suited" on p 66 para 2.
I don't think "working back" is correct on page 72.
Yes, remove the ellipses from "commit 6d9878c..." and "commit 30684df..." from the
example at the top of page 73.

For the footnote on page 78, number 3, let's rewrite it as:

<footnote>
<para>
The <command>gitk</command> command is not a Git subcommand;
it is its own independent command and installable package.
</para>
</footnote>

Robert P. J. Day  Sep 15, 2012  Jun 21, 2013
PDF
Page 20
Canada

Page 20 claims that Git still supports the "git-" form of subcommands, such as git-commit, git-log and so on. However, on my Ubuntu 12.04 system, those hyphenated forms of the commands are not in my search path (anymore).

A quick check shows that they exist under the /usr/lib/git-core/ directory, which suggests they're only for Git *internal* use these days, also suggesting that regular users are expected to use strictly the "git <subcommand>" form of the command. Unless I've misread something.

Note from the Author or Editor:
Well, yeah.... Things have progressed some...

For starters, the paragraph on page 20 beginning "In contrast , --amend" needs the
extra space before the comma removed.

Let's rewrite the paragraph beginning "Historically, Git..." like this:

<para>
Historically, Git was provided as a suite of many simple,
distinct, standalone commands
developed according to the <quote>Unix toolkit</quote> philosophy:
build small, interoperable tools.
Each command sported a hyphenated name,
such as <command>git-commit</command>
and <command>git-log</command>.
However, modern Git installations no longer support the
hyphenated command forms and instead use a single
<command>git</command> executable with a subcommand.
</para>

Robert P. J. Day  Sep 13, 2012  Jun 21, 2013
PDF
Page 11
Canada

It would appear that the location of the Git source at http://git.kernel.org is no longer the directory pub/software/scm, but pub/scm/git.

Note from the Author or Editor:
Yep. Kernel.org had some, adjustments....

Let's update the paragraph beginning "If you prefer to download..." to read:

<para>
If you prefer to download the Git code from its canonical source
or if you want the latest version of Git, visit Git's master repository.
As of this writing, the master repository for Git sources is
<ulink url="http://git.kernel.org" />
in the <filename>pub/scm/git</filename> directory.
</para>

Robert P. J. Day  Sep 13, 2012  Jun 21, 2013
PDF
Page 10
Canada

The note/trap on p. 10 claims that Debian and Ubuntu have a package called "git" that is actually the GNU Interactive Tools. Not anymore. As of 12.04 (as the author noted earlier), "git" does indeed refer to the basic Git package, while GNU Interactive Tools are now available as "gnuit".

Note that, just below that, the command does indeed (as of 12.04) correctly refer to the "git" package.

Note from the Author or Editor:
Gah. Yes. We should simply remove this Warning entirely as it
tries to warn of a now non-existent issue.

Robert P. J. Day  Sep 13, 2012  Jun 21, 2013
PDF
Page 2
Canada

Pedantically speaking, the proper phrase for the acronym "CVS" should be "Concurrent Versions System", not just "concurrent version system", at least as far as I know.

Note from the Author or Editor:
Oy vey. Make it so!

In the paragraph beginning "Prior to Git, ..." Change "concurrent version system"
to "Concurrent Versions System".

As an interesting note, it was capitalized in my source already.

Robert P. J. Day  Sep 13, 2012  Jun 21, 2013
PDF
Page 90
First line in the "Branch or Tag?" Box

The paragraph starts with a number:

Quoted text:

"
90 A branch and a tag seem similar, perhaps ...
"

Note from the Author or Editor:
Hmmm... True. This appears to have been introduced in layout or printing.
It should be removed.

Maksim AbuAjamieh  Sep 01, 2012  Jun 21, 2013
PDF
Page 88
2nd paragraph (Using Pickaxe) section

The Using Pickaxe paragraph starts with numbers:
Quoted text:

"
Using Pickaxe
87-88 Wheareas git blame tells you about ...
"

I guess these are page numbers entered by mistake

Note from the Author or Editor:
Hmmm. True. But it isn't in my source. Looks like it was introduced
somewhere in layout and printing. It should be removed.

Maksim AbuAjamieh  Sep 01, 2012  Jun 21, 2013
Printed
Page 229
5th paragraph, end of 1st sentence

5th paragraph, end of 1st sentence ends with:

"...you can establish the relationship using the --upstream option."

--upstream should be (I think) --set-upstream

Note from the Author or Editor:
Yep, that should be --set-upstream instead.

So, let's fix the option in that paragraph like this:

<para>
And, if you already have a topic branch that you decide should
be associated with an upstream repository's remote-tracking branch,
you can establish the relationship using
the <option>--set-upstream</option> option.

Jeff Meyer  Aug 27, 2012  Jun 21, 2013
Printed
Page 231
3 lines of examples following the 5th paragraph

There are 3 example lines, showing the equivalence of several remote git commands, due to the defaults used by git:

$ git push upstream new_dev
$ git push upstream new_dev:new_dev
$ git push upstream new_dev:refs/head/new_dev

However, the error here (I think) is that "upstream" should be origin -- or perhaps "--set-upstream origin". I.e., the example should be either:

$ git push origin new_dev
$ git push origin new_dev:new_dev
$ git push origin new_dev:refs/head/new_dev

or:

$ git push --set-upstream origin new_dev
$ git push --set-upstream origin new_dev:new_dev
$ git push --set-upstream origin new_dev:refs/head/new_dev

Personally, I prefer the latter -- I find that always using --set-upstream (or it's abbreviated format, -u) to create tracking information makes a lot of sense.

I'm calling this a serious technical mistake, because for new users, this is a command that needs to be done, but isn't performed frequently enough to be lodged in the git user's memory.

Thanks,

Jeff Meyer
Fluke Electronics
Jeff.Meyer@fluke.com

Note from the Author or Editor:
Uh, those are just examples where "upstream" is any generically named upstream
repository. It could be "origin", or it could be the name of some other remote that
is considered upstream of this one.

To clarify, let's add this paragraph right after the three-push screen:

<screen>
$ <userinput>git push upstream new_dev</userinput>
$ <userinput>git push upstream new_dev:new_dev</userinput>
$ <userinput>git push upstream new_dev:refs/heads/new_dev</userinput>
</screen>
Naturally, <literal>upstream</literal> would be a reference
to an appropriate upstream repository and might typically be
<literal>origin</literal>.
</para>

Jeff Meyer  Aug 27, 2012  Jun 21, 2013