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.
| 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 |
|