Errata for Pragmatic Version Control Using Git

#43346: Cygwin is not a Linux emulator for Windows. Cygwin is a collection of tools compiled on Windows using a shim library that provides POSIX functionality missing in Windows. Perhaps best to say something like, "Cygwin makes it possible to recompile tools intended for distribution to Unix systems so the tools can run under Windows".--Seth Arnold

#43347: Giving "chances of collision" for SHA-1 without further discussion is misleading in several dimensions.

SHA-1 encodes any data up to 2^64 - 1 bits in length into a hash only 160 bits long. So, clearly there are trillions upon trillions of collisions. (Roughly 2^(2^64) possible inputs; 2^160 possible outputs. Pigeon Hole Principle means there's going to be overlap in the outputs.)

Actually _finding_ collisions is another matter. If SHA-1 were perfect, reaching a 50% chance that there is a collision in a 'random' set of inputs to SHA-1 should require a set roughly 2^80 in size, by the 'birthday paradox'. That's for a 50% chance of any collision, not a specific collision, which would of course be lower.

But SHA-1 isn't perfect; I found an article in Eurocrypt 2009 mentioning 2^52 complexity work for finding collisions. (Which is one reason why SHA-1 is being phased out in favor of SHA-2. 2^52 work is cheaper than brute-force searching DES keys, and much cheaper than the 2^80 work that one would expect from a perfect 160 bit output function.)--Seth Arnold

#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

#44227: This is clearly an error I get the following

$ git commit -a
Aborting commit due to empty commit message.

the book shows the output as

prompt> git commit -a
... editor launch, create log message, save, and exit ...
Created commit e993d25: add in a bio link
1 files changed, 3 insertions(+), 0 deletions(-)

which shows a commit message of "add in a bio link" that is missing from the command "git commit -a"
--Ron Bingham

#46043: The text says the "<meta> description" change that was added to the RB 1.0 branch needs to be added to the master branch too (by using git rebase), but then the git rebase command shows the "bio link" change added instead. The order of commits in figure 3.2 also implies the "bio link" has just been added (to some unspecified branch). This makes it confusing about what git rebase actually does... does it merge changes from the branch listed on the command line into the currently checked out branch, or does it merge changes from the currently checked out branch into the branch listed on the command line? The text says the git rebase command takes as a parameter the name of the branch you want to rebase against, but the phrase "rebase against" is undefined.
Figures 3.1 and 3.2 would be clearer if the master and rb 1.0 branches were labeled.
Figure 3.2 is ambiguous; either the "<meta> description" change has been inserted into some branch (master?) ahead of the "bio link" change, or the "bio link" change has been appended to some branch (rb 1.0?). If the change was inserted instead of appended, it would help to explain why git rebase inserted it instead of appending it.
Also, it would help on page 43 to say whether or not the git branch command causes the new branch it creates to become the currently checked out branch.--Steve Eppley

#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

#45441: On page 98, the sidebar "Adding a Remote Repository Later" is incomplete... well, ok, wrong. At least, it doesn't work for me.

Here is a (genericized) sequence that DOES work for me:

ssh git@example.com
mkdir pocus.git
cd pocus.git
git init --bare
exit

# Now, assuming I'm already in my existing local repository:
git remote add origin git@example.com:pocus.git
git push origin master--Charles Roth

#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ý

#43357: "The final & suffix detaches it from the current session, and the nohup prefix detaches it from the current user."

& creates a new process group and places the process group in the background. (setpgid(2) in the child, ioctl(tty,TIOCSPGRP,$$) in the parent.) The process is still in the current session.

nohup sets the signal disposition of the child process to ignore SIGHUP. The terminal will send SIGHUP to its controlling process, usually the shell, and the shell will send SIGHUP to all jobs before exiting. nohup instructs the child to ignore SIGHUP. (This is different from e.g. bash's disown command, which asks bash to not send the SIGHUP signal to that specific job.) The default disposition of SIGHUP is to terminate the process, so ignoring SIGHUP allows the process to continue running. But the process still retains all the credentials of the user running the process.

In neither case are child processes "detached from the current session" (that would require calling setsid(1), which calls setsid(2)) or the child process "detached from the user" (which requires CAP_SETGID and CAP_SETUID, and then calling setuid(2), setguid(2), setgroups(2), setreuid(2), setresuid(2), or setfsuid(2), and perhaps other syscalls.)--Seth Arnold

#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