Errata

This seems a bit confusing:

"Consider the most recent commit (or its associated tree object). Because it contains, as part of its content, the hash of its parent commits and of its tree and that in turn contains the hash of all of its subtrees and blobs recursively through the whole data structure, it follows by induction that the hash of the original commit uniquely identifies the state of the whole data structure rooted at that commit."

What exactly does "the original commit" refer to? For this to make sense to my mind it must refer to "the most recent commit" you begin by asking the reader to consider. But the containing sentence has just constructed an argument based on a sequence of temporally prior 'ancestor' (you say 'parent' explicitly) commits. In this context, I would tend to think of "original commit" as the earliest or "base" commit in the induction. Perhaps naming the original commit would help:

'Consider the most recent commit (C), or, equivalently, its associated tree object.'

and

'...it follows by induction that the hash of the original commit (C) uniquely identifies...'

Or is my understanding mistaken?

Thanks.

On page 48, a "tracked" file is defined as one already in the repository or currently staged. On page 54, it says that "git rm" removes a file from both the repository and working directory. Then, two paragraphs later, it says that the command does not remove a file from the repository. This sounds like a contradiction.

The trap note on page 55 says that the "rm" command makes a file untracked. But if it does not completely remove the file from the repository, then according to the definition of a tracked file, the file should still be tracked.

I have the suspicion that the index actually contains an entry for every file in the repository, not just the staged ones. It would be helpful to clarify this one way or the other, because having a clear mental model of the index is important.

~~ Paul

The two code examples on that page seem unconnected. This section seems to be talking about officially removing files with "git rm", which is fine. And if one officially removes a file called "data", then the first example, trying to add it back with

$ git add data

will, of course, fail, since the file will no longer exist in your working directory.

But the second example to allegedly fix this:

$ git checkout HEAD -- data

will also surely fail, since that file is no longer part of HEAD. Perhaps you meant "HEAD^"? In any event, that's a very confusing example.

The third paragraph on page 65 says that Git compares the index to the current commit and creates new blobs for files that have changed. I don't believe this is true. Blobs are created when you perform add commands and the like, not when you commit. All commit does is create a tree object from the index and a corresponding commit object. (commit -a does create blobs, but that is irrelevant.)

Paragraph 6, in parallel, says that a commit is the only way to introduce changes to the repository. But add, rm, etc. also make changes to the repository. A commit is the only way to permanently commit the changes to the current branch.

~~ Paul

The git command "rev-parse" is used to display a sha. I believe that this command had not been used in the book prior to this. When I looked up the command, the description does not suggest to me that "rev-parse" would be the logical command for this purpose.

For this reason, the command should have been explained at that point. Also, an inexperienced reader, like myself, would more likely have used the log command to get this information so when the author uses "rev-parse" instead, the reason should be stated.

This same command is used for the same purpose at the top of page 158 as well.

The authors write "With an amendment, anyone can see that the original commit has been modified and that it replaces the existing commit." This statement is apparently contradicted by Figures 10-10 and 10-11 on page 167. In those Figures, commit "C" has been amended to be commit "C'" and "C" is not shown in Figure 10-11.

That said, the reader knows of the prior existence of commit "C" because it was created on page 165. However, I don't think that's what the authors meant, or is it?

To summarize, if commit "C" no longer exists in the repository, the authors' statement is wrong. If it does remain, it would seem appropriate to demonstrate how the presence of commit "C" would be revealed.

In the middle of (printed) page 188 in the pdf format, the following paragraph starts out fine, but I'm confused about the second sentence which contains "...tracking branchtracking branches...".

The book has the following on page 206 2nd Ed near the top:

--START--
Because you used the --bare option during this clone operation, Git did not introduce the normal, default origin remote.
Here's the configuration int he new, bare repository:
# In /tmp/Depot/public_html.git
$cat config
[core]
repositoryformatversion = 0
filemode = true
bare = true
--END--

but when I ran the command on my git (version 1.7.10.4) I *do* get the origin remote and my config file looks like the following:

[core]
repositoryformatversion = 0
filemode = true
bare = true
[remote "origin"]
url = /root/public_html


Why do I have [remote "origin"] stanza in my result? Did something change in the git version used in the book and my version of 1.7.10.4? What changed and why?

This comment is a suggested improvement.

On pages 204-208, the authors describe a process for setting up a bare repository based on a pre-existing local repository. On page 209, the command "git push origin master" is used instead of "git push" to send local changes to the remote. As I understand it, the first git command is necessary because the local config file does not have a "branch master" section.

Perhaps there's a good reason for using first command instead of the second but none is given. The reason I bring this up is because on page 206, 3'rd paragraph in subsection "make your own remote", it says "in a sense, you must manually convert your initial repository into a derived clone". If this is one of the aims of the authors, then achieving it would would allow the use of the simpler "git push" and the repository behavior would be the same as if it had been cloned.

When I followed the steps in the text, git would not allow the simpler "git push" command. Instead, it recommends "git push --set-upstream origin master" which apparently adds the "branch master" section to the config file which then allows use of the shorter command thereafter.

In the section 'Getting Repository Updates' there is a line that states "Let's assume you did this after getting Bob's latest changes" (Bob changed the fuzzy.txt file). I've been following the examples but there was no command example given in the book on how to properly pull Bob's change to fuzzy.txt into the 'public_html' repo. I tried the command 'git pull', but this did not bring don the change to fuzzy.txt to my working dir and I got the following from this command:

--START--
remote: Counting objects: 5, done.
remote: Compressing objects: 100% (3/3), done.
remote: Total 3 (delta 1), reused 0 (delta 0)
Unpacking objects: 100% (3/3), done.
From /tmp/Depot/public_html
ba0b9d9..d90a85c master -> origin/master
There is no tracking information for the current branch.
Please specify which branch you want to merge with.
See git-pull(1) for details

git pull <remote> <branch>

If you wish to set tracking information for this branch you can do so with:

git branch --set-upstream master origin/<branch>
--END--

Why did a simple 'git pull' command fails and what does the above mean?

I did the command 'git pull origin master' and this seemed to do it but I do not know if this was the proper way. Hoping to have clear examples in Ch 12 as this is a critical chapter that I'd like to fully understand.

In figure 12-7, the commit graph for "Origin" appears to show a branch being created and then merged into "master" even though there is only one branch on "Origin". There is no such confusion in the "Yours" repository because there are two branches: master and origin/master.

I see this as confusing because in most/all similar diagrams prior to this one, multiple "paths" corresponded to different branches. I'm not sure if the example should be changed or if it is an opportunity to explain what I think is a not uncommon occurrence.