Errata

Git for Teams

Errata for Git for Teams

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
PDF, ePub
Second command from the bottom, second before "Working with Commits" section

> If you prefer, you can combine these two commands [`git reset HEAD README.md` and `git checkout -- README.md`] into one:
>
> $ git reset --hard HEAD -- README.md

There is no `git reset --hard -- <filename>`. You were thinking about `git checkout HEAD -- README.md`, not `git reset --hard HEAD -- README.md`.

Note from the Author or Editor:
Replace "reset --hard" with "checkout" in the combined command.

Book repository has been updated with the correction.

Jakub Narębski  Sep 21, 2015 
PDF, ePub
Page 54
Figure 3-14. Merging two branches using the fast-forward strategy is as clean as rebasing

There are two errors in Figure 3-14. "Merging two branches using the fast-forward strategy is as clean as rebasing".

First is that before state is described as "before merge with no fast forward", while after state is described as "after merge with no fast forward". In both "no fast forward" should be replaced by "fast forward".

Second, the state after fast-forward merge is factually wrong. When 'work branch' is merged into 'master' branch as fast-forward, then the 'master' branch is simply advanced to 'work branch'. Commits are not replayed as in the case of rebase; there should be no grayed out copy of balls representing commits in the post image. The state after fast forward merge should have single chain of commits like there is in after state for 'master' branch, while 'work branch' should simply start after last commit / last ball. This looks a bit like the limitation of ball-and-chain diagram, as used in "Git for Teams" book.

The text "commits are still available from the work branch until it is deleted" is wrong. In fast-forward merge case commits are on 'master' branch, and would be present even if 'work branch' was deleted. Not to mention that they are protected by reflog for 30 days.

Note from the Author or Editor:
Diagram 3.14: the two instances of "no fast forward" should be replaced with "fast forward". The text caption below the diagram is correct.

Diagram 3.14: to clarify: the commits are still available in the work branch if the master branch is reset. (They have the same unique identifier regardless of branch when a fast forward merge is used.)

Jakub Narębski  Sep 20, 2015 
PDF
Page 80
Clone an Existing Project

There appears to be a typo in the first sentence of Ch5 section "Clone an Existing Project" page 80

the text reads:

"On code hosting systems, such as GitLab or BitHub, when you navigate to a project page, you are ..."

I believe the BitHub should be: GitHub

Note from the Author or Editor:
BitHub should be changed to GitHub (this appears to be a mashup of Bitbucket and GitHub).

Don E Llopis  Nov 14, 2017 
PDF, ePub
Page 110
Figure 6-2

Figure 6-2. You want to discard changes you’ve made to a file in your working directory; the incorrect copy of the file is not staged or committed

The figure is slightly wrong. The command `git checkout -- filename` does not take "good file" version from the repository, but from the staging area. To copy changes from repository, use `git checkout HEAD -- <ilename` (this would also update the staging area version) or `git show HEAD:./filename >filename`.

It is *subtly* wrong, because usually staging area has the same version of file as the HEAD version in repository.

Note from the Author or Editor:
Diagram 6.2: command should be: git checkout HEAD -- filename

Jakub Narębski  Sep 20, 2015 
Printed, PDF
Page 128
last paragraph

The are now three loose beads rattling around.

should be:
There are now three loose beads rattling around.

Note from the Author or Editor:
Confirmed. Thanks, Matthew!

ORM: This has been fixed in the master branch on new Atlas. Commit ID fa36012.

Matthew Wheaton  Oct 29, 2015 
Printed
Page 130
First paragraph

There is an extra "work" near the end of this sentence:

"Used incorrectly, this can cause chaos on shared branches as new commit objects with different IDs are used to store work identical work."

Note from the Author or Editor:
Change to:

Used incorrectly, this can cause chaos on shared branches as new commit objects with different IDs are used to store identical work.

Kyle Thompson-Bass  Aug 17, 2016 
PDF
Page 153
4th paragraph

Extraneous "a" in "If you do a have a remote set up for this repository,"

Note from the Author or Editor:
Change to:

If you do have a remote set up for this repository

Evan Lloyd  Jul 01, 2016 
Printed
Page 154
1st paragraph


The url "https:// ....projectname>.git" appears again in parentheses in print form:

To add a new remote connection, you will first need to know the URL for the project.
The structure is generally https://<hosting-url.com>/<project-owner’s-name>/<projectname>.
git.

Note from the Author or Editor:
Confirmed, but I don't know how to fix this. It needs to be passed as a literal string so that the http:// doesn't trigger adding a repeated URL in parentheses after the sample URL.

Matthew Wheaton  Oct 30, 2015 
Printed, PDF, Mobi
Page 163
last paragraph

When I’m working in on a task I feel more confident about, I’m more likely to make
radical changes to the working directory without those tiny lifeline commits.

Suggest:

When I’m working on a task I feel more confident about,

Note from the Author or Editor:
Confirmed. Fixed the typo in CH07 in the master branch on new Atlas.

Matthew Wheaton  Nov 03, 2015 
Printed, PDF, Mobi
Page 168
Indent, first paragraph

(I still think you need to do whatever is best for your team, but I’m going to show you the instructions for rebasing where it so that you can see it’s not significantly more difficult to use this method.)

Suggest:

...show you the instructions for rebasing so that you can see it’s not significantly more difficult ...

Note from the Author or Editor:
Confirmed. Fixed the typo in CH07 in the master branch on new Atlas.

Matthew Wheaton  Nov 03, 2015 
Mobi
Page 168
Inset, first paragraph

The easiest way I’ve found to ensure consistency this is to provide copy/paste-friendly documentation, and have people work at the command line.

Suggest:

The easiest way I’ve found to ensure consistency is to provide

(still loving this book!)

Note from the Author or Editor:
Fixed the typo. Edit pushed to the master branch on new Atlas.

Matthew Wheaton  Nov 03, 2015