Errata

(This is exceedingly minor and doesn't affect the reading of the book - just a consistency thing I noticed)
The page number text is formatted erratically -- for instance on page 58 it mentions "on page 80" in the first paragraph, but the "0" is a shorter size. Yet, you can see that the page number of that page "58" has the 5 lower than the 8 - but the next page "59" page number has them at the same baseline. There are many instances of this (ie page 96 vs 97, 148 vs 149, 182 vs 183). Doesn't really need to be fixed per se.

Note from the Author or Editor:
Hi team, is this something that needs to be fixed? I think it's more of a design error perhaps.

The single sentence of the third paragraph on page 7 ends "then you should continue ono the next section to install an up-to-date version of Git on your computer." That should probably be "... continue on to the next section ..." [continue ono -> continue on to]

Note from the Author or Editor:
Yes, you're absolutely right, we will have to fix this. Thank you for bringing this to our attention! (-:

The Follow Along 1-14 shows the following prompt and command:

$rainbow $ git config --global --list

The initial part of the prompt is meant to be the user's current working directory. Previous Follow Alongs asked the user to create directories 'desktop' and 'rainbow'. Therefore, the '$' before rainbow looks like a minor mistake. The prompt and command should read:

rainbow $ git config --global --list

Note from the Author or Editor:
The reader is right. This is a mistake. It should be changed to:
rainbow $ git config --global --list

Figure 2-1 shows the contents of the '.git' local repository directory immediately after issuing the 'git init -b main' command. The first file is given as '.config'. However, on my system, and in every cloned repo I have examined, the file is 'config', without the initial 'dot'. So, I believe that first file should be 'config' rather than '.config'.

Note from the Author or Editor:
Yes, the reader is right, the file should be config not .config.

The NOTE begins: "There are times where you can be on a commit ...". Given that the sentence begins "There are times ..." I would expect the subordinating conjunction to reflect a temporal reference rather than a spatial one. Although the sentence is understandable as written, I believe it would be (slightly) better as "There are times when you can be on a commit ..." [where -> when].

(Yes, this is rather picky. No doubt opinions may differ.)

Note from the Author or Editor:
The reader is once again correct. Let's use the correction suggested by the reader.

"There are times when you can be on a commit...."

The final sentence of the paragraph ends "... once called chapter_five_approach_a and one called chapter_five_approach_b." That should be "... one called chapter_five_approach_a and one called ..." [once -> one]

Note from the Author or Editor:
Yes, the reader is correct, the word "once" should be changed to "one".

In the sentence "I make two branches off the main branch,
once called chapter_five_approach_a and one called chapter_five_approach_b."

We need to change the word "once" to "one". So it reads:

I make two branches off the main branch,
one called chapter_five_approach_a and one called chapter_five_approach_b.

The last sentence of the paragraph begins:

At the time of cloning the remote repository URL was associated with a shortname in the local repository, ...

It would help readability by adding a comma after "At the time of cloning". Otherwise, "the remote repository URL" is likely to be taken as the direct object of the participle "cloning" which then leads to an inability to parse "was associated ...". This forces the reader to backtrack and try to parse the sentence again. Using a comma to mark off the initial temporal adverbial phrase allows the reader to treat "the remote repository URL" as the sentence's subject and smoothly parse the remainder of the sentence.

(Yes, I am being picky again. However, if I had a problem with this sentence, it is highly likely that other readers have had a similar experience.)

Note from the Author or Editor:
The reader is right, let's fix this as they recommended.

The first sentence begins: "Suppose I work on chapters 1, 2, and 3, of my book, ..." I would say there is an extraneous comma after '3' so I would suggest changing it to "Suppose I work on chapters 1, 2, and 3 of my book, ..." See the next sentence for a similar phrasing which does not have the extra comma.

Note from the Author or Editor:
Let's change this as well as the reader recommends.

The book suggests removing chapter_two.txt and chapter_three.txt from the staging area after staging all three chapters (chapter_one.txt, chapter_two.txt, and chapter_three.txt), intending to leave only chapter_two.txt for the commit. However, following this instruction would leave only chapter_one.txt staged. A slight adjustment would be to remove chapter_one.txt and chapter_three.txt instead, ensuring that chapter_two.txt remains staged, as originally intended for review.

Note from the Author or Editor:
The reader is absolutely right! We need to fix some things in this chapter. See below the text where I have fixed the things:

"Suppose I work on chapters 1, 2, and 3, of my book, editing the files corresponding to those
chapters: chapter_one.txt, chapter_two.txt, and chapter_three.txt. I add all the
chapter files to the staging area, which means all the changes I have made to chapters 1, 2, and
3 will be saved in my next commit. My plan is for my editor to review all of my changes.
Before I make the commit, however, I realize that only the changes in chapter 2 are actually
ready to be reviewed. In other words, I want only the changes that I made in chapter_two.
txt to be included in my next commit. Since the staging area is a rough draft space where I
can add and remove modified files in order to craft what will be included in the next commit,
I’m free to remove the modified chapter_one.txt and chapter_three.txt files from this
area, so that only the changes in the modified chapter_two.txt file are included in my next
commit. This means my editor will review only those changes."

The paragraph begins: "InExample Book Project 12-11, ...". That should be "In Example Book Project 12-11, ..." [InExample -> In Example].

Yes, trivial, but if someone is going to update the text at all they might as well update such trivialities.

Note from the Author or Editor:
The reader is right, let's fix this.