Errata for Pragmatic Version Control Using Git

#36685: No mention seems to be made of the .gitattributes file. We are coming from Subversion and we use RCS $Header$ ids -- pointers on how to get this sort of support from git would help people coming from CVS or Subversion.

--Timothy J. Wood

#36647: "git commit -a" launches a terminal-based editor that I'm not familiar with. More explanation required here for the newbie. Is this a configuration issue?
--Matt

#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

#39566: You describe the process of tagging a release and cleaning up your repository by rebasing master on top of your release branch and deleting the branch. Most of your readers will be working with other developers, pushing to a common repository, not working entirely in their own local repository. As a result, rebasing master on a release branch is not a good idea, as far as I understand anyway. I think this more realistic scenario should be the basis for the example.--Moses Hohman

#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

#40163: Regarding this statement : "Right now your repository looks like Figure 3.1. After rebasing, it looks like Figure 3.2, on the following page."

This make it look as if rebasing removes the RB_1.0 branch. Suggest either including the RB_1.0 branch in the second diagram, or changing the text to "Right now
your repository looks like Figure 3.1. After rebasing, the master branch looks like Figure 3.2, on the following page."
--Mike Depot

#37275: Chapter 3 leaves the work area (/work/mysite) in branch RB_1.0.1. (p. 46)
Chapter 4 assumes the work area has master checked out, that may be confusing

#43349: When git branch -d or git branch -D deletes a branch, is the branch gone forever? Later in the book, I see branches retrieved using tags that were set inside the branch; does this matter if -d vs -D was used? What does it really mean to 'delete' a branch if you can get it back? What are the consequences of deleting branches that others use as 'remote' branches?--Seth Arnold

#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

#36481: It would be helpful to show the various URL formats that work, such as:
"git clone sjf@hercules:git-test/depot depot-frm-svr",
"git clone sjf@hercules:~/git-test/depot test-again",
"git clone ssh://sjf@hercules/home/sjf/git-test/depot depot-frm-svr2",
"git clone ssh://sjf@hercules/~/git-test/depot depot-frm-svr3"

--Steven Finnegan

#43351: Even after the discussion of remote repository handling, I'm left confused. I've seen discussion of remote/ branches in the local repository, and I haven't got a clue how one would use the branches in daily use.

Furthermore, I'm not entirely sure what would happen if two developers each start their own git repos by unpacking the same tarball... or perhaps unpacking the same tarball into different directories in their repos. How does sharing changes work between them after they've been added as new remote repos? (Or, must repositories share a common ancestor in order to be shared via git remote?)--Seth Arnold

#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

#37327: At the end of section 8.2, you allude to the realization that you should have branched earlier, and suggest creating a branch from an earlier commit.

This seems like a good place for an example of creating a backdated branch and moving the inappropriate commits out of the current branch.

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

#47811: I have found that the post-update hook is not (necessarily) executable by default on a few installations both using the python install method and apt-get.

#43356: You're using sudo to run the git daemon as user git to serve up a repository owned by user git. What prevents the daemon from modifying the repository? Or, what keeps it 'read-only'? Is it just that the git daemon tries hard to not write, and we're all hoping that there are no bugs that allow it to write? Or should the git daemon be running as some other user, one with only read access to the repository?--Seth Arnold

#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

#43358: Please also include 'recipes' for reverting a previous commit in history, reverting a range of previous commits in history, and reverting (one,many) previous commits for a specific file.--Seth Arnold