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.
| Version |
Location |
Description |
Submitted by |
Date submitted |
| Printed |
Page 19
Bottom; penultimate example |
The line
$ echo 'My website...'
uses single quotes for fixed strings. Most others use double quotes. As a quoting fanatic, I prefer single quotes to document that I do not want any substitutions, but for consistency, it would be simpler to change just this example.
|
Felix Gatzemeier |
May 24, 2012 |
| Printed |
Page 22
Middle |
Before the
$ git commit index.html
there should be a
$ git add
If the unsuspecting user leaves that out, git finds no changes in the commit.
On the other hand, if the user goes through the example in just one terminal session (which I deem reasonable),
$ cd ~/public_html
is superfluous. And if the cwd is somewhere else, everybody with basic shell skills will manage to get to the right place.
|
Felix Gatzemeier |
May 24, 2012 |
| Printed |
Page 23
Middle |
Most of the git show output is self-explanatory. Just the index numbers are mysterious, at least for me. And they will not be explained until p. 250!
I suggest adding a paragraph below the example like the following:
There are more IDs in this output. The diff contains an 'index' line mentioning prefixes of the IDs of the compared objects. Go ahead, poke around to find out what they are.
The reader would still have to guess that the ID '00000000' is somewhat special.
|
Felix Gatzemeier |
May 24, 2012 |
| Printed |
Page 24
Middle |
The explanation of the git diff example refers to the IDs used as the "first revision" and "earlier version of the content". The IDs are, however, commit IDs and as such do not (directly) inidicate content.
At this point in the book, a novice reader will not notice the difference, but the very nature of content-adressable storage surfaces here: a reader will hardly be able to replay the steps so she gets the same commit IDs (since they incorporate timestamps). *But* if she does it right, she gets the same file hashes.
Suggestion: Rephrase to
As is the convention, the first commit, identified by ..., contains the earlier version of the content, while the second commit, identified by ..., contains the newer one.
|
Felix Gatzemeier |
May 24, 2012 |
| Printed |
Page 31
2nd paragraph |
I cannot fathom the meaning of the last sentence in the paragraph starting with "The project's state..." and I think the paragraph is better off without it. If it does have meaning, please clarify what "the project's state" may be here. I usually think of it as the content of the working directory. But here, it may be a commit or some goal. Furthermore, this sentence is in a section about the index. I cannot make out the connection between the state, the index, the goal and the working directory.
Inside the sentence, "a commit and a tree" is mentioned - for me, a project's state would encompass the contents of the files, too, so that it should either be technically more correct "a commit, its tree and the blobs it points to" or more commonly just "a commit".
|
Felix Gatzemeier |
Jun 02, 2012 |
| PDF |
Page 43
"You create an annotated, unsigned tag ..." |
The book states
" You create an annotated, unsigned tag with a message on a commit using the git tag
command:
$ git tag -m "Tag version 1.0" V1.0 3ede462 "
There is no mention of how to create a lightweight tag, so I googled for more information. I found many sources which seemed to say that git will make a lightweight tag unless you specify the -a option, which is missing from the command above.
Eventually I noticed that lightweight tags apparently can't have messages associated with them, so I figured that perhaps the -m option automatically implies -a as well. The man page for git-tag confirmed my conjecture:
" If -m <msg> or -F <file> is given and -a, -s, and -u <key-id> are absent, -a is implied "
Therefore it would seem that although the quoted passage from the book is technically correct - the command does indeed create an annotated tag with a message - I'm probably not the only git newbie who found it misleading. The text should explicitly state that your tag will be lightweight unless you specify -a or -m, where the latter happens to imply -a because a lightweight tag can't have a message.
|
Anonymous |
Apr 27, 2012 |
| Printed |
Page 59
Figure 5-1 |
In Figure 5-1, the hash code of file1 (with "foo" content) and file2 (with "bar" content) might be
257cc5642cb1a054f08cc83f2d943e56fd3ebe99
and
5716ca5987cbf97d6bb54920bea6adde242d87e6,
respectively. This could be verified from the text in the bottom of Page110. When running git diff HEAD, the output looks like
"diff --git a/file1 b/file1
index 257cc56..d90bda0 100644".
Obviously, the hash code in the store is "257cc", instead of "a23bf" shown in the figure.
Meanwhile, when I run command
echo "foo" > file1
git hash-object file1
the output is again 257cc5642cb1a054f08cc83f2d943e56fd3ebe99.
Therefore, I guess the hash codes in Figure 5-1, 5-2, 5-3, and 5-4 are incorrect, so are the codes in Figure 8-1.
|
Anonymous |
Dec 13, 2012 |
| Printed |
Page 59
last bullet point for ignored files' precedence |
The last bullet point for ignored files precedence is:
* Patterns from the file specified by the configuration variable core.excludefile
Should be:
* Patterns from the file specified by the configuration variable core.excludesfile
|
foolhunger |
Feb 04, 2014 |
| PDF |
Page 62
Figure 5-4 |
Commit tree object created in the step "3a. Convert index into tree object" should point to modified file1 blob bd71363. Currently commit tree object points incorrectly to blob a23bf.
|
Anonymous |
Jul 02, 2012 |
| Printed |
Page 80
Middle |
The text uses parentheses to denote node sets (A, B, ...), which is more commonly used for tuples. The usual mathematical notation for sets are curly braces {A, B, ...}.
|
Felix Gatzemeier |
Jun 02, 2012 |
| Printed |
Page 83
1st paragraph underneath examples |
The paragraph states that "In a perfect bisection run, it takes log_2 of the original number of revision steps to narrow down to just one commit". The term "perfect" allows for some interpretation, but it sounds like best-case to me. A bisecting search in a sorted list, however, has a *worst-case* complexity of log_2. But that is also not correct here, since we cannot tell from just one ommit whether it is the wanted one. So, we always have to process log_2 bisections (give or take one) to get to a 2-commit-interval.
I may also be off the mark, because the commits are not fully ordered.
If "perfect" means something else here, that may want clarification.
Note from the Author or Editor:
Sure. And whole bunch of other factors too, including branches, possible "invalid" commits that get side-stepped but the user, merges commits, fence-posts, squirrels and off-by-ones. It is a sorted list, but it is possibly a topological sort with a bunch of side branches too. And yeah, you really would like to narrow it down to side-by-side commits, so you'll work through all of that *basically* log_2 range. It's a mixed up muddled up shook up world.
The thing to pick on in this sentence is the vagaries of "the original number of revisions". Urk. I don't even explain that that is over the range between "good" and 'bad.
So, yeah, this could be improved some, I suppose. :-) |
Felix Gatzemeier |
Jun 02, 2012 |
| PDF |
Page 94
Line 11 from bottom |
The command:
$ git show-branch bug/*
should have its last argument enclosed in single quotes in order to avoid shell globbing:
$ git show-branch 'bug/*'
|
Mirko Banchi |
Oct 11, 2016 |
| Printed |
Page 97
3rd paragraph |
Text reads "Seeing the error message saying NewStuff is not uptodate might suggest that you update the file within the index and then proceed with the checkout." instead of index it should be working directory
|
Anonymous |
Sep 25, 2012 |
| Printed |
Page 99
Example of section "Creating an Checking Out a New Branch" |
In the second paragraph you can read:
"In other words, you are in the master branch, editing files, and..."
So, as you are editing files, the example should show that edition.
$ git branch
bug/pr-1
bug/pr-2
dev
* master
$ echo "Some bug fix" >> NewStuff
$ cat NetStuff
Something
Some bug fix
On the other hand, as you are editing files, the next command should be
$ git checkout -m -b bug/pr-3
(with '-m' or '--merge' option).
Thanks in advance.
|
Tom?s Abad |
Oct 09, 2012 |
| Printed |
Page 101
Section "Deleting Branches", 4th paragraph. |
The paragraph starts with
"In this git show-branch output, the commit..."
but there is not any output related with 'git show-branch'.
I think the example should be
$ git checkout master
Switched to branch "master"
$ git branch -d bug/pr-3
error: The branch 'bug/pr-3' is not an ancestor of your currrent HEAD.
If you are sure you want to delete it, run 'git branch -D bug/pr-3'.
$ git show-branch
[...]
Thanks in advance.
|
Tom?s Abad |
Oct 09, 2012 |
| PDF |
Page 109
just after 4th paragraph |
"--M" (two dashes) should be "-M" (one dash) in the two places it is mentioned in this paragraph.
|
tcordes |
Mar 03, 2017 |
| Printed |
Page 167
Figure 10-15 |
In Figure 10-15, I believe the commits should be P' and Q' instead of P and Q.
They are based on a different commit (E instead of Y) so unless I really messed something... this must be a typo.
It would be really, really nice to have less mistakes in the book. Git requires attention to detail. Also, please consider condensing the book towards its later chapters.
|
bmdesign |
Jan 30, 2012 |
| Printed |
Page 187
fourth comand promp |
$ git remote add origin /tmp/Depot/public_html
should be
$ git remote add origin /tmp/Depot/public_html.git
|
Anonymous |
Sep 11, 2012 |
| PDF |
Page 190
3rd last command line example stanza on page, 3rd line (output) |
Almost certainly "/tmp/public_html/.git/" should read "/tmp/bob/public_html/.git/". (The newer versions of git, of course, produce a different message (sans path), but to be consistent with the version used for this edition of the book the above should be changed.)
|
tcordes |
Mar 08, 2017 |
| PDF |
Page 194
5th paragraph (excluding code blocks) |
"use the URL /tmp/Depot/public_html as the source"
should be:
"use the URL /tmp/Depot/public_html.git as the source"
Also, further down the page in the last command example "From /tmp/Depot/public_html" possibly should have a .git suffix as well.
|
tcordes |
Mar 08, 2017 |
| PDF |
Page 217
3rd paragraph, 3rd sentence |
"the corp of developers"
should be:
"the corps of developers"
|
tcordes |
Mar 23, 2017 |
| PDF |
Page 294
Missing topic |
Overall, Chapter 16 does a great job of describing the "gatekeeper" workflow for mirroring subversion repositories. For example, great detail is provided for how to take git user's change sets, get them into the gatekeeper repository and such.
But it wasn't clear to me how to manage the other direction --- meaning, how do you make sure your gatekeeper repo always reflects what's in the upstream subversion repo. Ideally, some tips on automating this would be included.
|
Anonymous |
Feb 17, 2012 |