Historical errata for Pragmatic Version Control Using Git

I think where you talk about metrocracy, you mean meritocracy.
(Final sentence on the page)

“provide you wiht a good jumping off point [sic]” should be “with”, and “Be sure to check the the Joe Asks… [sic]” should only have one “the”

“For developer’s who have never used version control”, “developer’s” should not have an apostrophe.

“Ask your self” shouldn’t have a space between “your” and “self”

Final bullet point before section 4.2
“Fiually, you synchronize.”

Thinking that should say, “Finally”

Figure 11.3
git svn rebaes

“but you can also any other repository than you have permission to write to.” I’m confused what I can do. Push to any other repository?

“You also have to pull change to get the latest updates (…)” I think maybe “pull change” should be “pull changes”

“Each branch keeps track of the changes made to it’s content (…)” should be “its,” “it’s” is the contraction, “its” is the possessive pronoun.

“share it when its something worth sharing” should be “it’s”, for “it is”

the first line (continued from page 21)

“These are called squashed merges and something that are so useful (…)” I think is missing an “are” before the word “something”. For example “These are called squashed merges and are something that are so useful (…)”

“Knowing how these work is an important part of master Git.” I could very well be wrong, but “an important part of mastering Git” may make more sense?

“The both make changes to the same file, bu in different areas of it.”

“The” should be “They”

“Speaking of the command prompt, don’t worry if you’re not used to working outside of a GUI (graphical user inter face) Git only requires a handful of commands (…)” It looks like the first sentence is missing a period (after the end-parenthesis)

“Most of these you’re never need to tweak, but there is one extra change that is useful if you like color -coded output.” “you’re never need to tweak” might need to be “you’ll never need to tweak”

“It’s an algorithm developed by the United States’ NSA (National Security Agency) to to produce shorter strings (…)” repetition of the word “to”

“In American English, that’s nine quintillion, two hundred twenty three quadrillion, three hundred seventy two trillion, thirty six billion, eight hundred fifty four billion, seven hundred seventy five thousand, eight hundred eight.”

at “eight hundred fifty four billion,” it should say “million.”

“In the git status after you add the modified numbers.txt the header the is now Changes to be committed (…)” the word “the” after the word “header” shouldn’t be there.

“If you want to stage files that are not being tracked yet, you can use the forth option.” I think it should say “fourth option”

“Once you make your choice, presented with a diff of the changed files and given the option to add the changes or not.” This should probably be “Once you make your choice, you are presented with a diff (…)”

“Now you have the option of adding this hunk or deny it.” To me, it would sound slightly better if “deny” was replaced with “denying”:

“Now you have the option of adding this hunk or denying it.”

“For example, you can run the following to launch patch mode directly on the days.txt” I think it would have better sentence flow if the last “the” was removed:

“”For example, you can run the following to launch patch mode directly on days.txt"

“If you create a quick branch to do some work in, since Git isn’t tracking your directory, it leaves sandbox in tact.” “intact” should be one word

“You can use the git status to see all of the changes that have occurred in your repository.” The phrase “You can use the git status to see (…)” would have better sentence flow if “the” was removed, or if the word “command” (or something like it) was appended to the end of “status”:

“You can use the git status command to see all of the changes that have occurred in your repository.”

“It’s easy to remember that you added a new file or made a change to one file when its fresh in your mind.” the “its” should be “it’s”, for “it is”

“You need to find out what has changed in your working tree
and how they’ve changed.” “what has changed” is singular, and “they’ve” is plural. Suggestions:

“You need to find out what items have changed in your working tree, and how they’ve changed.”
“You need to find out what has changed in your working tree, and how it’s changed.”

“git diff only shows changes in your working tree that you have not staged of committed yet.” I think “of” should be “or”

“I know the gist of American history, but I can’t tell you specific dates unless they ended up spawning an national holiday.” It should be “a national holiday.”

“You should always specify your the old revision first so Git can understand what you want.” I think the “your” should be removed:

“You should always specify the old revision first, so Git can understand what you want.”

“For example, the following loads the plame for lines 3 and 4 of numbers text.” “plame” should be “blame”

“Making a change to your copy effects just your repository” should read “Making a change to your copy affects just your repository”

“Git allow you to move files […]” should read “Git allows you to move files […]”

“Git interprets that range to mean every commit after f320 to 5ef8.”
Since “after” is printed in italics it merges with the following “f320”. Some extra space would be advisable to compensate for the spill-over.

“If you’ve commits your changes already, […]” should probably read “If you’ve commited your changes already, […]”

Section 2.1 second paragraph, first sentence
“..were only accessible if you had access to machine..” should read “..were only accessible if you had access to the machine”

Section 2.1, paragraph 4

You talk about needing to maintain a link to “your” repository. Perhaps you should refer to this as the central repository.

First paragraph.

“..just shared their changes..” maybe should be “..just shares their changes..”

Last paragraph.

“All they need to have access to is their computer and they..” You could change this to “They only need to have access to their computer..”

Last sentence:

“..working tree is the files..” I think that since files are plural then maybe “..working tree are the files..”

“art of merging”

I don’t think you’ve gone into enough detail to say that we’ve learned about merging as an art.

You’ve mentioned plumbing, but I think you should also mention porcelain and why the functions are so named.

.gitignore files.

I think you could expand on where the .gitignore file goes. i.e, you can put it in any directory and it will apply to that and all sub directories. so you can have a general .gitignore file in the top level directory that will apply to all the files, but adding .gitignore files in sub directories will override these settings. Useful for when you don’t always want to ignore certain files in these subdirectories.

para 2 “comform” -> “conform”

cygwin is not a Linux emulator, but a POSIX API compatibility layer allowing you to compile and later run any unix application under windows - provided that you are careful when writing your code.

So in the first sentence under “cygwin”, I’d change “a Linux emulator” to “a POSIX API compatibility layer - like WINE under Linux”

it’s nit-picking, I know :-)

in the cygwin section, 3rd paragraph, you link to the section 11.1 called “Communicating with SVN”. Actually though, the section is called “Migrating to Git” - other links - like the one on page 26 - are correct.

I may be wrong, but SHA-1 is IMHO a 160 bit hash which IMHO should mean that the chance of a collision isn’t just 1:2^63, but 1:2^160 which makes that even more unlikely.

“Once you push those changes, though, you loose some of that flexibility.”

loose -> lose

“How to share your changes by pushing a remote repository” -> “How to share your changes by pushing to a remote repository”

I would like to see a bit more about pushing and pulling and tracking branches with remote repositories.

I would suggest to include a reference to code.google.com/p/git-osx-installer/ .
The website distributes an easy to use Mac OSX GIT package to install GIT without compiling the source by hand or via port.

I usually skip port usage when I have a valid alternative. It is prone to duplicate already installed dependencies.

“…how does these alternate histories” should be “…how do these alternate histories” because the subject is plural.

Why is “histories” quoted in the fifth paragraph and not in the third paragraph? This should be consistent.

Last paragraph in 2.4:
“You can push and pull changes multiple repositories.” Should this be “from multiple repositories.”?

It seems that “git status” is no longer working in 1.5.3. You can either use “git-status” or “git runstatus”.

“Originally, these repositories were only accessible if you had access to machine they were stored on.”

should be

“Originally, these repositories were only accessible if you had access to THE machine they were stored on.”

Missing word in the second paragraph, text in brackets are missing: “I encourage you to follow along with examples [in] this chapter”.

When mentioning the over 130 settings, the addition of a footnote to git-config man page listing the configuration settings would be useful for those looking for additional tweaks.

In the second paragraph of section 3.5, the comma should be removed after “six” since there are only two lines added.

In the “Joe Asks…” bubble, the second to last paragraph has a missing subject in one of the sentences. I’ve added the new text for the sentence in the brackets: “Another thing to keep in mind when writing your commit message is who is going to read [it].”

“one commit into multiple multiple commits?”

Repeated word “multiple”

In the 2nd to last paragraph, the word with is spelled as wiht

Here, among other places, the author refers to “the git-something”, which sounds awkward.

“One of the benefits of Git over other popular DVCS however is its ability to continue to not only pull but also push changes back to Subversion.”

Would probably read better with commas around the “however”, though it might be a little too wordy still.

The following is unclear:

“but you can also any other repository that you have
per mission to write to”

Did you mean:

“but you can also push to any other repository…”

“Originally, these repositories were only accessible if you had access to machine they were stored on.”

Should be:

“Originally, these repositories were only accessible if you had access to the machine they were stored on.”

“Git also does merges between remote repositories and its branches and your local branches.”

should (probably) be

“Git also does merges between remote repository and its branches and your local branches.”

or

“Git also does merges between remote repositories and their branches and your local branches.”

I would also suggest to avoid “.. and .. and ..” usage because it makes more difficult to understand how fragments should be joined together (ex. (A AND B) AND C or C AND (A AND B) or A AND C AND B?)

“Thankfully, you don’t have to. Git handles it through “merge tracking”. […] This is a feature not found in many traditional VCS such as Subversion or CVS."

This is no longer true.
As of SVN 1.5, Subversion provides a “merge tracking” feature.
See subversion.tigris.org/svn_1.5_releasenotes.html for more details about how SVN 1.5 revamped merging support.

Second paragraph after the box says “Now, you can just us erin…”, should be “Now, you can just use erin…”.

The first example in section 3.5 displays an tag that is probably part of the book editing format and not of the example itself.

prompt> git status

1. On branch master
2. Changed but not updated:

Before diving into the interactive mode, I would suggest to demonstrate the most simple way to add a file:

git add

Reading the section 5.2 my feedback is that it is simply “too much verbose” if want to you assume (ad you did in chapter 4) that Part II should be used as a cookbook.

I would suggest to first display the most immediate way then to go deep into details talking about interactive mode.

I probably have to admit that I would never understood the section 5.2 without a knowledge of what was the section about. It’s hard to keep reader attention if you explain after 3 pages that the goal is to prepare a commit (page 46, Now all of your files or changes are staged and ready to commit.).

In the second paragraph, “…how not having a built in copy command affects you…” should be changed to “…how not having a built-in copy command affects you…”

I think the phrase “old revision first” near the end of the page should be “oldest revision first”. This phrase is used in the previous sentence and makes more sense.

“Lines 2 and 3 both begin with a caret” should be changed to “Lines 2 and 4 both begin with a caret”. The line number is incorrect in the blame listing.

In the footnote, “Masting” should be changed to “Mastering”.

Paragraph 4 Sentence 2;
The both make changes to the same file, but in different areas of it.
should read;
They both make changes to the same file, but in different areas of it.

The chapter title should be “Using Git Every Day”, or “Everyday Git”.

“Everyday” is an adjective meaning “ordinary”. “Every day” means “each day”.

“Most projects have some sort of build script.” Makefiles and Ant build.xml files aren’t scripts. I know what you’re trying to say here, but script isn’t the right word. Build control files, maybe?

“Up next,we’ll talk about Git handles merging the branches
together.” is missing the word “how”

“checkout” is a noun. “check out” is the verb.

The use of “library” here is confusing. Even thought I know you’re talking about a public library where books are checked out, I still think of “a collection of reusable code” whenever I read the word “library” in your pages.

“Speaking of the command prompt, don’t worry if you’re not used to working outside of a GUI (graphical user interface)”

That sentence is missing a period.

May want to explain why using an SHA-1 hash means that the commit name will be different. What’s it a hash of? Is there date & time in it somehow?

To a Subversion guy like me, it is baffling that you have to add a file to commit it, even though it’s already been added. You call it “staging” the file, but the command isn’t “git stage”. I’m hoping that somewhere soon you’ll explain.

I suspect that many reading this may be in my boat.

A key aspect to any version control system is its history.

should probably be

A key aspect of any version control system is its history.

“Many a book”

should probably be

“Many books” or “More than a book”

The last example on the page contains some external metadata.
“#<label id=”code.orig.2"

“namees” should be “names”.

With the new version 1.5.6 of Git on MSys, there is the installation choice of using plink instead of openssh. I found that quite handy, since I was already using PUTTY and plink with svn, and had my keys already set up. In any case, you will now need to at least reference this new installation option. Thanks!

In my version of git (1.5.3.7), git revert HEAD -n does not work, but git revert -n HEAD does work.

You could also add the example file and explain that you need to create this file and add to the repository.

in sidebar: “in tact” => “intact”

“Whether you used svn git clone -r … to make” should be “Whether you used git svn clone -r … to make”

“The warning is just telling you is that it couldn’t find” should be “The warning is just telling you that it couldn’t find”

“tasks you’ll need to per for m while use Git. Consider” should be “tasks you’ll need to per for m while using Git. Consider”

“I hope that’s come through in the book.” should be “I hope that comes through in the book.”

“by adding a :# between the domain name” (A) that should be a colon only, no pound sign/octothorpe. (B) between the domain name and what? Should be “between the domain name and the following slash”.

“It will get you there, but you never really get to use the care
to its potential in the 8 AM rush hour traffic.”
should read
“It will get you there, but you never really get to use the car
to its potential in the 8 AM rush hour traffic.”

Continuation error. Created branch ‘test’ and then checkout branch ‘new’. test or new?

The shorter remote url shows:
[url “git://example.com//var/repositories/eng/sateam/repos”]
insteadOf = sateam:

I think it should read

[url “git://example.com/var/repositories/eng/sateam/repos”]
insteadOf = sateam:

With the extra backslash removed…

In “How you create and use your branches is depends a lot on the project”, should not have an “is”. It should be: “How you create and use your branches depends a lot on the project”

In “You can create a branch call test like this.” “call” should be “called”

In “Notice that the master branch as an asterisk by its name.”, instead of “as”, it should be “has”.

The example uses “git branch test” but then uses “git checkout new” a few paragraphs down rather than “git checkout test”

“git is a fully-distributed, though” - Probably shouldn’t say “a”.

“This is a feature not found in many traditional VCS such as CVS and until recently Subversion”

Sounds a little awkward. Perhaps offset the ‘until recently’ with commas.

Missing from the daily activities: a) how to package and deploy. b) how to cleanup the local .git and the remote .git.

Last sentence: you need to define “metrocracy”. I am unable to find a definition of this anywhere. Do you mean “meritocracy”?

“changes we make the projects” should be “changes we make to the projects”

“A couple of common ones are Makefile or an Ant build.xml files.” should be “A couple of common ones are Makefiles or Ant build.xml files.” (or maybe “A couple of common ones
are a Makefile or an Ant build.xml file.”, but the sentence needs number agreement).

“so your can compile” should be “so you can compile”

>git checkout new
Should it be >git checkout test?

End of 3rd paragraph: “how-to” looks wrong with the hyphen.

3rd paragraph: change “stopping you giving it another name” to “stopping you from giving it another name”

4th paragraph: “You” and “shown” don’t agree. Maybe “You” and “showed” or “You’ve” and “shown”

The bit on parameters starting in the 4th paragraph is awkward. The sentence ending that paragraph starts a new thought and should start a new paragraph.

3rd-to-last paragraph: change “using that it can figure out” to “using that git can figure out” (it’s not the commit that figures out all the changes in its branch; it’s git)

2nd-to-last paragraph: change “Here’s a few things” to “Here are a few things”

Last paragraph: change “if its faster” to “if they’re faster”

‘Bug fixes’ bullet paragraph: “Whether its a fix” should be “Whether it’s a fix”

3rd-to-last paragraph of section 6.1, last sentence: “New edits to the chapters happen in their own branch, then I merged those change back in to the beta branch once they are ready.”

Tense agreement and a few typos. How about:

“New edits to the chapters happened in their own branches, and then I merged those changes back into the beta branch once they were ready.”

Last paragraph of section 6.1: “introduces you to how to some basics” should be “introduces you to some basics”

Last sentence of section 6.1: change “let’s start with creating new branches” to “let’s start creating new branches” (we’re not starting out from square one, but we are starting on the new branches bit)

Last paragraph of section 6.2: change “tracked in just that branch” to “tracked in just one branch”

In the “Straight Merging” section, we only see an example of a “fast forward” merge. Is that what we mean by straight merging?

Also, the section starts out saying a straight merge takes two branches and merges them into one. I’m a little iffy on this. On the one hand, it would look that way on a graph. On the other hand, it seems to imply that you are left with just one branch, but unless I’m mistaken, I think you’ve still got two branches.

At the point where the “git branch colors master” example is given and explained, I find myself wondering: If we left off the last parameter (master) would it default to the currently checked-out branch?

Last paragraph: “the second one will call” should be “the second one we’ll call”

3rd paragraph: change “Now you call” to “Now call”

2nd paragraph: “Maybe its a bug” should be “Maybe it’s a bug”

3rd paragraph: “Lets run” should be “Let’s run”

2nd-to-last paragraph on page: “this is example” should be “this example”

2nd-to-last paragraph: “that one change it, but” should be “that one change, but”

2nd-to-last paragraph: change “steps you need to do” to “steps you need to take”

2nd paragraph: “a new commit is created with the contents of the cherry-picked commit”

This wording seems a little confusing. A commit’s “contents” are the straight of the tracked files, right? So don’t we want the changes the commit represents, and not the commit’s contents?

5th paragraph: “it’s output” should be “its output”

5th paragraph: change “see the new file has been added” to “see that the new file has been added”

4th paragraph: “the -a flag to commit the changes” should be “the -a flag to stage the changes” or alternatively, “the -a flag when commiting the changes”

7th paragraph: “the newly added name is now in your file too.” should be “the newly added name is not in your file.”

End of 2nd-to-last paragraph: “conflicts with the names2 branch” should be “conflicting with the names2 branch”

3rd paragraph: First sentence reads, “This invokes Git’s git mergetool.” That’s obvious; this sentence can be taken out.

3rd paragraph: change comma “in your configuration, then it will scan” to a semicolon

2nd-to-last paragraph: “via its opendiff” should be “via opendiff”

Figure 6.1: “status” text toward bottom of screenshot seems cut off for some reason…

First paragraph, first sentence is awkward.

2nd paragraph: “your repositories branches” should (I think) be “your repository’s branches”

3rd command line example: This output text from git:

“is not an ancestor of your current HEAD” makes sense to the reader only if s/he knows something about git’s internals

4th paragraph, last line: “has been into” should be “has been successfully merged into”

2nd paragraph of section 6.6, 2nd sentence: Inconsistent use of “you” and “we”?

3rd-to-last paragraph: change “seem weird for you” to “seem weird to you”

Statement in 3rd-to-last paragraph does seem strange without knowing about git’s internals, whether reader is coming from CVS/Subversion or not. The following paragraphs do help, though.

3rd paragraph: change “you can delete the branch” to “you can again delete the branch” (emphasizing that this is just like what we just did earlier)

Last sentence: “The next chapter Chapter 7” needs a comma. Also, “on the next page” seems unnecessary.

Last sentence in the last paragraph of 6.5

has been into the current branch.

should read:
has been merged into the current branch.

In 3rd pgh, “all of the history of one branches and compresses it”, should be singular “branch”

git svn rebase doesn’t quite work like an svn update. An svn update will what is in the repository with any changes you are currently working on. It seems that using git svn rebase doesn’t do this. It informs you that you need to commit your changes first before doing the rebase: here is the text….

machine seigel$ git svn rebase
ProjectOnRails/app/models/file.rb: needs update
update-index —refresh: command returned error: 1

Thanks again and great book

but you never really get to use the care to its potential in the 8 AM rush hour traffic

“care” should be “car”

Dear Pragmatic Authors

Since i’m not the git expert (that’s why I bought that book sic) it’s possible that this report may not be true. You write in 8.4 that a push happens automatically from the current branch (I assume that’s the one that is checked out currently). Thats not true for me. My git version 1.5.6.4 tries always to sync my master with the origins master. If I want to push another branch, I have to be more explicit, e.g.

[promt (dev)]$ git push origin dev:master

be sure to check the the Joe Asks

“are Makefile or an Ant build.xml files” doesn’t read well; “are Makefiles and Ant build.xml files” maybe?

“The content of the working tree are the files” - “content” should be plural (or “are” should be “is”?).

“You make changes [to] the source code”

“between the two revisions to detected a copy and paste”: s/detected/detect/

“Now it’s let’s explore tags” remove “it’s”

“something that are so useful” I’d just remove the “something that”.

“what DVCS is” - “what a DVCS” or “what DVCS are”, or even “what DVC is”

" whether its our multiplication “: needs to use ”it’s"

This may be an error, or more likely an error in my understanding, but on page 99 when you pull from erin I get an error in a similar scenario.

Using: git pull HEAD

then allows me to pull the latest changes.

Consistency: capitalise `Git’ in non-teletype: “Since everything is considered a branch in git,” —> “Since everything is considered a branch in Git,”

“For developer’s who have never used version”

Has an apostrophe when it shouldn’t. (Found in free sample)

Final sentence on page: “That will make sure you don’t have any unnecessary conflicts when to work through when reverting multiple commits.” Should read “…unnecessary conflicts to work through when reverting multiple commits.” Consider using “ensure” rather than “make sure” too.

Not a definitive erratum, but there seems to be a cognitive leap from general repository structures described on p11 (and illustrated on p12) to suddenly, on p13, the thought “and this is how you’ll structure your GIT repository”. While I accept the destination, I’m not sure you’ve fully connected the dots.

I’m not sure about the sentence “At a higher level, how you organize the files and directories in your
repository makes up your project.” Maybe the thought is incomplete, or maybe ‘makes up’ needs clarification - perhaps ‘defines’. Since I’m not quite sure what it is trying to say, I’m not quite sure how to fix it, either.

Taken literally, the sentence “There’s
an entire chapter, Chapter 6, Understanding and Using Branches, on
page 57, that covers how to use both.” means that the whole chapter is on page 57. Maybe ‘starting on page 57’?

I second the awkwardness at “This is a feature not found in many traditional VCS such as CVS and
until recently Subversion”.
Also, by the time the book is published, June 2008 will be old hat - maybe the comment and footnote should be combined:
“…such as CVS [or RCS or SCCS]. Subversion 1.5.0 and later has merge tracking; earlier versions did not.”

In “Joe and Alice both create clones of the repository
they share and starts making changes”, ‘start’ should be singular.

In “so if you want the latest features—and
possibly bugs—you need to compile Git from source”, you don’t really mean ‘latest bugs’ but ‘latest bug fixes’. This misnomer causes me endless amusement at work - the team forever refers to putting bug 123456 into a particular version of the product when what they actually mean is putting the fix for bug 123456 into the product so that bug 123456 is no longer in it.

In the running text, it is hard to spot that the double-dash in options such as “global, add the —global option” is a double-dash. It isn’t clear (to me) until I get to about 150% magnification.

In “If you
turned colors on, the line with numbers.txt also changed from red to
green”, the example on p34 does not show any red — should it?

How useful are the comments like “See the (as yet) unwritten
apd.recipes.custom-colors” on this page, and the similar but different “An example of this is the excellent program the (as
yet) unwritten apn.3rdparty.trac”. Is there a significance to the apn vs apd notation? Is that explained somewhere? Can unwritten software be excellent? (Granted, it is bug free - but it is also not immediately useful.)

I suggest that “This chapter preps you to work with remote
repositories by covering” is a little too casual; I’d certainly expect to see ‘prepares’ instead of ‘preps’. I’m not wholly convinced about the repeated “Next up”, either. But I’m also an old fuddy-duddy.

Near the end of the page: “In Subversion or CVS when you commit”, I suggest a comma after CVS.

Use “it’s” instead of “its” in “and its something we haven’t talked much about yet”.

Continuity?? End of chapter 5: “Now you know how to create the history of a repository. You’ll learn
how to inspect that history in Chapter 7, Working with Git’s History, on
page 73.” Should you not have something here to lead into the next chapter, such as: “But before we tackle that, we will cover branching in Chapter 6.”?

On the chapter opening page, there doesn’t seem to be an erratum link…

At: “you never really get to use the care
to its potential”, “care” should be “car”.

In “Each tool is a little different, so a step-by-step is impossible,
but the overall is the same”, it feels to me (fuddy-duddy that I am) that there are words omitted after ‘step-by-step’ and ‘overall’. I might let the first one slide - though I’d think about adding ‘recipe’ or ‘guide’ or something after step-by-step; the second should have “effect” or something similar after ‘overall’.

In the example:

in version 1.2 and release version 1.2.1, you can do this:
prompt> git branch RB_1.2.1 1.2
prompt> git checkout RB_1.2.1
Switched to branch “RB_1.2.1”
All you did was use

Should that be 1.2 or RB_1.2?

In “Many a book have been written”, ‘have’ should be ‘has’.

Given: “Many a book have been written on regular expressions, so I won’t cover
them here other than to show you an example” (as amended), which species of regex does git recognize? It would be helpful to know whether they are basic regular expressions (grep), extended regular expressions (egrep), Perl regular expressions, or some other sub-species. (The example indicates that we can rule out shell globbing expressions.)

In “We need to add it to our repository using git add and git commit we talked about in Chapter 5,”, I think you need something like “as” before “we”, or maybe “using the git add and git commit commands we”.

The chapter opens: ‘However,
the “distributed” in distributed version control means you’ll normally
be working with other people on your projects.
This chapter is about how to interact with those remote repositories.’ I don’t think that ‘those remore repositories’ have been properly identified yet - so the first paragraph might be extended to “on your projects, which means you will be working with their remote repositories as well as your own local one”

In “Git allows you to specify the port by adding :# between the
domain name.” Incomplete sentence…between the domain name and what? After the domain name and before the slash?

At “To write to my server, I SSH keys for authenticating”, ‘use’ or some similar word is missing between I and SSH.

In “Pulling the changes fetches them from
the remote repository and merges them into you local branch”, you —> your

Continuity?

Next up, we’ll cover handling those conflicts.

8.4 Pushing Changes

Now that your local repository is up-to-date, you’re ready to start pushing the changes you’ve made back to your upstream repository.

Looks like the ‘Next up’ is pushing changes, not resolving conflicts.

At “to send your commits with
another repository”, replace ‘with’ with ‘to’?

Missing comma before “no” in “If you didn’t clone your repository, but still want to share it no sweat”.

You ask about ‘other VCS’. I use RCS - having migrated from SCCS under protest (but necessary because it wasn’t clear what would happen with Y2K — I have a souped up sccs2rcs conversion that I trust totally on unbranched files and I think is OK on branched files). I have history back to 1987 that I want to preserve if I migrate to GIT (or SVN, or any other newer repository). In case of doubt, I’d go by hacking the CVS description, but it isn’t quite the same.

In fig 11.3 (lower diagram), I assume ‘rebaes’ should be ‘rebase’. I’m not sure about the ‘git svn dcommit’ either (but I haven’t read beyond this page to check).

“Of course, substitute your name for mine.”

I think is the inverse!

“but if you’re development process” —> “but if your development process”

“keeping the to branches in sync will be a snap” —> “keeping the two branches in sync will be a snap”

“Like everything in Git, there yet another way to handle this situation.” —> “Like everything in Git, there is yet another way to handle this situation.”

“These aren’t allowed in in tag and” -> “These aren’t allowed in tag and” ( extra in )

are these supposed to be the same?

C.2 Normal Usage
Add a new file
prompt> git add
prompt> git commit -m “”

Stage and commit file
prompt> git add
prompt> git commit -m “”

The paragraph “The staging area is just that, a place that you can setup commits prior to committing to your repository.” looks misplaced. This is a definition that belongs in the beginning of the section (page 43).

Motivation: the text between pages 43-46 uses the term ‘staged’, and that leaves me wondering “what is that? did I miss it?” and makes me go back through the book lookin for it.

Thanks for the awesome book!

Command “git submodule init hocus” should probably be
“prompt> git submodule init hocus”

Paragraph: “Note that I used a short commit name—just the first four characters of the commit name. Git will try to match any hash you provide it, but it has to be unique. Four or five characters nor mally matches, but 7 or 8 is almost guaranteed to be unique.” should have shown up much earlier. Throughout the book, I was a bit confused as to why the commits are named using full hashes, but the command lines only have the first 7-8 characters of the hash.

I assumed this is what’s happening, but it’d be nice to have this paragraph early on, so I don’t have to do the mental leap. Reasoning: I’m buying the book so I can learn this as quickly as possible :)

Thanks!

“repository when it you try to run git submodule update” should be “repository when you try to run git submodule update”

“For those math majors out there, or just those
who like tr ying to pronounce large numbers, the changes are
2^63 , or 1 in 9,223,372,036,854,775,808.” At “the changes are 2^63” should say “the chances are 2^63 to one”.

“Git also does merges between the branches from the remote repositories
your local branches.” Should there be a word, such as “and”, between “repositories” and “your”?

In Fig 11.3, bottom picture, “git svn rebaes”

Should that be “git svn rebase”?

Last sentence of paragraph continued from page 20.
“it’s something worth sharing or quietly delete it if it didn’t work out.” maybe should read “it’s something worth sharing or quietly deleted if it didn’t work out.”

“Lines 2 and 3 both begin with a caret.” Should read “Lines 2 and 4 both begin with caret.”

Last sentence of 2nd paragraph. “… rewriting your repository’s history without worry of how it effects others” should read “… rewriting your repository’s history without worry of how it affects others”

The “Inspecting Git’s log” section should give an examples for a log command line parameter that show the full log message as well as the affected files.

In my mind this is the most commonly used choice, as it gives an overview who edit what and for which purpose.

“git log —name-status” should be the right choice.

Please additionally consider this for Appendix C.4 “Show history” as well

Please add information about how Git handles storage of symbolic links as those are very important under Unix/Linux.

In chapter 11 “Migrating to Git” I would appreciate to find a section on how to Migrate from IBM’s Rational ClearCase to Git.

Please add a chapter that deals with the disk space usage of Git repositories and how this can be kept to a minimum.

Background:

Consider you are in a large company. As per company rule everyone has a Windows-PC on his desk, but as you are developing for e.g. Solaris Sparc which cannot be done on Intel Hardware, the members of the development team have to do it server based.

If all members are sharing the same department server (or a small number of such servers) with the compilation and build environment, how can Git be used most efficiently? Server disks and appropriate backups for it are very expensive.

The Git features regarding use of hardlinks or cloning or even better using ‘git clone —shared’ with alternates come to mind.

Regarding Chapter 7.6 “Undoing changes”:

While the writeup regarding the dangers of rewriting history is ok I feel that the everyday topics are not yet covered.

I give you some examples:

Most people will never do any partial staging as Git allows. They want just to add new files or modify, rename or remove existing files as a whole in one single step. And they want to undo just that single step (before committing) without throwing away all other staged changes affecting different files (and completely going back to an older repository revision).

Change existing file:
$ edit somefile
$ git add somefile
$ git status

1. On branch master
2. Changes to be committed:
3. (use “git reset HEAD …” to unstage) #
4. modified: somefile #

To undo this you need two steps:

$ git reset HEAD somefile
$ git checkout somefile

The second step only, if you not only want to unstage but want to completely get rid of the changes, of course.

If you remove a file:
$ git rm somefile
$ git status

1. On branch master
2. Changes to be committed:
3. (use “git reset HEAD …” to unstage) #
4. deleted: somefile #

$ git reset HEAD somefile
$ git checkout somefile

Here the second step is required, otherwise the file would not be recovered.

For moving it even gets more complicated:
$ git mv file1 file2
$ git status

1. On branch master
2. Changes to be committed:
3. (use “git reset HEAD …” to unstage) #
4. renamed: file1 -> file2 #

$ git reset file2
$ git reset HEAD file1
$ git checkout file1
$ rm file2

… and I don’t know how complicated it will get to recover a move of an entire directory with multiple files.

I omit the adding of a new file example which also needs to be covered.

Regarding undoing it should be mentioned that “git checkout” undoes local changes that are not yet staged – without a warning!

$ edit somefile
$ git checkout somefile

Oops, all changes lost!

I suggest to add such examples to the book including what happened and why.

Description and command have inconsistent hours (2 and 6):

Show commits from the last 6 hours
prompt> git log —since=“2 hours”

9.3 Rbasing a Branch. Last sentence of first paragraph. With merge tracking, such as Git provides, the effort required to make keep everything in sync is greatly reduced …’. “make” is an extra word?

9.4 Using the reflog. First sentence. One “for” too many.

“we talked about how branches are just is a pointer to the latest commit”

replace with

“we talked about how a branch is just a pointer to the latest commit”

Full-stop missing after “… what it looks like when diagrammed”

Show commits from the last 6 hours
prompt> git log —since=“2 hours”

This command will (obviously) show commits since the last 2 hours.

You can’t actually perform this step because you have already resolved the conflict at the end of the last page. You just get ‘No files need merging’.
Tried to checkout names and modify first-names.txt and then checkout names2 and modify first-names.txt differently to create a conflict, but this did not create a conflict! (I commited after each change). Would really like to see it use the merge tools but I can’t create the situation! Would have to back all the way up and create two new branches to create the situation!
(There are several other places where this is true, following the instructions one-after-another does not give the same results!)

Sentence that begins: That covers the creating and merging…
‘inevitiably’ should be spelled ‘inevitably’ (remove the third ‘i’)

These are three of the areas that most of your time gets spent
—- when you say it aloud it sounds bad, try:
These are three of the areas WHERE most of your time gets spent
—- or:
These are three of the areas that most of your time gets spent ON

— Paragraph that begins: Let’s say you’re an American working in London.
…to tell Git that you want to rename a branch, just like did
— should be:
…to tell Git that you want to rename a branch, just like YOU did

Hello,

it would be nice, if you could tell a little bit about the “core.autcrlf = true” switch on windows systems. I struggled with that issue until I’ve found a hint in the web.

Git interprets that range to mean every commit afterf320 to 5ef8.
— should add a space after ‘after’ (which is italicized):
Git interprets that range to mean every commit after f320 to 5ef8.

— Paragraph that begins: The first 8 characters you’ll recognize…
— In the sentence:
Lines 2 - 4 of the above session, lines 1 - 3 of the file, all have the same
commit name and that lines 5 - 7 have another.
— remove ‘that’:
Lines 2 - 4 of the above session, lines 1 - 3 of the file, all have the same
commit name and lines 5 - 7 have another.

— AND you might want to parenthesize (lines 1 - 3 of the file,):
Lines 2 - 4 of the above session, (lines 1 - 3 of the file,) all have the…

— AND you might pick just ONE numbering convention instead of TWO
— because you still have ‘and lines 5 - 7’ without making it clear that you
— mean lines 5 - 7 of the FILE, not the SESSION
— maybe just call the prompt> line ‘Line 0’ and label it as such,
— so that things match up? much less confusion and easier to read
— (programmers relate to index 0 being the first index, so it’s not confusing)

prompt> git log -C -C -p –1

— Is there a reason why Git wants us to specify -C twice?
— I’m sure everybody reading this will scratch their heads!
— it’s a distraction for the reader, to see such a strange thing unexplained

— Add to that the fact that they might think the –1 (number one) at the end
— might be the letter ell, if they missed that option earlier
— The number one / letter ell problem is all over the place,
— perhaps a super-scripted footnote (or a different font face) might be
— appropriate, or even a page reference to the option/explanation
— (even a side-margin note saying ‘–1 is the numeric digit’ would help)

prompt> git log -C -C -p –1

— Re: previous erratum report on this page by myself:
— Maybe it IS the letter ell instead of the digit one, both are legal
— Just proves my point that it should be clarified everywhere either is used

— In paragraph that begins: In a centralized repository where every…
— Sentence ending with:
…but making those types of changes aren’t fun.
— Should read:
…but making those types of changes isn’t fun.

— Or better yet, rephrase to avoid sounding like John Madden:
…but making changes like that isn’t fun.

How can the repository keep track of content when its commits move around, renamed, or even disappear?
— Add ‘are’ or ‘get’ before ‘renamed’:
How can the repository keep track of content when its commits move around, get renamed, or even disappear?

The simplest way to handle a revert an existing commit is the git revert
command.

— Should be (remove ‘a’ and change ‘revert’ to ‘reverting’:
The simplest way to handle reverting an existing commit is the git revert
command.

— Or possibly just add ‘to’ after ‘revert’:
The simplest way to handle a revert to an existing commit is the git revert
command.

The first sentence in the section “Straight Merging” contains either a gratuitous ‘the’, or ‘another’ should be ‘other’. Either way, it is incorrect as is:

A straight merge takes one branch and merges it into the another
branch.

Please include a section on using git with textmate — presumably in the “Third-Party Tools” chapter?

On page 99, the “Adding a Remote Repository Later” would benefit from other details like the fact that the repo needs to be created first in the remote server before a push to that repository is attempted. Otherwise you’d get an “unable to chdir or not a git archive” fatal error. (git 1.5.6.4)

It would be helpful if on page 90 where ssh is discussed, to have a little explanation on how to set up key authentication with ssh as it’s the method that will be used most often (maybe I’m wrong about this particular assumption?).

You switch between the URL format (ssh://example.com/git-repo) and the scp format (example.com:/git-repos), without mentioning the difference. (In fact, despite using both for a decade or two, I never noticed that they WERE different until recently.) It would be good to point that out.

Also, some (older?) git documentation claims that git:// is the default protocol, which left me scrambling to figure out why git was actually working even though I don’t have port 9418 open, or git-daemon running. If you know the story behind that, it’d be good to have a footnote after “SSH is the default network transport”.

“Configuring Shorter Remote URLs”: Is there a functional difference between using an insteadOf alias and naming the repository via “git remote add”?

“Both of these use the git branch, but they provide different parameters.”

Should either get rid of the “the”, or change to “use the command git branch”.

In the table for Type/Condition for truth, the entry for Iterator states ‘has text’…I believe that should be ‘has next’.

“prompt> git log f320”

It seems that the git installation on my Ubuntu Hardy (amd64) machine with git version 1.5.4.3 is behaving slightly different.
The command line “git log f320” seems to be interpreted as“git log ..f320” (list commits up to f320, including), is shows a slew of commits on my box.

I also would like to recommend that if the Preface is written, you mention the version of git that you used to create the output of the commands, since there are obviously slight differences.

2nd section, last sentence: Remove “then clone the repository located at the /git-repos/hocus.git path.”
You have not introduced any command line for cloning, just URLs at this point, so this sentence just seems to fall out of a blue sky.

In the sidebar “Choosing networking options”, the sentence “For the my personal Git repository…” : remove “the”

The sentence “It pulls all of your changes into their remote
branch, but doesn’t try to merge them into your local branch.
”, should this not be “It pulls all the changes from their remote branch…” The description suggests that you are actually talking about a git push

Please remove the left pointing arrow attached to the master branch line from figure 9.1 because it’s confusing. At first, I interpreted it as being the direction of the positive time axis which obviously is opposite true.

Add files via Git’s interactive add mode
prompt> git add -a

Shouldn’t the -a option be -i?

It would be nice if you could add a short subsection in section 9 or so about creating patches from your changes for publishing on the diverse mailing lists like LKML etc…

“what a VCS is and how DVCS … is different” - should be “a DVCS”

" *All about merging“: something like ”What merging is" would be more parallel with the rest of the list.

“Originally, these repositories were only accessible if you had access to the machines they were stored on.” - This is unclear to me. Do you mean you had to be logged onto the repository machine, or you had to have a live network connection?

“wifi” should be “Wi-Fi”

Figure 1.2 is incomprehensible to me. Specifically, why are there three tiers, why does Joe’s private repository sit between Joe’s public repository and Your public repository, what do the different arrow directions mean.

“What should we store? The short answer: everything.” I don’t think this is a helpful answer, as you probably don’t want to include generated files, binaries, system libraries, DLLs, system header files, third party libraries, interpreters such as Python, etc.

“Some VCS refer to this as your working copy, but in Git it’s the working tree. Git treats your entire history as a tree of changes. The working tree is the current view of the tree that you’re working with.” - this is a bit confusing whether the tree is the history of changes or the tree is the set of files.

“People coming to Git for the first time often have trouble separating what the working tree and the repository is.” - The grammar seems off here; I think that should be “are”, not “is”.

“You make changes to the source code, re-run your unit tests to make sure your changes don’t have any side effects, then commit those changes.” - I’d cut the part about unit tests, as it implies a particular model of development. In particular, people may want to do intermediate checkins even if everything is not entirely working.

“Pulling is sort of like the reverse of pushing.” - kind of vague.

“Git is fully-distributed, though.” - Not a good topic sentence.

“So far we’ve talked about repositories and how they store stuff in them.” - I’d replace “stuff in them” with “things” to mesh better with the next sentence.

“Instead of tracking a models.py file, Git tracks the content - the individual characters and lines that make up the variables, functions, and so on of models.py” - I think mentioning variables and functions confuses things.

“meta data” - “metadata” is more common.

“or where copied code came from” - “or determine where copied code came from” would fit the sentence structure better.

“You interact with the data in those files exactly like you do any another files.” - This sentence is unclear.

“You know what a repository and your working tree is”. Should be “are”.

“Your brances then branch off of that line”. This implies that you can only branch off the master branch.

“It might be a branch to track an older major version of your project” - some motivation about release branches would be good, explaining that this allows you to fix bugs on a released version while developing a new version.

Book says: “It works with branches to keep them synced properly. We
talked about it in the previous chapter, Chapter 5, Understanding and
Using Branches, on page 57.”, but there was no mention of ‘git rebase’ before this chapter. What is the meaning of these sentences? Is there something missing and will be added?

Installing via macports on Mac OS X Leopard was complete failure (missing files, compile errors, …). I finally gave up and installed using installer from google code: google for “git-osx-installer” (it seems I can’t type url in here)…

Maybe you could mention this option for people using Macs.

“Resetting Changes”. I don’t understand how I would use this as an alternative to revert, and would find some examples useful.

Particularly,
“git reset updates the repository and stages the changes for you to com-
mit. This is useful when you notice an error in your previous commit
and want to fix.
Add —soft when you want to stage all of the previous commits, but not
commit them. This gives you a chance to modify the previous commit
by adding to or taking away from it.
”
That sounds useful, but I have no idea what it actually means!

Figure 1.5 “How Branches Work” needs more explanation. It’s not going to make sense to anyone who doesn’t already understand it.

Section 1.8 Merging. This section isn’t clear about what merging is and why you do it. “Merging is taking two or more branches and combining their history into one”. This is somewhat misleading, since you’re not combining two branches into one, but still have two branches. Also, it’s unclear at this point what “combining their history” means; this section makes it sound like merging is some sort of operation on the history only, to update the logs (especially when you discuss squashed merges), rather than an operation on the changes.

“1.4 Manipulating files and staying in sync” - This section should have more detail, as this is one of the major differences between Git and other VCS. I think it should discuss the differences between changes, staged changes, committed changes, and pushed changes, as this is one of the key concepts necessary to understand Git. But this doesn’t get discussed at all until section 2.5.

“Since Git has its heritage in the Linux world, it’s meant to be downloaded as source code and compiled.” That’s contradicted by the rest of the chapter which discusses how to install Git without compiling it. I’d suggest just cutting that sentence.

“the original creator the Linux Kernel” - missing “of”.

“…has never been at the forefront of Git’s mind.” - I didn’t realize Git had a mind. A different wording would be less jarring.

The discussion of Git hashes at the end of page 33 and the beginning of page 34 is a bit repetitive. Both pages mention that commit names are SHA-1 hashes.

“little or no possibility for a collision” - should be “little possibility for a collision”.

The book uses “work flow” and “workflow”; it should be consistent.

“These are all of the day-to-day activities that you go through when you’re working with Git.” I’d suggest “some” rather than “all”, since there are other activities.

“4.2 Adding Files” - I’d suggest a heading such as “Adding Files: The Interactive Shell” since that’s really what the section is about. I think this section could also do with more explanation of the staging area; it feels a bit hand-wavy.

“Like all good Git commands, it’s not just that simple.” This paragraph could use a topic sentence; it’s about “git add”, but that’s buried in the previous paragraph.

Overall, I think the users of this book are likely to flip through it a lot to find what they need. So it’s very important to have strong topic sentences for paragraphs that indicate what the paragraph is about. Try to make it possible for the reader to find what they want even if they’re just reading the first sentence in each paragraph.

" staged unstaged path unchanged +1/-1 days.txt": This could use some explanation about what the output means, as it’s going to be incomprehensible to the new git user.

“you can use the type 2 to stage the file”: Should cut “use the”.

“The log message is only as good as the content that you commit, though.” I’d suggest cutting this; it seems meaningless.

“There are a few different ways to handle a commit. The first is to call git add in some form for every file … that you want to commit.” This section is kind of muddled; it says it’s discussing how to commit a change, but ends up discussing how to add a file to commit, and git add was covered in the previous section. One possibility would be to focus this paragraph on the “git commit” and mention that you do a “git add” previously, rather than focusing on the “git add” and mentioning that you do a “git commit” to close the loop.

“This stages those changes for commit, calling git commit closes the loop” - comma should be semicolon.

“Another way to handle commits is to pass it the o parameter…" ambiguous pronoun ”it“; replace with ”git commit"

“Remember we talked about this as the shortcut around staging changes in the last section.” I’d suggest putting parentheses around this, and replacing “the shortcut” with “a shortcut”.

“We have a repository, we’ve added some files to it, and committed some changes.” I’d suggest “we’ve committed some changes” to make the structure parallel.

“You can use two of Git’s provided commands.” - I’d suggest cutting the word “provided”.

In the sidebar: “just type git config - global alias.ci ”commit" the command prompt." I think “at” is missing before “the”. Also, shouldn’t the font be different for the typed command? Also, is that two dashes or one long dash. And there shouldn’t be a break between the dashes and global, no?

“two-step commit process we talked about on page 25”. I think that was page 49.

“Viewing difference” - should be “Viewing differences”

“It can show you differences between your working copy and the repository as well as your staged commit and the working copy” - I’d suggest adding “between” before “your staged commit”

The “Viewing Difference” section on page 51 and 52 seems muddled; the paragraphs should each discuss a single set of “git diff” parameters, and each paragraph should be associated with the example of its use. There should be a clear topic sentence on each paragraph for people skimming the section.

E.g.
“git diff only shows changes in your working tree that you have not staged or committed yet. You can view the difference between what you hae staged and what is in the repository by adding —cached to the git diff command.” - This paragraph should be split in two; the first part should go near the example of running “git diff” a couple paragraphs earlier, and the second part should be the topic sentence for a paragraph about —cached.

“When you execute git diff without any parameters, it…” - This sentence should also go in a plain “git diff” paragraph, and the rest of the paragraph should be its own paragraph about “git diff HEAD”.

“Things such as moving, copying, and even ignoring some files.” This is a sentence fragment, and should be combined with the previous sentence, perhaps with a colon.

“To Git, a directory is only interesting if it has content in it. Once it’s got that content, it treats that directory as the holder…” Too many uses of “it”, without being clear if “it” is the directory or Git. Maybe change the last “it” to “Git”.

Also, the discussion of treating the directory as the holder of the files is confusing. I don’t understand the difference between moving a directory and moving the holder of the files.

“It seems counter-intuitive at first, and one of the reasons I’ve avoiding bringing it up until now.” - Paragraph should have a topic sentence. Also change “and” to “which is”.

“Whenever you feel the need to copy-and-paste a file, it is almost always time to start refactoring.” Most of the time I copy and paste a file, it’s not a code file; this philosophical debate seems to assume you’re using git for Linux kernel code. (But maybe I’m going off on a tangent.)

Tracking content instead of files: This seems like a key point with git that requires a longer explanation. Section 1.5 briefly says that git tracks characters (?) and lines, Section 4.5 “Copying Files - Or Not” discusses it briefly, and Section 6.5 discusses it some more. None of these sections give a really satisfying explanation of how git tracks content instead of files.

“Whenever you start editing a file… We don’t need to track these files…” - singular/plural mismatch.

This section says to put “*.swp” into .gitignore and then after a few paragraphs says it should really go in .git/info/exclude, not .gitignore. I think it would be better to give an accurate example up front. Maybe .gitignore and .git/info/exclude should both be mentioned at the beginning of the section.

“Is this kind of file something that everyone is going to have in their repositories?” - some examples would be helpful.

“If the answer to that is yes, you need to ignore it…” - I prefer if “need” is only used for things that are truly necessary, and would suggest “should” in place of “need to”.

Footnote 4: “Although, ignoring the common backup files provides a simple early warning system for file naming” - Doesn’t make sense to me.

“You initialize the repository” - Cut the word “you” to make the bullets parallel.

“Add new features, refactor existing code.., and the random bug fixes”: Change to “and fix random bugs” to make it parallel.

“Here is git’s secret: everything is treated like a branch.” The word “everything” is hopelessly vague here, and I’m not sure what you mean. (Other vague usages of “everything”: Section 9.1: “Git stores everything.” Section 1.2: What should we store in a repository: “The short answer: everything.”)

“The first has three parameters.” This is a pretty vague topic sentence, since it is referring to one of the commands two paragraphs back. I’d suggest something like “The first git branch command in the example above has three parameters.”

“Just to tidy things up, let’s rename it back to master.” - unclear what “it” refers to; I’d suggest “the branch”.

“… independent of any changes that are being deployed immediately.” I don’t think “immediately” is the right word here; maybe “concurrently”?

“Whether it’s a fix to a bug in code that hasn’t been released, or code that’s already been tagged for a release.” Sentence fragment. Also, I’d suggest “or in code…” instead of “or code”.

The list of why to create branches: Release branches should be added to the list, as they are a key reason for new branches.

“git checkout new” - this is one of the mysterious “magic” things of git that is very different from other VCS, and I think it should be described in more detail. Files that were in the directory - where did they go? Where did the new files come from?

“[Merging] takes two - or sometimes more - branches and merges them into one.” I don’t really like that explanation, as it implies you end up with one branch instead of two. It also doesn’t really define or explain what merging is.

“This can happen when the same lines get modified in the same file.” - append “in two branches.”

“git branch colors master” - This command should be introduced in the “Creating a new branch” section, not the “Squashing commits” section.

“All you have to do is give git cherry-pick the -n.” Not a good topic sentence. How about “To cherry-pick multiple commits, give git cherry-pick the -n flag.”

"git reset —hard HEAD^{" - git reset isn’t introduced until page 84, so there should probably be a forward reference. Also should explain why HEAD} and not HEAD.

First two paragraphs on git mergetool could be merge together.

I don’t think the list of valid tools needs to be a bullet list; it draws excessive attention to a list that’s basicallly trivia.

“When this happens you need to delete the branch…” - “need to” shouldn’t be used unless you really do need to do something; I’d recommend “should” or “could”.

“After you merge your changes back into your current branch, such as the roman-numerals branch” - “such as from the roman-numerals branch”

“you can use the d parameter on git branch to delete the branch" ”to delete the old branch"

“…but be careful or the other members on your team might quit talking to you after they spend a morning trying to fix broken merges.” Page 82 says “Well, only if you want to keep everyone else on your team talking to you.” - You bring this up twice, but it’s unclear how to “be careful” and what “broken merges” are and how they “fix broken merges.”

“In VCS-lingo” - you mean “git lingo”?

“With ranges, you can swap out the commit name for a tag name” - tag names aren’t explained until page 101.

“So you can do git log HEAD..HEAD. fatal … Actually this is what happens when you specify a revision that does not exist.” - It’s confusing to give an example that doesn’t work, and the explanation is also confusing.

“All of the revision ranges and arithmetic are the same from git log” - change to “… same as with git log.”

“With it, you can figure out how many lines of code were changed and how much was removed.” - change to “how many were removed.”

“git blame numbers.txt” - I don’t like the marginal line numbers, since the output is already numbered, and is off-by-one with the marginal numbers.

“That signifies that they are the boundary of this blame”. What’s the boundary of a blame?

“Using the N notation … regular expressions." These paragraphs should be restructured to have topic sentences. You start discussing regular expressions in the paragraph beginning ”Using numbers is often very convenient" which has nothing to do with regular expressions.

“Of course a lot of times the output from blame isn’t going to be helpful.” I think you mean “the default output from blame”

“… to specify where you want to look.” - “where” is vague; I think it should be “which revisions”

“but it can be used to follow changes…” - suggest: “but it can also be used to follow changes”

“git remote add” should be mentioned here?

In general, section D.5 should summarize chapter 7 “Working with remote repositories”, but D.5 introduces a bunch of commands chapter 7 doesn’t mention, and doesn’t summarize some commands that chapter 7 does discuss.

“Create a branch from another starting point” - should be “start point” for consistency with the text below.

Under “Overwrite existing branch”: “[ ]” - the opening square bracket should be next to the opening angle bracket.

“ask around for a bootstrap repository before you start cloning yourself.” - Is that a joke?

“If you cloned a project within a repository that isn’t the present in the oldest commit” - doesn’t make sense.

“Also like it’s regular Git counterpart…” - should be “its”.

“git svn rebase can’t run when with uncommitted changes in your working tree” - extra word?

“This may take awhile though”. Should be “a while”

“An outdated one that was installed…” - sentence fragment.

“You can use the the b" extra ”the"

“you have every thing” - “everything”

“*Git complains about svn … *An error saying…” - bullets should be parallel.

“There are two ways to migrate from Git to Subversion, the first is …” - run-on sentence.

Sorry, but I’d call pages 130 and 131 chartjunk. The shadow-box, arrows, and boxes make it hard to actually read the content.

“If you’ve been developing for very long, you probably have either a Subversion or CVS repository that already has your complete project history stored in it.” - Maybe change to “If you’ve been developing a project for a long time, you may have …”

“a compelling replacement to CVS” - I think that should be “compelling replacement for CVS”

“To do this, you need to have a script” - Should have a topic sentence introducing automated bisection.

“You can’t exist with the exit code 125 unless … Generally you don’t want to skip unless you just can’t test…” - I’d suggest rewriting this paragraph in positives instead of negatives to make it easier to understand. Also, this is of lesser importance, so I think it would be better a few paragraphs later, probably after “other than 0, it is treated as a bad commit”.

“Logically, you can determine at this point that if the previous commit was good and all of the commits after this point are bad this one must be the cause.” - I don’t get that. It seems that either this commit is the bad one, or the commit after this one is the bad one.

“Marking it as bad causes Git to realize it’s hit the last possible bad commit, and shows the log entry for it.” - too many ambiguous “it”s.

“To do that, save the output…” - should have a topic sentence for this paragraph.

“Figure 9.5, on the following page” - actually, it’s on the same page.

“First things, first, ” - shouldn’t have comma after “things”

“Rewriting history can be dangerous, git reflog is a safety net” - run-on sentence.

“have rigorous acceptance tests created with client” - “the client”?

“your repositories history” - “your repository’s history”

Should define “reflog” - is this short for reference log? I was thinking re-flog at first.

—pretty=oneline - I don’t think you explain this anywhere.

“You can create additional branches to experiment in before you do them in your live branches” - unclear what “do them” refers to.

“Changing the order of commits, breaking one commit, …” - sentence fragment. I’d suggest ending the previous sentence with a colon.

“…a few commits that you made all of the changes” - word missing?

“What about something more complex.” - needs question mark

I suggest replacing:

“These are three of the areas that most of your time gets spent when working with branches”

…with:

“These three areas are where you will spend most of your time when working with branches.”

“by using the >—a greater than symbol” - add space after >

“You have to provide an additional command…” - “If you want to compress the tarball, you have to provide an additional command…”

“You can replace out gzip with” - delete “out”

“…but there is a better way.” - This section needs more discussion of why rebasing is better and when you would use merging vs rebasing.

“…against an updated pointed on another branch” - typo.

“That tells Git not to check and make sure that the branch you are trying to delete has been merged into the current branch.”

I suggest removing “and make sure” from that sentence.

A quick check of file’s log might show that it hasn’t been touched since it was originally hacked together with a log message of “make ready for client demo”.

Missing “the” before “file’s”.

“The same thing happens when I code. “I added that functionality last Monday or Tuesday.” “I fixed that bug this morning.” Git has a lot of functionality for that looking through its logs that way."

The paragraph before this one describes the author’s inability to remember specific dates, but it’s not obvious what this paragraph means by “the same thing happens”. I think it is trying to say that Git can filter history using relatively vague time-frame specifications.

Also, the final sentence of this paragraph appears to have an extra “that”.

“Git can under stand —since=”24 hours“, ”…

The word understand has been divided by a space.

I find chapter 1 a bit unsatisfying. It’s kind of a mixture differences between Git and other VCS, discussion of Git configuration (p15), and VCS philosophy (p16). What I’d like to get out of this chapter is a feeling “Ok, now I understand how Git is different from other VCS” but I didn’t quite get that.

Specifically, “1.2 What Should We Store” doesn’t seem relevant to chapter 1. “1.3 Working Trees” is good but should go into more detail since this is a key difference with Git. “1.4 Manipulating Files and Staying in Sync” should go into details of adding, staging, and committing. Section 1.8 is mostly generic VCS branching, and should go into more detail of how Git branches are different. E.g. lightweight and easy to switch between them compared to other VCS. Section 1.8 should also discuss rebasing, as that’s a key difference from other VCS. Section 1.9 “Locking Options” should state the key point, that Git uses optimistic locking, sooner.

“tells you shell to put the output from…” - I’d replace “put” with “redirect”

It would be nice to have some discussion of the advantages and disadvantages of Git vs other VCS. What sort of projects should use Git instead of a different VCS?

“Or you delete the expiermental branch…, Git knows what was in that branch.” - not a sentence.

“I’m going to use my the repository” - extra word

“You learned how to use tags for the first time” - cut “for the first time”.

“Now you know that there are two different ways to organize your repository” - isn’t that three ways with submodules?

“There are a few extra steps… Lets walk through it here.” - should be “through them”.

“those are here to make…” - run-on sentence.

“the hocus is displayed” - “the hocus repository is displayed”

“Now it’s time to commit this changes” - “these changes”

“Will this project be released by itself? If it will, it definitely needs to be in its on repository. This isn’t a hard rule” - “definitely” seems too strong, maybe “should be”. “its on” should be “its own”. “hard rule” is ambiguous - do you mean a hard rule to follow or a strict rule?

“straight forward” - straightforward

Section 8.5 - I found this section the hardest to follow; it seemed too abstract and unmotivated, and too hard to keep “hocus” and “magic” straight. I think it needs some more explanation of why you’d track external repositories, and what benefit you get from that.

“You can also use periods, ”.," in the name" - there’s an extra comma in the quotes.

“All of the special characters…” - this sentence is missing an ending, such as “… are prohibited.”

What about Unicode characters?

“You can use this to organize them…” - too many vague pronouns.

“There are pros and cons to each, we’ll cover them in this section” - run-on sentence; replace comma with semicolon, or split into two sentences.

“The first and most straight forward is …” - “The first and most straightforward approach is …”

“For example, a project that is…” - sentence fragment. Also, this paragraph could be merged with the next one.

“This is the criteria” - “criterion”

“If each smaller project, or component, is …” - delete commas.

“make sure to switch back to your master branch” - append “first”.

“your organizations development style” - “your organization’s development style”

“for simplicities sake” - “for simplicity’s sake”

“whether they are bug or logic” - sounds strange.

“… your tag marks its place” - run-on sentence.

“to fix a bug in version 1.2 and release version 1.2.1” - I think it would be clearer to replace “and” with “in order to”

“It’s syntax” - “Its syntax”

"- - a tag name" hyphens went strange.

“You can provide a it with an…” - extra word.

“Adding a remote repository later” - this seems like mostly a duplicate of the sidebar on page 96 and the discussion at the top of page 98. I think they could be folded together.

“Say your team includes developer named Erin…” - this should be a new paragraph. Also should be “a developer”.

“from their repository.” - sounds awkward, maybe “from Erin’s repository.”

Sidebar: “there might be a case were you need to let someone push changes into your private repository”. So what do you do to let someone push changes into your private repository?

“The syntax the same” - missing word

“Any of the URLs we discussed Section 7.1” - missing word.

“If you didn’t clone your repository, but still want to share it no sweat… You might be able to guess what the command is called: git push” - I think there are two unrelated topics in that paragraph.

Footnote: “That’s the default behavior, you can …” - run-on sentence.

“Resources” - I’d suggest mentioning github.com.

“straight-forward” - no hyphen needed

“a working WebDAV server” - maybe explain more about this.

“I SSH keys for authenticating users” - missing word?

“Adding new remote repositories” - “How to add new remote repositories” would be a more parallel construction.

“That network can be your internal LAN, a VPN, or over the Internet” - delete “over”

“Git provides three protocols” - I count four, since http and https are separate protocols.

I think this whole page should be reorganized:

Move heading “Squashing and Reordering Commits” to the start of the example, i.e. before “The tool for this kind of voodoo…”

“You have to provide the rebase command with the revision…” - this should be a separate paragraph from “The interactive mode”.

“The interactive mode…” - this sentence should be added to “Everything in my editor…”

“Move 5 to just the second line.” - doesn’t make sense.

“Just by looking at this short, one line output from git log you can guess that the first commit didn’t include everything that it was supposed to.” - This confused me. It’s three lines of output, not one. “the first commit” - ambiguous if this is the first in the output or the first chronologically. “you can guess the first commit didn’t include everything that it was supposed to” - unclear if you mean the Person model or not.

“For example… first reset it, then check it out” - run-on sentence.

“And would logically fit somewhere else.” - sentence fragment.

Also, rewriting history should probably get mentioned in chapter 1, as this is a major difference between Git and other VCS.

“When detecting for copies within the git log command…” - needs to be rewritten.

“All of these commands…” - suggest replacing “these” with “the following”

“move around, renamed, or even disappear” - add “are” before “renamed”

“you can cause problems for people…” - too vague. You mention a couple other places that changing history can cause problems and teammates not speaking to you, but I think there should be more detail on what the problems are, how to avoid them, and what to do if they happen.

The paragraph beginning:

“All of the special characters we covered in Section 6.2, Specifying Revision Ranges, on page 74 along”…

… does not have any context to explain what is being listed - permitted or prohibited characters.

I suggest creating a couple of bullet lists - one containing the rules determining what is valid and the other listing the notable exclusions. Alternatively the first part of that paragraph should be converted into a proper sentence to explain what it is listing.

The sentence:

“This means that releases/1.0 is a valid tag name, but neither releases/.1.0 nor .releases/1.0 are.”

… would be better if the word “are” was moved immediately after the word “neither”.

“Just like the other git submodule commands, this takes the name of the submodule you’re working with as it’s parameter.”

“it’s” - spurious apostrophe.

Shouldn’t “git grep” get a mention in the book? It seems like a useful command to describe.

“I like my development interfaces to all same font at the same size…”

missing a “use the”?

“Eclispe Git Plugin”

“Eclispe” -> “Eclipse”

The Appendix appears as a subsection of Administration in the pdf structure (i.e. the left-hand tree in Adobe Reader).

The Appendix appears as a subsection of Administration in the pdf structure (i.e. the left-hand tree in Adobe Reader).

“It requires the TLC/TK” - should be “Tcl/Tk” (not all caps); it’s Tcl, not TLC; and “the” shouldn’t be there.

I think the book should explain in more detail how git stores data: blob, tree, commit, and tag objects. This would clarify some things that are currently hand-waving. The “git show” command should be also explained, how it lets you view these basic objects.

Stray “s” at the end of:

exists “over there” on another server.s

It would be nice to introduce the “tree-ish” concept, since it is used a lot in git documentation.

At “Well, you start your own project, then tell Git to initialize a repository for it; or you can clone an existing repository.”

I think symmetry and clarity demand ‘you can start’. Or even ‘either you can start’ and then maybe replace the semi-colon with a comma? I might use ‘project and then’ in place of ‘project, then’ too.

At “There’s two steps”; use “There are two steps”.

At “Maybe you follow an Agile
methodology”, I would probably not capitalize ‘agile’; if I did, I would probably also capitalize Methodology.

It would be nice to describe what to do if a checkout or merge gets “fatal: Entry ‘foo’ not uptodate. Cannot merge.”

Maybe there should be a section on common git errors and how to deal with them.

It would be nice to describe what to do if you get “fatal: cannot do a partial commit during a merge.”

“Vim, or it’s predecessor vi, are” - should be “its”

“TicGit let’s you disconnect again” - should be “lets”

“your current repository and and the branch you’re on” - repeated word

“those who have setup Gitweb” - should be “set up”; “setup” is a noun

“It is the hosting provider …They offer several unique features.” - singular/plural inconsistency. Should be “it” or “they” in both places.

“The source for all thing’s Git” - should be “things”

“is becoming stronger ever day.” - “every day”

Change “brain child” to “brainchild”

Footnote: change “bail out” to “bailout”

Also, this blurb is a few days out of date! Rather than the “American banking system”, the trouble is now worldwide!

Change “every day tasks” to “everyday tasks”

Change “it’s killer feature” to “its killer feature”

Change “other developer’s repositories” to “other developers’ repositories”

Change “you learn about some organizational techniques” to “YOU’LL learn about some organizational techniques”

How about getting rid of ‘Then’ next to the last bullet point

Change “program as whole” to “program as A whole”

Change “the command you run in in the command line” to “the command you run ON the command line”

“jumping off place”
How about “jumping off point”

“without any further ado”
How about: “without further ado”

3rd paragraph: Seems odd to say DVCS are no different, and then say how they’re different. Maybe “no different in those respects”?

(also sounds funny to use ‘VCS’ and ‘DVCS’ as plural words, but oh well)

“The repository is the place that”
How about: “The repository is the place WHERE”

“along with when the change was made”
How about: “along with when EACH change was made”

“Making a commit doesn’t involve connecting to a remote repository, the change is just recorded on your local repository.”

How about:
“Making a commit doesn’t involve connecting to a remote repository; the change is just recorded in your local repository.”

(2 changes)

3rd paragraph talks about pushing but for some reason not pulling.

Change “There’s two steps” to “There are two steps”

“All of your work happens in the working tree, that we talked about earlier.”
2nd part of that sounds unnecessary

“You can create a new directory in the repository for each project so they all share a common history”

How about:
“You can create a new directory in a repository for each project so the projects all share a common history”

“Git can merge them together.”

How about:
“Git can merge them together automatically.”

“Joe and Alice both create clones of the repository they share and starts making changes.”

How about:
“Joe and Alice both create clones of the repository they share and START making changes.”

“We’ve taken a 30,000 foot view of the DVCS world the way Git interacts with it.”

doesn’t sound quite right… maybe “AND the way Git interacts with it”?

“You learned how files are tracked, how repositories stay in sync and got an introduction to tags, branches, and the art of merging.”

How about:
“You learned how files are tracked and how repositories stay in sync, and got an introduction to tags, branches, and the art of merging.”

“straight forward” -> “straightforward”

“they tend to be out of date quite rapidly.”

How about:
“they tend to GO out of date quite rapidly.”

“I advise against using adding doc…”

How about:
“I advise against using doc…”

“Git uses SSH (Secure Shell) as the default transfer protocol when it talks to other repositories.”

“Git uses SSH (Secure Shell) as the default transfer protocol when it talks to REMOTE repositories.”

“That’s all there is to configuring Git—you’re ready to start using Git.”

How about:
“That’s all there is to configuring Git—you’re ready to start using IT.”

“view all branches instead just the current one.”

Change to:
“view all branches instead OF just the current one.”

“Just replace out with…”

How about:
“Just replace with…”

“Don’t worry you have trouble installing the documentation, you can always access the documentation online at kernel.org…”

How about:
“Don’t worry IF you have trouble installing the documentation; you can always access IT online at kernel.org…”

(3 changes)

“You have Git running, now it’s time…”

How about:
“You have Git running; now it’s time…”

“getting setup”

How about “getting set up” or “getting ready” etc

“Technically, this has a lot of advantages. It reduces the amount of storage space needed to store the entire history of your repository ”

Are you sure that’s true? Other sources say that git’s storage is much less efficient than storing diffs. (That’s why git has pack files and git gc.)

“and makes it feasible and fast to do things like detect functions or classes moving between two files or determine where copied code came from.” - as far as I can tell, git’s storage is orthogonal to git blame’s detection of moved lines, and that’s just done by (more or less) brute force.

[last paragraph]: Here’s the first first two lines
[change to]: Here’s the first two lines

Git tries to match at least three lines when it
tries to detected a copy and paste.

Change to detect

Change, “either you one you created in the last chapter, or a cloning mine” to “either the one you created in the last chapter, or a cloning of mine”

Change “git add feels both” to “git add fills both”

Change, “a place that you can setup commits” to “a place where you can setup commits”

Maybe change “name of a file or files” to “name of a file or the files”

The word “just” feels overused and appears to be a filler word in most instances. Many times the word “just” can be omitted from a statement in order to give it a more authoritative quality.

For example, page 10: “Completely disconnect and just work with out the distractions of an always-on Inter net connection.” could be " Completely disconnect and work without the distractions of an always-on Inter net connection. "

Page 12: “keep in mind they are just jumping of f points ” could be “keep in mind they are only jumping of f points”

Page 53: “This generates a list of files that can be staged. In this case, there’s just one file to add, so just type in 1 and it will…” could be “This generates a list of files that can be staged. In this case, there’s only one file to add, so type in 1 and it will…”

“its” should be “it’s” in “If its the first thing you do”.

The word break
“in
tact”
is missing a hyphen.

“either you one you created in the last chapter, or a cloning mine” : The a is probably a typo.

“Like the -a> parameter” : Superfluous > character.

The part “Tracking empty directories” begins with this :
Git doesn’t doesn’t track directories.
It must by an error to have doesn’t two times no ?
My english is very poor so mey be I’m wrong.

On the page 2 (about the PDF being a Beta book), the link for errata goes to the errata for “Enterprise Recipes with Ruby and Rails”.

“you can skim the Part I for the Git specific and then”

seems to lack something after “specific”.

You mention git’s ability to communicate with subversion, I couldn’t find anywhere in your book a warning that this isn’t yet working with msysgit.

“Subversion 1.5.0, which was released in June of 2008,”

Is the “of” in “June of 2008” good English? It feels wrong to me, but maybe it’s an American versus Commonwealth English issue.

s7.4 footnote 1 indicates that pushing to a remote branch is not a common case. You need to do this to create the remote branches on github which I find myself doing more and more. I have to remind myself using git-help-push but that explanation could use some of the love your book provides so it sinks in. Many thanks!

Re Missing SVN/Core.pm : Shouldn’t the instructions also mention Windows / Cygwin, perhaps by referring to the installation chapter?

para.1 - change “rolls” to “roles”

in last para “Git has a lot of functionality for that looking through its logs that way”, remove extra “that” (or rephrase entirely - it’s pretty clunky)

“With the the git protocol,” : One the to many.

“it’s made simple by a program called Gitosis, which
we’ll cover in the (as yet) unwritten sec.gitosis.”

This section is no longer unwritten…

“Your local copy created by cloning works just like it would if you had created it yourself using git init like we talked about in the (as yet) unwritten sec.common.init,”

Guess this is referring to section 3.1?

In third paragraph starting from the end of the page.
It says:
“Using the -N notation allows you to subtract out that many lines.
You can use -L 12,–2 to show lines 2 and 3 of your file.”

Lines are wrong.
It must say:
“You can use -L 12,–2 to show lines 11 and 12 of your file.”

sudo make install install-doc

will cause a recompile, unless you’re using the default prefix. It should be:

sudo make prefix=/usr/local install install-doc

or whatever prefix you choose to use.

Para:

We’ve got the basics—adding new files, modifying existing ones, and
looking at the repository’s history—out of the way; now let’s get into
something more meaty and tur n are attention to branches.

should end:

“turn our attentention to branches.”

First para:

on—but every one of those in dependent on the tools and methods you use.

should change “in” to “is”:

“those is dependent”

Para starting: “As you can see, Git displays…”, change

“show us when whole files can been copied”

to

“show us when whole files have been copied”

In the “what are SHA-1 hashes” box, the phrase “a unique
hash that has a small probability of ever colliding with another commit” is vague. How was the “1 in 2^63” obtained?

We can say, for example, that to observe one or more collisions with 50% probability, we would need approximately 2^80 commits (according to the birthday paradox, since SHA-1 has 160-bit outputs.)

The text reads as:

You can use the command on one line
without the “\\.”, those are here to make the command fit on the page.

This should probably be:

You can use the command on one line
without the “\\”, those are here to make the command fit on the page.

The backslash doesn’t actually have a dot.

The text reads as: You can use the command on one line without the “\\.”, those are here to make the command fit on the page.

This should probably be: You can use the command on one line without the “\\”. Those are here to make the command fit on the page.

In addition to my previous report of the dot problem, the original appears to be a run-on sentence as well. At the very least, it could use a semicolon.

In second paragraph from the end of the page:
It says:
“[…] and the directory where you want to repository to live. […]’
I think it must say:
”[…] and the directory where you want the repository to live. […]’

“developed to track changes made to the Linux Kernel”

Kernel is not a proper noun; it should not be capitalized.

Change “specific” to “specifics”.

“Branching is so key to how Git operates there’s a full chapter explaining what they are and how to use them.”

Noun-pronoun disagreement. Should instead read: “Branching is so key to how Git operates there’s a full chapter explaining what IT IS and how to use IT.”

It is bad style to follow verbs with colons. Under “Typographic Conventions” you should instead write, “They are the following:”

“Most store the current state”

Most what? Most version control systems? Most repositories?

“message that explains why they made the change”

They who? This pronoun has no antecedent.

Missing comma after “of course” in “and of course your unit tests.”

Ask yourself, "if I didn’t have X

“If” should be capitalized.

“so you have to get your hards a little” should be “so you have to get your hands a little”

At the bottom of the page it says: “Now you can add start making changes ..”. Remove “add”.

“This is necessary for Windows to know what to find the git command on your system.”
“what” should probably be “where”.

2nd last paragraph:
“That also introduces a new parameter to git log, the –1. You can change the number to limit the output of git log to the number of commits you want.”

- This is the first mention of git log, so the text should be rephrased.

“Report erratum” only works on some pages of the pdf document, not all. For example page 50 and 51. I believe this is the same for all “new chapter pages”.

At the bottom of the page it says: " .. either you one you created in the last chapter, or a cloning mine ..“. Should probably be: ” .. either THE one your created .."

Third para:
“Since I know that MacVim swap files always begin with a period and end with .swp, I just add .*.swp to the .gitignore and Git ignores all matching files.”
Missing ‘file’ after ‘.gitignore’

First para:
“If the answer to that is yes, you need to ignore it by adding the rule the .gitignore file and committing that file to the repository.”
Missing ‘to’ between ‘rule’ and ‘the’.

Last para:
“We’re going to be work with the repository that you’ve created up to this point.”
Change ‘work’ to ‘working’.

Top of page:
“on git branch to delete old the branch.”
‘old’ and ‘the’ transposed.

Para three:
“For the my personal Git repository, I use a mixture of SSH and git.”
Remove ‘the’.

The first sentence beneath the “Straight Merging” header reads as follows: A straight merge takes one branch and merges it into the another branch.

There is an erroneous “the” — it should read: A straight merge takes one branch and merges it into another branch.

Last prompt on the page:
“prompt> git checkout -b another-from-1.0”
Should this not read:
“prompt> git checkout -b another-from-1.0 1.0”?
(The para above mentions the tag name as a second parameter)

Last sentence, 5th para:
“Will this project be released by itself? If it will, it needs to be in its on repository.”
- Change ‘on’ to ‘own’.

The top of the page is pretty much a repetition of the bottom of page 120.
I think you want to show the results of running “git submodule”, not “git submodule init”.

4th para:
“To give our examples some meat, I’m going to use my the repository my book is stored in.”
Remove the first ‘my’.

5th para:
“In that few weeks”, change to “In those few weeks”.

2nd para:
“against an updated pointed on another branch.”
Change to “against an updated point on another branch.”

2nd last para:
“One of the key tenets that Linus set for for Git”
Remove extra ‘for’

After checking out mysite-chp6, “the two files we created earlier” should be “the five files we created earlier”

The SSH URL shown in Figure 7.1 is missing a colon, and will not work as shown. It should be “git@github.com:/tswicegood/mysite-chp6.git”

In the git svn clone command, the first option should be —prefix (with two dashes) instead of -prefix.

The git tag command does not support the -r option as shown in “Show all remote tags”.

I think the mapping of “svn commit” to “git add; git commit” is incomplete. It should also include “git push”, since in svn every commit is sent automatically to the remote repository. This comment also applies to the mapping of “cvs commit” in p. 140.

After running the git merge about2 command and explaining the CONFLICT line it reads:

“This is what my list from about.html looks like now:”

and shows some of the output from git diff HEAD.

Using the terms “list from about.html” is a bit confusing. Perhaps replace this line with instructions to run git diff HEAD and show the full output.

Correction to my previous suggestion. I have just now looked at my about.html file and seen what I was supposed to see. The extract that I thought was git diff HEAD is actually the contents of the about.html file.

Still the line “This is what my list from about.html looks like now:” is a bit confusing. It should be more clear that the conflict has made modifications to the about.html file and that you should open or refresh the file to see this.

It wasn’t until I read the second paragraph on page 77 that I realized what was originally intended.

The box on “Adding a Remote Repository Later” is great, and addresses a common need. I believe it could be made better by briefly summarizing all of the steps needed to attach a locally created git repo to a remote repo for the usual case: you made a local repo with git init, and now need to upload it to a remote server.

First, you must create the remote repo: mkdir the directory for the remote repo on the remote machine (e.g. mkdir /repos/pocus.git) , and in that directory: git —bare init . Also, since many of us put ssh access on non-standard ports, the port number should be part of your ssh url in figure 7.1: ssh://myusername@github.com:4321/tswicegood/mysite-chap6.git . For the box on page 110: git remote add origin ssh://git@example.com:4321/repos/pocus.git

In the first paragraph, “git add feels both of these rolls” should read “git add fills both of these roles”.

In the sentence “If you’ve skipped ahead, you can clone the repository from it’s GitHub repository” in the last paragraph, that “it’s” should instead be “its” i.e. with no apostrophe.

When you discuss pushing changes to a remote git repository you don’t make any mention of the fact that the git push won’t update the local files at all on that repository and will only touch the history and the refs. So people following along trying to push local changes to a remote ssh repository wont see the files update. I really think you should mention this problem, and indicate that its a git design decision, as written at the git website git.or.cz in
at this place ( i am not allowed to put hyperlinks so I am doing it this way): /gitwiki/GitFaq#head-b96f48bc9c925074be9f95c0fce69bcece5f6e73

And I think you should tell people they need to drop in the post-update hook so they get the expected behavior of updating the actual files. I think especially people coming from subversion and cvs will expect this behavior and be very frustrated otherwise. And I would include the source code to a sample post update hook (such as the one mentioned in the link above).

Thank you.

2nd paragraph after the command snippet.

Each one marks the progression of you code.

should be

Each one marks the progression of YOUR code.

-Shant

2nd to last paragraph

Rebasing takes the changes from branch and replays them on top of another branch.

should be “from a branch”

In the first paragraph, “lets you share you work with others” should read “lets you share your work with others”.

In the second paragraph of section 7.4, “This is the step you go through to send your commits with another repository” should read “This is the step you go through to send your commits to another repository”

In the final paragraph when referring to the syntax of “git push”, the text reads “The syntax the same”; it’s missing an “is”.

There’s a typo in the sentence “Now it’s time to commit this changes” right before the commit of the submodules; it should read “these changes”.

In the second paragraph, the sentence “… on page 66 we talked about how branches are just is a pointer to the latest commit in that line” has an extraneous “is”.

In the second paragraph in the sentence “Also like it’s regular Git counterpart”, that “it’s” should be “its”.

In the second paragraph in the sentence “First, you can try to enlist the help of a sysadmin buddy bribing, err… paying him to help your out”, that final “your” should be “you”.

para. 7: “I shortened the commit on line the second line of the output so it would …” should be “I shortened the commit on the second line of output …”

Near the end of the sentence immediately before the git clone command, “you can always clone the repository to get repository that I built”: insert “the” between “get” and “repository.”

“developer named Erin and you constantly pull changes from their repository” should be “a developer named Erin and you constantly pull changes from her repository”

Is it possible compile git just running make without running ./configure before? I coudln’t.

“Setting this up requires a two steps.” => “Setting this up requires two steps.”

the example: git tag contacts/1.1 contacts
doesn’t work with the: git clone git://github.com/tswicegood/mysite-chp7.git
taken from the server on 30th Nov as it only has a master branch

Last sentence on page says: Next up is a adding a link…

Remove ‘a’ before adding.

When discussing .gitignore it might be useful to also mention the config option core.excludesfile. I have mine set to ‘core.excludesfile=/Users/danimal/.gitignore’. When set as a global option a user can put common ignore file patterns in a single file and have them apply to every project. This is very handy for personal prefernces like Vim *.swp files and won’t carry across to other repo users as it’s not installed into the project directly.

Fourth paragraph: “…you can see that there’s one changed change” should be “…you can see that there’s only one STAGED change”?

Note that it has the header “Changes to be committed.” That tells you
know that it’s waiting to be committed.

should be lets you know, or tells you that.

With all of this changes—let’s create a commit so our changes are
tracked.

this = these

…figure out that name by asking the file system about it, but what it
cares about is the content that stored inside them.

4th paragraph, last sentence.

content that is stored, or content sorted inside. Not - content that stored

to the chapters happened in their own branch, then I merged those
change back in to the beta branch once they were ready.

4th para from bottom, change should be changes

You write of adding to the .gitignore file, but I think you mean creating a .gitignore file with one line of content, “.*.swp”. Explain that this file needs one line per filename pattern to ignore. Similarly for .git/info/exclude.

Third paragraph in Section 1.3, “s” after the last period should not be there

Last paragraph: We are going to be workING …

“Opps” should be “oops”.

“and wait” s/b “and wait”

“counter part” s/b “counterpart”

“git pull erin HEAD” s/b “git pull erin”? since HEAD was not specified in the previous command?

Regarding this:
The release branch should only last for a short period while your release
goes through any final testing. Once the release is ready, you create a
tag to mark the occasion and delete the branch.

Do you mean that when the release’s bugs are fixed, then you would merge the release branch with the master branch? But what happens if there is new development on the master branch? Then the release is at risk because of bugs introduced on the master branch since the branch, no?

“the commit the tag” s/b “the commit tag”?

Regarding my erratum:
“the commit the tag” s/b “the commit tag”?—Keith Bennett

I was wrong, you were right. I misread it.

“the commit referenced by the tag” might be a little clearer than “the commit the tag referenced”, but your way is correct too.

“straight forward” s/b one word

“setup too” — I think you mean “set up too”? “setup” is a noun, and I don’t think that’s what you mean.

Regarding “Adding —aggressive tells Git to recalculate those deltas from scratch when it runs its optimization.”…

I would have thought that all Git stores is those deltas, so that recalculating them would be impossible. If that is not the case, then it would be helpful (to me at least) for you to elaborate on that to explain it.

another workable URL would be
ssh://git@github.com/tswicegood/mysite-chp6.git

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

Shrinking the Size of Your Repsoitory box. Near the end it states 31,0000 commits. Either too many 0’s or a misplaced comma.

The first command

prompt> git svn clone -prefix svn/ -s svn://svnrepo/sunshine

is missing a hyphen before the option. It should be —prefix instead of -prefix

Word-wrapping “SHA-1” on the hyphen looks funny. I would think a hard hyphen there would help.

the name of the prerequisite package is “build-essential” (instead of “build-essentials”)

“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?

2nd paragraph, 2nd sentence, “Rebasing takes the changes from branch” should probably be “Rebasing takes the changes from a branch”

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.

I am not a git expert (obviously) but it appears that the name in the gitosis.conf file “mysite” should be the same as the name of the repository added in the “git remote add” command, but in the second, it has a “.git” extension

In the last example on the page we are examining another way of creating a branch from a tag. The text explains that we can give the name of a tag as the second parameter, but the sample command does not reflect this.

Command (from text):

git checkout -b another-from-1.0

Intended (apparently) command:

git checkout -b another-from-1.0 1.0

“an updated pointed on another branch” should read “an updated point on another branch”

To do this, you need have a script

Should read:

To do this, you need to have a script

The command “git branch -m mymaster master” is incorrect; since “master” is the old name and “mymaster” is the new name, the command should instead be “git branch -m master mymaster”

The sudo adduser command provided will not create the user, merely the group. Adding the —system flag will make the command process as it should.

In the box /Shrinking the Size of your Repository/:
“31,0000 commits”

Too many zeroes or misplaced comma?

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

prompt> git reset —hard HEAD^
doesn’t work on Windows (I’m prompted with: More?).
Adding quotes around “HEAD^” solves the issue.

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.

You say git branch RB_1.0 master – it might be worth explicitly saying here that the ‘branch’ command implicitly changes you to be on the RB_1.0 branch, thus changes will not be made to the ‘master’ branch ( which we may well assume, per the thought experiment, that my peer reviewers are looking at ).

“Right now your repository looks like Figure3.1. After rebasing, it looks like Figure3.2, on the following page.”

Having both diagrams on the same page, if possible, would really help online PDF reading (ie, single page fit-to-screen.)

Also, the text size in the two diagrams looks different, which is distracting for some reason.

Its reads: “Now it’s time to commit this changes.”

It should read:
“Now it’s time to commit these changes.”
or
“Now it’s the time to commit this change.”

It reads: …against an updated “pointed” in…
It should read: …against and updated “point” in…

“git@github.com/tswicegood/mysite-chp6.git” should be “git@github.com:tswicegood/mysite-chp6.git”

-prefix should be —prefix on the git svn clone command half way down the page.

Info:
git version 1.6.1.3
gitosis version 0.2

You wrote:

For each new repository you want to create, add a new writable line with
that repository’s name. Once again, commit your changes and push
them to your server. After pushing the changes, you can add content to
your new remote repository.
——

In fact you have to write
“writable = repo-a repo-b”
and not
“writable = repo-a
writable = repo-b”

At least on my installation.

Markus

The SSH URL should be:

ssh://git@github.com/tswicegood/mysite-chp6.git

At least that’s what worked for me (on a different repo, of course) when I worked at it.

I see there’s already an erratum saying it should be something else, so maybe we’re both right.

The URL for SSH in figure 7.1, at the top of the page, is incorrect, as it omits the protocol. It should be:

ssh://git@github….

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.

Replace “some partially completely algorithm change” with “some partially complete algorithm change”.

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.

The second short commit name in the example “git log 18f822e..0bb3dfb” does not match the range described in the explanatory text: “Instead, Git interprets that range to mean every commit after 18f822e to 5ef8.”

first code example (second line)
EMCAScript should be ECMAScript

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

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.

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.

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.

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…

In the commit message Javascript should be referred to as JavaScript

In the commit message, EMCAScript should be referred to as ECMAScript

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

GitHub actually does support HTTP now, although it is extremely slow

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.”

Code files (both .tgz and .zip) are empty. If there is no code, no code files should be offered for download.

Fourth paragraph:
“This brings us to the end of the basics chapter”
should be:
“This brings us to the end of the beyond the basics chapter”
Maybe “the end of this chapter” would flow better?
Hmm, my version date is not listed: P1.0 printing November 2008
Version: 2008-11-18

On page 85, fourth line:

“The following three commands would all grab the same revision” should be “The following four commands -”

There are actually four commands below it.

Figure 7.1 should be: git@github.com:tswicegood/mysite-chp6.git

You never use ‘_{#’ except this one. ’}#’ shoud be ‘~N’.

“keydir directory” should be “keydir/ directory”

You have always put ending slash for directories.

Missing ‘#’ for comments.

This is a combination of two commits.

1. The first commit’s message is:

should be

1. This is a combination of two commits.
2. The first commit’s message is:

I believe you are referring to the master branch and not RB_1.0:

"A quick check of git log shows that you have only the three commits
that were in your RB_1.0 branch:
prompt> git log —pretty=oneline
4b53779 Add in a description element to the metadata
a5dacab add

and