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