Errata for Pragmatic Version Control Using Git

#39672: In discussing the probability of getting duplicate SHA1 hashes, the exponent should not be 63 but 160 (the hash is made up of 40 hex digits, each equivalent to 4 bits). Thus the probability diminishes from the quoted 1 in 9,223,372,036,854,775,808 to an absurdly small 1 in 1,461,501,637,330,902,918,203,684,832,716,283,019,655,932,542,976. A small detail, but ugly to the eye when reading... --Àlvar Vinacua

#38818: At the end of the page, when you talk about the caret (^). Although what it says is correct, it's not complete.

The most important use of the caret operator is in the form ^# (where # is a number) in order to identify a parent when there's more than one.

For example when you've finnished merging 2 branches, you can checkout HEAD^ and going to the last commit in one branch (usually the current), and checking out HEAD^2 goes to the last commit in the other branch.

The examples in the start of page 85 are nonsense... Why anyone needs to do git log HEAD~1^^ ? I think it's not much pragmatic when you can just do git log HEAD~3

Anyway, combining them is useful in a situation as the next one: Imagine you have the next history:

-- X -- X -- X -- A -- X -- X -- HEAD
-- X -- X -- X -- B --´

If you want to checkout the commit "A" you have to do: git checkout HEAD~2^
In the other hand, if you want to checkout the commit "B" you have to do: git checkout HEAD~2^2

I think it's important to point that.--Albert Oliver

#42112: 'git reset' with neither --soft or --hard leaves the changes in the working tree. I think the fourth paragraph would be clearer if it read something like "git reset updates the repository and _leaves_ the changes in your working tree..."

Also, 'git reset HEAD' seems to be a noop for me. 'git reset HEAD^' seems to reset the previous commit. I think the sentence 'HEAD^ would reset two commits...' (in the third paragraph) isn't correct.
--Kevin McCarthy

#38706: At the very bottom of page 103, the example at the very bottom should be:
git checkout -b another-from-1.0 1.0
The trailing tag name has been omitted.

The example is supposed to show how to create a new branch from a tag, but instead it shows how to create a new branch from the current commit and is identical to the command right above it, and the "another way" ends up being identical to the first.--Anthony Foglia

#39914: The command "git tag contacts/1.1 contacts" fails with the error "fatal: Failed to resolve 'contacts' as a valid ref.' since the contacts branch is not being tracked locally. There appear to be two solutions:

1) Use the command "git tag contacts/1.1 origin/contacts" to create the tag contacts/1.1 from the remote branch origin/contacts, or
2) First locally track the remote contacts branch using the command "git checkout --track -b contacts origin/contacts" and then issue the command "git tag contacts/1.1 contacts" to create a tag from the latest commit in the local contacts branch.

I'm not sure of the differences or advantages/disadvantages between the two solutions (if any).

Note, I cloned the repository with the following command: git clone git://github.com/tswicegood/mysite-chp7.git ~/development/git/mysite-chp7.github.tswicegood

--Matthew Rankin

#39305: As mentioned by Steven near the bottom of "Macports install fails", sometimes git-svn --version returns errors even if installed if you do it outside of a repository.--Andrew Grimm

#39280: Not really the linux admin, but as far as I could infer from the manpages, the adduser command on page 150 is not right.

In the text, there is stated, that user and group will be created, which was not the case. When I used --group option, only group was created.

Adding group `git' (1002)...
Done.

Obvoiusly I could not than proceed with other commands, because the user didn't exist.Omitting the --group option did the trick for me

Adding user `git'...
Adding new group `git' (1002).
Adding new user `git' (1002) with group `git'.
Creating home directory `/srv/example.com/git'.
Copying files from `/etc/skel'
Changing the user information for git

HTH--Tomáš Svárovský

#39361: Under "Move or Rename a Branch", the commands for renaming a branch use "git checkout" with a "-m" or "-M" flag. They should use "git branch" with the same flags.

git checkout does take a "-m" flag, but it invokes a merge.--Tim Holahan