The Author Online Book Forums are Moving

The Author Online Book Forums will soon redirect to Manning's liveBook and liveVideo. All book forum content will migrate to liveBook's discussion forum and all video forum content will migrate to liveVideo. Log in to liveBook or liveVideo with your Manning credentials to join the discussion!

Thank you for your engagement in the AoF over the years! We look forward to offering you a more enhanced forum experience.

Hi Mike,

Thank you for contributing to the forums. What you experienced is a peril of technology publishing: technology changes!

Based on your observation, the phrase 'forward-port local commits' is indeed deprecated. Since Git is a well-documented and well-tracked open source project, I dug into the history of this change.

The change was made in commit b385085b on March 2016 by Stefan Beller. In this commit message, he writes:

[The 'phrase' forward-port local commits] is introduced in c3f0baaca
(Documentation: sync git.txt command list and manual page title, 2007-01-18 ),
but rebase has evolved since then, capture the modern usage by being more
generic about the rebase command in the summary.


There is a brief thread when Stefan announced this patch in git-core's mailing list, which you can view at:

https://marc.info/?l=git&m=145687260911184&w=2

Thank you again for your comment!

(NOTE: Digging into Git's history is an exercise in software archaeology. For this I used git blame, the git-core commit logs, and a searchable archive of the git-core mailing list.)
Manning has been doing the work to repair the MoreLunches website. At the moment, going to this site redirects to Manning. Thank you for your patience!
559007 wrote:I get the following message when attempting to access MoreLunches.com:

Warning! Domain mapping upgrade for this domain not found. ...


I've contacted Manning Publications and we are chasing down the issue. I should have an update by next week. Thank you for your patience!
559007 wrote:I get the following message when attempting to access MoreLunches.com:

Warning! Domain mapping upgrade for this domain not found. ...


Unfortunately, I don't own the domain. However, I will look and ask about this issue, and report back what I find out!
I have uploaded a new PDF of lab answers. Please find it at:

http://tech.rickumali.com/learngit/

This new version contains answers for Chapter 14. Thank you all for your patience!
593445 wrote:What about Chapter 14 onwards for Lab answers?


Sorry for my delay in responding! The short answer: yes, I can continue working on my overdue answer guide. I have neglected the lab answers document for six months, so I appreciate your request! I'll announce an updated answers document in a new forum topic as I've done before.
My answers:

1. Yes, you're correct! I should have removed this "--" from the book. The few times the "--" is printed is because it is a part of the output of standard Git commands like 'git status', but I admit leaving it in the sections that you list.

The appearance of "--" in the Git output messages is why I call it out in the answer guide. Git commands have many different forms, and using "--" is one of them. The answer guide (and specifically that Stack Overflow link) offers the details behind this rational. The goal of this exercise is to recognize that there are different ways to call a Git command.

2. Yes, you can use "git checkout math.sh" (without double dashes) instead of "git checkout -- math.sh". Keep this in mind as you explore Chapter 8, when we use 'git checkout' without "--". Same command, different form! The Stack Overflow link references "Argument Disambiguation" from the 'git checkout' help. Check it out for more details.
This git diff format is called 'the patch format', and it's described here:

https://git-scm.com/docs/diff-format/2.0.0#_generating_patches_with_p

In the case of deleting files, git diff will emit its usual headers, and in the index row (the index is the old name for the "staging area") it announces that the file pointed to by SHA1 ID e69de29 was turned into '0000000', which is Git's way of saying "non-existent".

(This '0000000' is used in the case of creating new files, but viewing the 0s is trickier: skip ahead to section 15.1.3 (listing 15.6) to see a brief discussion.)

My book shows how to use git show on any Git SHA1 ID in Section 15.3.2, but I don't cover the case of deleting files. If you type git show e69de29, you'll see your file's contents.
Hi MrJobs!

Yes, your description of the "@@" line looks accurate. I'm no expert on the hunk format, and when I considered your question, I found myself looking carefully at these resources:

1 https://www.gnu.org/software/diffutils/manual/html_node/Detailed-Unified.html
2 https://www.artima.com/weblogs/viewpost.jsp?thread=164293

Check these out. The second link is written by the author of Python!
I have uploaded a new PDF of lab answers. Please find it at:

http://tech.rickumali.com/learngit/

This new version contains answers for Chapter 13.
455933 wrote:
Will the answer for chapters 13 onwards come at some point?


The short answer: yes! I have neglected the lab answers document (for a year and a half!). I appreciate your gentle prod! I'll announce an updated answers document in a new forum topic as I've done before.
Thank you for posting this issue to the forums. I recommend two things: 1) try downloading from the book's webste, which is now:

https://www.manning.com/books/learn-git-in-a-month-of-lunches

The link is labeled "Source Code". I was able to download the code even without logging in.

2) If you're trying to download it from your account page, after logging into your account page, please contact support@manning.com. They will be able to straighten it out after looking at it.

Thank you again!
Thank you for commenting to this post. The answer guide has not been updated since June 2016, and it is missing answers for Chapters 13 onwards. However, it does contain answers for Chapters 4 and 5. I've attached this PDF to this reply, just in case the version on my website still links to an older PDF.
Hi! Thanks for posting your question to the forums.

The make_lots_of_commits.sh script is inside a ZIP file named LearnGitMoL_SourceCode.zip. This ZIP file can be downloaded from the book's web page at:

https://www.manning.com/books/learn-git-in-a-month-of-lunches

The link to this ZIP file on the above page is 'Source Code'.

Let me know if this helps, or if you have any difficulties.
I published a new video supplement, for section 7.4.4 ("Committing parts of changes using 'git add -p'").

The YouTube URL is:

https://www.youtube.com/watch?v=s1jrVfWtQw0

Please leave a comment here or on YouTube.
I created my first video supplement, for section 7.4.3 ("Committing parts of a file by using Git GUI").

The YouTube URL is:

https://www.youtube.com/watch?v=br-trnCnGwc

Please leave a comment here or on YouTube.
I created my first video supplement, for section 7.4.3 ("Committing parts of a file by using Git GUI"). I have a few more supplements in queue now. Look for these announcements in the separate forum posts.

The YouTube URL is:

https://www.youtube.com/watch?v=br-trnCnGwc


Hello! I'm the author, and I wanted to thank you for posting here on the forums.

214736 wrote: Second paragraph on page 31 of PDF states "I also have some videos on MoreLunches.com that demonstrate some of these techniques." As of 2017-March-20, no such videos can be found ...


This is entirely my fault. I never provided videos to the publisher. Given your interest, I'll spin up a quick video that shows off the techniques described in the section. I'll post the link here, and in a separate forum post, and on MoreLunches. This oversight should have been mentioned in the errata, but I hope to correct it within the week. Thank you for your patience!
Thank you for letting me know your versions! I neglected to try the script on my Windows Git. I ran make_mv_files.sh, and it produced the correct listing. However, my version was 2.8.0.windows.1, which is quite dated. I upgraded to 2.11.0.windows.3, and reran the script. Lo and behold, I encountered the same issue as you did!

What were your results on Linux Mint? I see from your reply that your Linux is version 1.9.1, which should mean that you won't see the error there.

I feel that this is a regression of some kind, but a mild one (albeit confusing). I rely on the touch command to quickly make files, but it does expose users to the corner case that two empty files are really the same object in Git's eyes. I'm glad you noted that just having content in these files allows you to generate the correct listing. I'll update the errata to alert other readers to this issue.

Thank you for commenting!
Hello! Thank you for commenting about the book on the forums.

I reviewed listing 7.6 and tried to recreate it. One of the difficulties is that the example builds from the previous chapter. To make the listing easier to reproduce, I isolated it into its own example in the attached BASH script that you can examine and run on your environment. It will create a directory list76 that will make a repo whose git status matches listing 7.6.

It should make no difference whether the file contains text or whether the file is empty. The git mv command works the same in either case. In our example, both c and d are empty, but Git knows which one is renamed to what file.

Run the script, and take note of the output. Go into the created "list76" directory, and then do git status, and then "git ls-tree --long HEAD". The output will be:

% git status
On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

        renamed:    d -> another_rename
        renamed:    c -> renamed_file

% git ls-tree --long HEAD
100644 blob e69de29bb2d1d6434b8b29ae775ad8c2e48c5391       0    c
100644 blob e69de29bb2d1d6434b8b29ae775ad8c2e48c5391       0    d


The ls-tree output is most interesting. You're right that c and d are empty, so they have the same contents (the e69de2 'blob'), but when you commit the renames match up properly. To test this, try git commit.

I avoided talking about the internals in this case, but Pro Git has a good chapter on it at:

https://git-scm.com/book/en/v2/Git-Internals-Git-Objects

Let me know if this helps or is confusing. Ultimately, your environment should match listing 7.6, despite the fact that we're renaming empty files.

Finally: it _is_ possible that things could have changed in Git. I ran my test with Git 2.5. Let me know what version you're at.

Thank you!
Hi IamHammer,

As for your question about making Git recognize the rename, you will need to indicate as such with 'git mv OLD NEW' (or use 'git rm OLD' on the file that has been removed, and 'git add NEW' on the new file). This is all broken down in 7.2 of the book.

However, in the original session, we rename a file that we added to the index but never committed! Below is a new session that sets up our situation.

I'll have more to say afterwards.

% mkdir bigger_file
% cd bigger_file
% git init
Initialized empty Git repository in /Users/rumali/gitbook/bigger_file/.git/
% cp ../lorem-ipsum.txt .
% git add lorem-ipsum.txt
% git commit -m "Adding lorem-ipsum.txt from source directory"
[master (root-commit) 1103fb1] Adding lorem-ipsum.txt from source directory
 1 file changed, 36 insertions(+)
 create mode 100644 lorem-ipsum.txt
% cp ../lorem-ipsum-change.txt .
% git add lorem-ipsum-change.txt
% mv lorem-ipsum-change.txt lorem-ipsum.txt
overwrite lorem-ipsum.txt? (y/n [n]) y
% git diff
diff --git a/lorem-ipsum-change.txt b/lorem-ipsum-change.txt
deleted file mode 100644
index b3ee228..0000000
--- a/lorem-ipsum-change.txt
+++ /dev/null
@@ -1,36 +0,0 @@
-Lorem ipsum dolor sit amet, consectetur adipiscing elit. Nunc facilisis
-venenatis felis, scelerisque consectetur lacus viverra in. Phasellus
-scelerisque pretium nibh, ac porttitor massa vestibulum non. Aenean ornare
-convallis enim, et change here. Proin blandit dui vitae quam
-fermentum, non lacinia lectus molestie. Vivamus tempus viverra dui. Cras in
-luctus felis. Pellentesque dictum tortor ipsum, id iaculis felis ultrices ut.
-Nunc id velit dignissim, suscipit est ac, euismod libero. Phasellus fringilla,
-nibh sit amet consectetur auctor, lorem magna euismod ante, tempor lobortis mi
-mi sagittis odio. Donec fermentum sem vel neque pulvinar eleifend.
-
-Nullam posuere condimentum rutrum. Vivamus vitae elit a tellus interdum
-accumsan. Duis pretium viverra condimentum. Curabitur dapibus aliquet semper.
-Aliquam pretium nunc deleted below molestie. Suspendisse potenti. In a
-fringilla.
-
-Cras non odio gravida, blandit risus sed, tempor lectus. Donec vel congue
-mauris. Donec ultrices malesuada dictum. Suspendisse molestie pulvinar quam eu
-dignissim. Aliquam eget faucibus neque. Phasellus at nibh dapibus urna
% git status
On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

	new file:   lorem-ipsum-change.txt

Changes not staged for commit:
  (use "git add/rm <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

	deleted:    lorem-ipsum-change.txt
	modified:   lorem-ipsum.txt

% ls
lorem-ipsum.txt


git status at this point says you have a new file (lorem-ipsum-change.txt) which we added to the index but have not yet committed. It also says it detected a deletion of this same file, and the modification of the original file.

Here's the rest of the session in which I try to follow the suggestions from git status:

% git status
On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

	new file:   lorem-ipsum-change.txt

Changes not staged for commit:
  (use "git add/rm <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

	deleted:    lorem-ipsum-change.txt
	modified:   lorem-ipsum.txt

% ls
lorem-ipsum.txt
% git add lorem-ipsum-change.txt
% git status
On branch master
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

	modified:   lorem-ipsum.txt

no changes added to commit (use "git add" and/or "git commit -a")
% git add lorem-ipsum.txt
% git status
On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

	modified:   lorem-ipsum.txt


This last status is satisfying to me. When I did 'git add lorem-ipsum-change.txt' in the above session, Git knew that the file was removed. (You could have also used 'git rm lorem-ipsum-change.txt'.) Git forgets about this file, but it saw that lorem-ipsum.txt (an existing file) was modified. Git only records "the final state of things."

I experimented with committing lorem-ipsum-change.txt after the add with 'git add lorem-ipsum-change.txt', to see if it would detect it as a rename.

% mkdir bigger_file
% cd bigger_file
% git init
Initialized empty Git repository in /Users/rumali/gitbook/bigger_file/.git/
% cp ../lorem-ipsum.txt .
% git add lorem-ipsum.txt
lorem-ipsum.txt
% git add lorem-ipsum.txt
% git commit -m "Adding lorem-ipsum.txt from source directory"
[master (root-commit) 016eb6d] Adding lorem-ipsum.txt from source directory
 1 file changed, 36 insertions(+)
 create mode 100644 lorem-ipsum.txt
% cp ../lorem-ipsum-change.txt .
% git add lorem-ipsum-change.txt
% git status
On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

	new file:   lorem-ipsum-change.txt

% git commit -m "Adding lorem-ipsum-change.txt"
[master 37b6e00] Adding lorem-ipsum-change.txt
 1 file changed, 36 insertions(+)
 create mode 100644 lorem-ipsum-change.txt
% mv lorem-ipsum-change.txt lorem-ipsum.txt
overwrite lorem-ipsum.txt? (y/n [n]) y
% git status
On branch master
Changes not staged for commit:
  (use "git add/rm <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

	deleted:    lorem-ipsum-change.txt
	modified:   lorem-ipsum.txt

no changes added to commit (use "git add" and/or "git commit -a")
% git rm lorem-ipsum-change.txt
rm 'lorem-ipsum-change.txt'
% git status
On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

	deleted:    lorem-ipsum-change.txt

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

	modified:   lorem-ipsum.txt

% git add lorem-ipsum.txt
% git status
On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

	deleted:    lorem-ipsum-change.txt
	modified:   lorem-ipsum.txt

% git commit -m "Dropping lorem-ipsum-change.txt on lorem-ipsum.txt"
[master 343781a] Dropping lorem-ipsum-change.txt on lorem-ipsum.txt
 2 files changed, 3 insertions(+), 39 deletions(-)
 delete mode 100644 lorem-ipsum-change.txt
% git log --stat -n 1
commit 343781a7211c41897f4abd11a7a5c5703e926f33
Author: Rick Umali <rumali@firstfuel.com>
Date:   Thu Sep 15 09:31:52 2016 -0400

    Dropping lorem-ipsum-change.txt on lorem-ipsum.txt

 lorem-ipsum-change.txt | 36 ------------------------------------
 lorem-ipsum.txt        |  6 +++---
 2 files changed, 3 insertions(+), 39 deletions(-)


This is less satisfying to me, but Git does record the final state of things: lorem-ipsum-change.txt was deleted, and lorem-ipsum.txt was modified. However, it doesn't record that this final state was generated by a rename. Below is a session in which I try to explicitly do a 'git mv'.

% mkdir bigger_file
% cd bigger_file
% git init
Initialized empty Git repository in /Users/rumali/gitbook/bigger_file/.git/
% cp ../lorem-ipsum.txt .
% git add lorem-ipsum.txt
% git commit -m "Adding lorem-ipsum.txt from source directory"
[master (root-commit) 3a385ea] Adding lorem-ipsum.txt from source directory
 1 file changed, 36 insertions(+)
 create mode 100644 lorem-ipsum.txt
% cp ../lorem-ipsum-change.txt .
% git add lorem-ipsum-change.txt
% git commit -m "Adding lorem-ipsum-change.txt"
[master 7b3c75e] Adding lorem-ipsum-change.txt
 1 file changed, 36 insertions(+)
 create mode 100644 lorem-ipsum-change.txt
% git mv lorem-ipsum-change.txt lorem-ipsum.txt
fatal: destination exists, source=lorem-ipsum-change.txt, destination=lorem-ipsum.txt


This last session makes me laugh, but hopefully you can accept it (like I have). Git seemingly will not rename a file into an existing committed file. I interpret this to mean that we can never record the final state as being generated from a rename, only as a delete and modify as in the previous sessions.

Sorry that this is so lengthy! Please let me know what you think!
Hi IamHammer,

Thank You for putting in all the details of your session. The log helped me spot the issue, and it was a case of unclear writing on my part.

In Step 4, you performed a 'git add', but I did not intend for readers to use 'git add'. However, I did write "and add it to the directory", which is not clear.

Try it again making the above change in Step 4. I've also put below my session to get the diff output from the answer guide.

I'll post another reply about the rename business.

% mkdir bigger_file
% cd bigger_file
% git init
Initialized empty Git repository in /Users/rumali/gitbook/bigger_file/.git/
% cp ../lorem-ipsum.txt .
% git add lorem-ipsum.txt
% git commit -m "Adding lorem-ipsum.txt from source directory"
[master (root-commit) 76a8cdb] Adding lorem-ipsum.txt from source directory
 1 file changed, 36 insertions(+)
 create mode 100644 lorem-ipsum.txt
% cp ../lorem-ipsum-change.txt .
% mv lorem-ipsum-change.txt lorem-ipsum.txt
overwrite lorem-ipsum.txt? (y/n [n]) y
% git status
On branch master
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

	modified:   lorem-ipsum.txt

no changes added to commit (use "git add" and/or "git commit -a")
% git diff
diff --git a/lorem-ipsum.txt b/lorem-ipsum.txt
index dd194e9..b3ee228 100644
--- a/lorem-ipsum.txt
+++ b/lorem-ipsum.txt
...
One more thought: the link you posted was for the LearnGit_SourceCode.zip. You can get this ZIP from the book page at:

https://www.manning.com/books/learn-git-in-a-month-of-lunches

Give that a try as well! (The link on the book page is different from the link you posted, so it may be better.)
Hi Brad,

For issues with downloading, especially from your account page, send an e-mail to support@manning.com. I have done so just now. Hopefully it will resolve itself shortly!

Thank you for your post!
Hi Riley,

Thanks for posting this question to the forums!

The answer guide PDF contains the answers for 6.4.1. This PDF is at:

http://tech.rickumali.com/learngit/

I'll have to work with Manning to get the PDF link on their website!

It was not my intention to have you wade through the entire body of Git documentation. The unstated goal was to access the help command for the respective commands in this section. For 6.4.1, type the following for the respective question:

1. git diff --help (then search for staged)
2. git add --help (then search for dry-run)
4. git log --help (then search for --oneline)
5. git commit --help (then search for -a)

Thank you for reading!
A new PDF has been uploaded to:

http://tech.rickumali.com/learngit

This version has all the questions for Chapter 12. I'm back at this, after a long break!

Thank you for reading!
I updated the learngit-answerhint.pdf to address these defects. Thank you again for posting!
I updated the learngit-answerhint.pdf to address these defects. Thank you again for posting!
Thanks for posting this, Graeme!

Your feedback on adding some text regarding git pull's --edit and --no-edit switches is valid. I'm glad you posted such detail in this forum post, as I believe future readers can benefit from it here.

Thank you again!
Thank you for posting this errata to the answer guide. I'll take a look and fix it, per what you described. Thank you again!
sample.tcl
[ 183 bytes ]
Thanks for posting that screen shot. I was able to figure out a workaround, but you definitely identified a change.

You are using Git version 2.X, and I am using Git version 1.9. Given this big difference, I downloaded a new version of Git for WIndows from https://git-for-windows.github.io/. I installed it, started 'Git Bash', and I was able to see the same issue you were seeing: the Console window did not appear at all!

As a workaround, you could enter the the contents of listing 5.1 into a file named sample.tcl. (I've attached this.) If you give wish this file as an argument, the UI will appear. My session with this workaround looked like this:

image

I dug around further, however, and found that if you invoke wish from a DOS CMD window and the "C:\Program Files\Git\mingw64\bin" directory (adjust to wherever you've installed Git for Windows), you will see the Console window. This session looked like this:

image

The difference between these two sessions is the Console. Git Bash uses mintty, and the DOS CMD window comes with Windows (and this is what was used in Git version 1.9).

Give these workarounds a try, and thanks for posting to the forums!
The picture below shows what Wish would look like when it is working. I wasn't clear that in Windows, the Console is separate from the window where you typed 'wish'. In the picture below, you would type listing 5.1 into this new Console window (marked with a red arrow, with the prompt '(Rick) 1 %').

I hope that clears things up. If you post a full screenshot (or send me one), I can try to help further! Good luck!

image
Thanks for this question! I'm glad you think it's intriguing to explore on-the-fly UIs with Wish. Wish (and Tcl/Tk) is an older technology, so it can be picky getting it to work. I'm looking at Ruby Shoes these days for UI stuff.

If possible, please send a screen shot of the failing command. I'm not near my Windows 7 machine, but I'll reply soon once I've had a chance to refresh my steps. Also: what version of Git (Windows) did you install?
Once again, I have fallen behind. Tonight, I uploaded a new answer PDF to:

http://tech.rickumali.com/learngit

This version has the answers for 12.4.1.
A new PDF has been uploaded to:

http://tech.rickumali.com/learngit

This version has all the questions for Chapter 11.
I've been away from this document for too long! A new PDF with just one new answer has been posted to:

http://tech.rickumali.com/learngit

This tackles the first question of Chapter 11.
Thanks for your note! Where you blogging about this? You can post a link here. I'll be happy to Tweet this out!
Hi Randy,

Thanks for your participation!

I have been behind in the answer key, that's for sure. I hope to update the document this week. In the meantime, please feel free to send questions into this forum.

As for your question, the exercise refers to section 14.5. In that section, the TRY IT NOW has you doing a git fetch, then a git diff HEAD FETCH_HEAD. However, the section does not walk you through the git merge, hence the exercise.

I believe completing this exercise will have you performing the steps of the "Conflicted merges" section (14.3.4).

I hope this helps!
In your post, is the example you provided something that you are seeing? If not, it would be helpful to see what you see, perhaps via copy/paste of what is in your Windows terminal/Git Bash, or a screen shot.

If the example you provided is what you're seeing, then that is all the information you're supposed to see. The hunk (the two lines following the '@@') contains what is different.

If instead you do not get any output when you type 'git diff', then chances are you haven't made a change you in your repository.

Let us know!
Sorry about that!

Try this URL:

http://tech.rickumali.com/learngit/?nocache=1850

If you see the new content, then chances are my web page is stuck behind some caching mechanism. (The "?nocache=1850" is one trick to my make web page reload from the server. Most browsers can also refresh a website directly from the server.)

To make sure you get the latest, I've attached to this post the updated PDF. I'm going to do this going forward, so that it's online here in the forums as well as on my website.
I have uploaded a new PDF of lab answers. Please find it at:

http://tech.rickumali.com/learngit/

This new version contains answers for Chapter 10.
Thanks for posting your screen.

I was able to reproduce your error, even getting the exact message as you did.

There are two issues here, from what I can see.

1) You're running into an old git gui bug. See:

http://stackoverflow.com/questions/12147930/fatal-corrupt-patch-at-line-xx-when-staging-single-line

The main issue from the above post is that your file must contain a newline at the end of the file before you can stage a single line. (Note that this is what we're doing on page 88 through 89. We're staging one line at a time.)

The comments suggest an even further nuance: you must git add and git commit this newer file before attempting to stage a single line. I didn't try this workaround, as it goes against what we're doing: we're staging one line at a time, but the workaround wants you to stage all the changes at once (via git add).

In the end, to short-circuit the error, select "Stage Hunk for Commit". This is the equivalent of staging all the lines at once (git add), but it will get you past the error.

2) The second issue is more subtle: the lines in your file don't look exactly like figure 7.19. Figure 7.19 is what your file should look like within git gui. From the screenshot, it seems as if you had added all the lines at once. I think making the lines look exactly like figure 7.19 will help you avoid the error. When I make my file match 7.19 (following the editing/commit session from section 6.2.4, and figure 7.12), I do not get the error.

How do you edit the file?

The goal of this section is to test out line-by-line staging via git gui, so if need be, try it out on a smaller file, so you can prove to yourself that this technique works properly.

I apologize that this is long and windy, but I hope it helps in some way!
Hello!

Thanks for posting your question here. Page 88 utilizes git gui to stage individual lines. By any chance does your file in git gui look like figure 7.16? If so, then there may be an end of line issue.

Either way, can you upload a screenshot of your file inside of git gui?

Thanks for this help.
I identified some errors.

On page 19, I wrote "open the Git GUI tool and select Create New Repository." This should be "open the Git GUI tool and select Clone Existing Repository."

On page 19, I wrote "Click in the Clone Existing Repository text box, and type the source URL..." This should be "In the dialog box, after pressing Clone Existing Repository, type the source URL...".

This was found per the discussion thread here:

https://forums.manning.com/posts/list/37284.page
jasonc wrote:Will these Errata be confirmed and compiled into a pdf we can print off?


Yes, we will be confirming and compiling these into a separate document (likely a web page). This is a work in progress, so please keep subscribed to this forum for updates.
Hi Gene,

I think I spotted an error in the book that may be contributing to the confusion. In the first text on p. 19, I wrote "open the Git GUI tool and select Create New Repository." However, in the next paragraph below the Windows Notes and Mac Notes, I wrote "Click in the Clone Existing Repository text box, and type the source URL..."

That first text should read "open the Git GUI tool and select Clone Existing Repository." The second text should be "In the dialog box, after pressing Clone Existing Repository, type the source URL...".

There's no need to create a new repository first, and if you had selected that, it could have resulted in the umali_3.png picture you attached.

The errors raised in umali_1.png and umali_2.png were both "fatal: bad config file line 1 in C:\Users\Owner/.gitconfig". This is a new error to me, but luckily for us it points to the offending file. Using Explorer, copy this file to another filename, and then delete it. This should enable you to get past that error.

After taking care of the .gitconfig error, select Clone Existing Repository, and for the "Target Directory" field, enter a random name that is not an existing directory. This should properly clone the repository from GitHub.

Please let us know how this works, and I will be entering this into the Errata thread.

Thank you, Gene!
I have uploaded a new PDF of lab answers. Please find it at:

http://tech.rickumali.com/learngit/

This new version contains answers for the last two exercise sections of Chapter 9 (9.5.3 and 9.5.4).
Hi Gene,

That is an interesting error!

As a quick work around for now, try the non-SSL URL to the repository:

http://github.com/rickumali/RickUmaliVanityWebsite

(The only difference is that the above URL uses http instead of https.)

I suspect that the non-SSL URL will work because the error message in your screen shot references "CAfile" and "CApath", which suggest an SSL issue.

Two questions that could help me dig into this further:

1) Does the SSL URL (https) work on the command line?

2) If you could repeat the 'git gui' error, scroll to the right so I can see the error message from git gui. (In the screen shot, it shows the message "fatal: unable to access 'https://github.com/rickumali/RickUmaliVanityWebsite/:", but I want to see what is to the right of this message.

Thank you!
I have uploaded a new PDF of lab answers. Please find it at:

http://tech.rickumali.com/learngit/

This new version contains answers for the first two sections of Chapter 9.
I have uploaded a new PDF of lab answers. Please find it at:

http://tech.rickumali.com/learngit/

This new version contains answers for Chapter 8. The exercises in this chapter were quite lengthy!
I have uploaded a new PDF of lab answers. Please find it at:

http://tech.rickumali.com/learngit/

This new version contains answers for Chapter 7. The exercise instructions were a little mangled, and I'm going to post an errata in the Errata thread.
I examined your error closely, and noticed the following:

image

In the highlighted image, the red box (pointed to by the red arrow) shows that your home directory is somehow a part of the clone URL! If I'm reading this correctly, you are typing the equivalent of:

git clone /Users/alejandro/Z/https:/github.com/rickumali/RickUmaliVanityWebsite.git

Your git clone window (figure 2.14 in the book) should be just the https part. Also, two slashes (//) follow the https, not one.

Git this a try again, making your git clone window look like figure 2.14 (substituting your directory of course).

Good luck with this, and thank you for trying out the exercise!
Maybe the first thing to do is to type "mkdir test" in the same directory from which you typed the git clone command.

I suggest this because that is what git clone is doing: it is trying to make a directory. In the error message, this directory is referenced as 'work tree dir RickUmaliVanityWebsite'. However, for whatever reason, it cannot make this directory, because permission is denied.

If the mkdir test worked, then try this:

git clone https://github.com/rickumali/RickUmaliVanityWebsite MyCopyRickSite

Notice the extra argument, MyCopyRickSite, at the end of the git clone command. This git clone will copy the repository into a directory named 'MyCopyRickSite', which it will attempt to create. However I suspect that this won't work, and that you may be in a directory which does not allow you to make other directories.

One directory that you should use is your $HOME directory. To get to your $HOME directory, type "cd $HOME" in git bash. Then try the git clone again! Something should work, since your git gui clone command worked!

Please let me know what you find out when do the above. Thank you for reading and trying out these exercises!
I have uploaded a new PDF of lab answers. Please find it at:

http://tech.rickumali.com/learngit/

This new version contains answers for Chapters 4 and 5. In total, the answer/hints PDF is complete from Chapter 1 through 6.
I have started the lab answers/hints document. A pointer to the PDF is at:

http://tech.rickumali.com/learngit/

Please leave feedback in either this post, or in a new post. This version contains answers for Chapters 3 and 6. I will work towards getting more chapters covered.

Thanks, everyone, for your interest!

Thanks so much for this post!

I'm embarrassed to say that the lab answers/hints are not available as of yet. Your post does prompt me to put this effort back on the front burner.

What chapter are you working on? I can start with that chapter, and build from there.

I'll post the URL to the lab answers in this thread, until I can coordinate with Manning to hang it off the book's web page.

Thank you again!
I've decided to write a short blog-type post every week here on this forum. These posts are exclusive to this forum, and they will primarily be about the writing of the book.

This past Monday evening, I saw two packages outside my door: a box, and a slim media mailer. After examining the label, I knew immediately what it was.

I opened the slim media mailer first, and I delicately pulled out three copies of my book. My first impression: I thought it should be thicker. But I convinced myself that all 352 pages were present, and later I compared its width to another book of a similar page count. They were roughly the same size. My second impression: it smells just like a new book!

That evening I showed the books to my wife and daughter, and I directed them to their sentence in the acknowledgements section. They were smiling. So was I. We joked back and forth, and I resumed the rest of my evening. I felt very satisfied.

This is the last one of the series, but next month or so I'll start to post some short Git-related articles as I mentioned in #37. Thank you all for indulging me these BLOG posts.

image
I've decided to write a short blog-type post every week here on this forum. These posts are exclusive to this forum, and they will primarily be about the writing of the book.

A tweet yesterday announced that the book was in print.

image

We're definitely down to the last few Book BLOG posts now. I hope to post a few pictures of this book in my hands once I receive a copy.

I've been fielding more questions about the book from co-workers and people who meet me when I'm out at meetups.

I always have to break past that bit of awkwardness when talking about the book. It's easier to talk about Git, versus talking about writing about Git. It's something I'll have to get used to however.

Thank you, everyone, for reading. See everyone next week!
I've decided to write a short blog-type post every week here on this forum. These posts are exclusive to this forum, and they will primarily be about the writing of the book.

The book is at the printers. Now I know the work is really over!

I learned from Mary Piergies that the printers are Edwards Brothers Malloy in Ann Arbor, Michigan. Unfortunately, I don't live close to there, or else I would have done one of those vanity tours to see the printers putting my book together.

To learn more about the printers, check this video out:

https://www.youtube.com/watch?v=tKd_08jGV0U

Earlier in the week I received an e-mail saying that the final PDF of the book is now available. A tweet soon followed. That's pretty exciting! I know the reality will really hit me when I have the book in my hand.

There won't be a BLOG post next week, so I'll see everyone next time! Thanks everyone, for reading!
I've decided to write a short blog-type post every week here on this forum. These posts are exclusive to this forum, and they will primarily be about the writing of the book.

In BLOG #26, I showed a few graphs of how the writing was going.

Today, with the production editors saying "we're going to press", here's a graph of all the commits to my book's Git repository (courtesy of my local installation of GitLab).

image

It's fascinating to see the activity spikes between the start of the project, all the way through April 2015. The commits then start to wane until this month, August 2015. To be fair, a lot of the activity was done outside of Git. All of the corrections and the reviews were done on files not managed in Git, so the only commits are those from my notes.

The book indeed goes to press, probably by early September. The end is near!

Thanks, everyone, for reading!
I've decided to write a short blog-type post every week here on this forum. These posts are exclusive to this forum, and they will primarily be about the writing of the book.

Janet Vail, who is overseeing the production of this book, sent me this note about the final page count.
Chapter 20 currently ends on page 344. The front matter will add about 20 pages, and the index will add another 8 to 10 pages for a final estimated page count of 368 or 376. (The final page count must be divisible by 8 for printing.)
I spent a few minutes pondering that parenthetical. The page count must be divisible by 8. Why?

I spent a good amount of time pondering the printing process when I worked on a student magazine in college. A lot of that started coming back with her e-mail.

The pages in a magazine or a book are printed on a large sheet of paper called a signature. There are 8 or 16 book pages on this large sheet of paper. After folding and cutting, this signature forms a block of 16 or 32 pages.

I found a great picture and explanation of the concepts here:

http://www.designersinsights.com/designer-resources/understanding-and-working-with-print

The 8 page imposition is shown below. The imposition is the placement and direction of pages, such that when folded and cut the pages are in the correct order. The website also shows that larger signatures are possible.

image

I thought two things: 1) printing software to properly layout signatures would be challenging, and 2) the book is very nearly done!

Thanks for reading everyone!
I've decided to write a short blog-type post every week here on this forum. These posts are exclusive to this forum, and they will primarily be about the writing of the book.

As I predicted in BLOG #51, I spent the past week going through corrections. The PDFs are now considered 'page proofs', and I went over captions, figures, indentations, line breaks and annotations. I could trust the text, but the layout could have jarred some elements from their intended positions.

Corrections are done right to the PDF (unless I wanted to submit an indexed list of corrections). I was surprised to learn that the standard Adobe Reader supports a basic highlight and comment facility. I could select words to highlight, and attach a comment to the highlight, enabling me to call out corrections (abbreviated as crx). (See picture below.) Clicking on the "Comment" button (upper-right of the picture) lists all the corrections.

I believe there's one or two more rounds of this. The books feels more real than ever. Soon I'll be dusting off a draft of my "front matter", which includes my acknowledgements, and the book will be very near the finish line.

Thank you, everyone, for reading!

image
Hello again!

The reason I used git gui and gitk is because they are part of the core Git distribution. These tools run on all platforms the same way, and their source code is available as part of git-core. This is not the case with the other tools out there.

I mention this rationale as well in Chapter 05. That said, the book does explore Atlassian's SourceTree and Git within Eclipse in Chapter 19.

Good luck and thanks for your follow-up!
Thanks for taking a look at the book, and for posting your question.

My book says to download a Windows version of Git from this specific URL:

http://msysgit.github.io/

GitHub offers a GUI product called Git for Windows, from this URL:

https://windows.github.com/

Both let you use Git, but the book makes use of the software specific to the first URL. You can install both, but my book does not document how to use Git for Windows from GitHub. If you want to make use of the book, you will need to install the software from the first link URL.

msysgit is the name of another software package that allows you to compile the Git source code, which the book doesn't cover. msysgit is a separate download package, available as a link on that first URL, but it is something that you don't need.

What's confusing, I suspect, is that the URL has the word 'msysgit' in it, implying that you need this software. I may change the book to use this URL:

http://git-scm.com/download/win

This URL points to msysgit, behind the scenes.
I've decided to write a short blog-type post every week here on this forum. These posts are exclusive to this forum, and they will primarily be about the writing of the book.

One of the documents I received earlier in the month is the full list of people who participated in the reviewing of the manuscript. At Manning, people can sign up to be technical reviewers, and this effort completely voluntary. If you remember, this is how I started down the path of writing this book!

The reviewers for this book will go into the acknowledgements section of the book, but let me acknowledge these 19 reviewers in this space. Their comments, by way of a questionnaire and open feedback, were typically anonymized, so this was my first time to see their names.

Art Bergquist
Boris Vasile
Changgeng Li
Ernesto Cardenas Cangahuala
Harinath Mallepally
Kathleen Estrada
Keith Webster
Luciano Favaro
Michel Graciano
Miguel Biraud
Mohsen Mostafa Jokar
Nacho Ormeño
Nitin Gode
Patrick Dennis
Ralph Leibmann
Richard Butler
Scott King
Stuart Ellis
Travis Nelson

I looked at each questionnaire and comment during the three review periods while writing the book. I tried to take something constructive from every piece of feedback. Many times this resulted in updates to the manuscript, and for that I appreciate it. Thank you, you reviewers!

There won't be a BLOG next week, as I will be away. Thanks for reading, and I'll see everyone next time!
I've decided to write a short blog-type post every week here on this forum. These posts are exclusive to this forum, and they will primarily be about the writing of the book.

The book has returned from the layout process, and it looks really good! Check out some the pictures below (from Chapters 1 and 2).

The output from the layout process was PDF files, and I used a the venerable PDFtk program to count all the pages as a first pass. There are 379 pages, including 15 pages for the index.

I am sure the next task will be for me to review all of these. I'm up for it. It means the project is getting closer to the end.

Thanks everyone for reading!

image

image
Thanks for this comment! The book is near its final stages, so I may not be able to cite this reference. However, I did look for posh-git, and I see it at:

https://github.com/dahlbyk/posh-git

This seems like a good solution for users working in Windows PowerShell. Thanks for contributing!
I've decided to write a short blog-type post every week here on this forum. These posts are exclusive to this forum, and they will primarily be about the writing of the book.

As the book progresses towards the finish line (it's in layout now), I find myself thinking back on some of the sparks that led to the way I wrote.

The book was born from presentations I have given about Git. In those talks, I always felt that if I could focus for a half-hour or an hour on each Git concept, I could really make Git clear for beginners. That would lead to a 10 or 20 hour seminar, and maybe that's an idea to pursue, but I went in the book direction first.

The idea of closely focusing on something is examined in Zen and the Art of Motorcycle Maintenance (Robert Pirsig, 1974). There's a section where a student is having trouble coming up with what to write, and the teacher tells her that she wasn't looking hard enough. "Narrow it down to the front of one building ... Start with the upper-left hand brick."

I always liked that part of the book. "The more you look, the more you see." That's what I'm aiming for. Each chapter is one close look at one key part of Git. The closer we look, the more we see and learn, and this applies to any kind of tech.

This book is aimed at beginners, and I hope that beginners grow with the book. There's a lot material in each chapter to digest, and I hope readers use it as a springboard for deeper dives into each part.

Thanks for reading, everyone! Once again, there won't be a BLOG post next week as I will be away. Stay cool!
I've decided to write a short blog-type post every week here on this forum. These posts are exclusive to this forum, and they will primarily be about the writing of the book.

The indexer submitted the last chapter a few days ago. I anticipate the next phase of the production process to start next week. The anticipated July release will likely be missed, but progress has been steady, so I'm not too worried.

The indexer used the standard Microsoft Word indexing capabilities, but when I opened the files that they've submitted, it wasn't readily apparent how to see the indexed items.

Fumbling around, I observed that the "Show Paragraph Marks" toggle will reveal the "index entries" (marked with an XE) in the text.

image

Once I reread the MS Word help, I saw the contents of each chapter's index by inserting the index at the end. (In the picture below, the index is highlighted in gray.)

image

If I wrote the manuscript using something other than MS Word, I'd have to handle the indexing by myself, so I'm glad for their help!

Thanks everyone for reading. There won't be a BLOG next week, due to Independence Day (US Holiday). See everyone next time.
I've decided to write a short blog-type post every week here on this forum. These posts are exclusive to this forum, and they will primarily be about the writing of the book.

The days between book work have grown longer and longer. As I type this, it's been 11 days since my last commit, and 18 days since the last time I uploaded a chapter to the production team.

(To get a feeling for the pace, check out the dates in the screen shot below. Each update is when the chapter was submitted to the copy editor.)

The book has begun to feel done, but I caution myself to not get too giddy: there's still one or two last mad rushes with the proofreader and the layout people. Once this kicks up, I'll have to be active and alert again, but until then it is "hurry up and wait."

One of things I wonder about is whether this long break is normal. I suppose that is why I'm writing all this down: so I can remember for the next book project! Until then, thanks everyone, for reading.

image
I've decided to write a short blog-type post every week here on this forum. These posts are exclusive to this forum, and they will primarily be about the writing of the book.

People who program in PHP may be quite familiar with Larry Ullman. He's a many-times published author who specialized in PHP back when it was still fresh. His early books catered towards beginners, and as a result he has a wide audience.

I heard him give a talk for the Boston PHP users group in 2012. He spoke about being an independent web developer, and how this work helped him with his writing. A year later he announced on his mailing list that he joined Stripe's support department, helping their users.

I sent an e-mail to Larry through his website. I told him I was writing a book and he asked me how that was going, and warmly wished me well. I replied and told him how arduous the editing process was, and he wrote back, saying he appreciated the note, and that he agreed with how I felt.

His brief reply was something I savored for months as my book progressed towards production. A note of understanding, from someone who's been through it multiple times. It meant a lot, and I appreciated his generosity. Thanks, Larry!

Thanks, everyone, for reading!
I've decided to write a short blog-type post every week here on this forum. These posts are exclusive to this forum, and they will primarily be about the writing of the book.

Last week, I reviewed the copy editor's pass of Chapter 20 and I posted my revisions to it. I'm done, right? No. There's actually a good deal of work left.

I'm waiting for the last few chapters to have their figures redrawn. Each changed figure requires me to eye-ball it, to see if it still fits the original intention.

As I did this for the last batch of figures, I realized that some of my text had to change, but I won't be able to change my text until the proofreading stage. After that comes a layout stage (something I had been wondering about).

I plan to write this BLOG until all of this production stuff is finished. I'm no longer doing heavy lifting, but I'm still in the weight room, nonetheless.

Thanks everyone, for reading!

P.S. Below is a peek at the 20 chapters, sitting inside the production folders.

image
I've decided to write a short blog-type post every week here on this forum. These posts are exclusive to this forum, and they will primarily be about the writing of the book.

I'm near the finish of the copy editing phase of the manuscript. The copy editor, Sharon Wilkey, has been carefully changing the voice (we to you) and touching up many typos and small mistakes.

She has found through careful reading some unclear areas, as well as some figures that need to be renumbered. Fresh eyes help here! It's hard for my own eyes to spot issues. The screen shot below shows a typical set of changes.

image

The above is from Chapter 15. Sometime this weekend, I'll submit the 19th chapter back to her. There's one more chapter after that! The finish line is very close.

Thank You for reading!
I've decided to write a short blog-type post every week here on this forum. These posts are exclusive to this forum, and they will primarily be about the writing of the book.

Many of the diagrams that I drew (using Google Draw) are slowly being replaced by professional line art, created by an illustrator from Manning. Below is a preview (in the book, it's figure 7.23).

image

I like the new art. It's another sign that the book is nearing the finish line.

I have looked at copy edits for ten chapters so far. Ten more to go, and things will really start to feel done.

Thanks everyone for reading and checking in. There won't be a post next week, due to the US holiday Memorial Day. The next time I write, I hope to report that I'm finished with the copy edits!
I've decided to write a short blog-type post every week here on this forum. These posts are exclusive to this forum, and they will primarily be about the writing of the book.

The copy editing process has started. I haven't looked at my manuscript in almost two weeks, but this afternoon I was reintroduced to it in the form of copy edits.

Here's a picture showing the number of edits in the first three chapters.

image

Each insert or deletion is a red mark in Microsoft Word, and so each page looks like it has dozens of little paper cuts.

I have to look at each correction and if I have a problem or a concern, I have to raise it as a comment. The copyeditor also has comments that I have to respond to. This is not too bad, despite what looks like a large number of changes. Many of the edits are capitalization, adding contractions, and changes for voice. I do admit the changes put a higher polish on what I'm trying to say.

This kind of detailed work will keep me busy for another month or so!

There won't be a post next week (Mother's Day), so thank you all in advance for reading. We're nearly there!
I've decided to write a short blog-type post every week here on this forum. These posts are exclusive to this forum, and they will primarily be about the writing of the book.

Earlier in the year, I wrote about a simple script to rename the raw picture files into the correctly named files expected by the publisher. That script is now much more complex. Instead of a single BASH script single-handedly renaming files, it is now a Ruby script that reads a master list of figures.

The program evolved because as the book progressed, I began moving pictures into different places. This required manually renumbering the figures in the script itself. I realized that the script could handle the numbering of the pictures. The Ruby program that I wrote reads a master list of figures. Whenever there is a new chapter, I insert a line with a two-digit number signifying this.

The master file looks like this:
# This is used by work_figures.rb
# This is the master list of figures in the gitbook
# Use work_figures to get the figure_map.csv file
01
single_point_of_contention
distributed
02
vc-personal
vc-personal-with-saves
vc-org

In the example, 01 and 02 represent the start of chapters 1 and 2. Whenever I move the figures around, I don't have to calculate the number. I just move the picture to the right spot, and ask the program to renumber the list. In the above listing, single_point_of_contention is renamed to 01_01.png. The program not only renumbers the files, it generates a CSV file that maps the figure to the correct figure number, and it copies the correctly named figures into a directory that I can compress and send to the publisher.

For people who want to try this out, the program is on a GitHub gist:

https://gist.github.com/rickumali/bad0be8fad81e03ae207

Check it out! Thank You for reading!
I've decided to write a short blog-type post every week here on this forum. These posts are exclusive to this forum, and they will primarily be about the writing of the book.

I worked with three development editors for this project: Supriya Savkoor, Sean Dennis, and Helen Stergius (four if I count Susie Pizen, who covered for Supriya on vacation). Development editors are charged with the broad charter of developing the manuscript. This encompasses everything from finding grammar issues to rearranging the chapter orders.

DEs became my touch-point into Manning. I had the most interaction with them, both e-mail and voice (via Skype). DEs became keepers of the schedule and made sure I was staying on track. DEs helped me reach out to other parts of Manning as needed.

The revisions from the DE were tactical and strategic. As I progressed through the project, I learned that DEs ultimately represented the reader. Each DE that I worked with had questions that were invariably framed with the reader in mind.

Though none of the DEs were experienced with Git, their questions helped shape the book in significant ways. I wrote every word of the book, but every editor I worked with affected those words.

Helen got the book into production, and that merits an extra acknowledgement for sure. It's a shared accomplishment to get to this stage. Thanks Helen!

And Thank You for reading!
I've decided to write a short blog-type post every week here on this forum. These posts are exclusive to this forum, and they will primarily be about the writing of the book.

The editing process for this book was a familiar one to me. In high school and college, I was a writer for various school publications. As I've written before, I've had manuscripts and articles marked up by the editing process.

The clearest editing moment came in college. I was the editor-in-chief of a college magazine. This position gave me the opportunity to write a "From the Editor's Desk" column every few months (we only printed four to six issues a school year).

For one issue, I wrote a scathing rant disparaging the school. I was simply venting. My editor at the time, Corrie Bates, gently called me out. To paraphrase, she asked "What are you trying to say?"

The question snapped me from my diatribe, and I'm sure we ran something more appropriate. However, I kept that marked up column for the longest time. Editors can save writers from looking foolish.

What are you trying to say is a question that editors need to keep in front of the writer. And for writers, it's not just a question about the current sentence, but rather about the whole paragraph, chapter or book.

Thanks, everyone, for reading this!
I've decided to write a short blog-type post every week here on this forum. These posts are exclusive to this forum, and they will primarily be about the writing of the book.

As a Manning author, a number of people were assigned to help me with the manuscript. One of them was Jonathan Thoms. He was the assigned technical development editor, or TDE.

I only interacted with Jonathan via the development editor (or DE), so I never spoke or exchanged e-mail with him. However, Jonathan has definitely interacted with me by way of his technical comments. As a TDE, he read through the book for technical concerns and issues. He also went through most of the TRY IT NOW sections, and looked at the exercises.

What I most especially enjoyed were his friendly comments at the start of each chapter. Jonathan was very encouraging, and encouragement is a necessary fuel for a writer. He did call out issues and each time he did so, I gave his notes its due attention. Some of his notes were minor changes, but some of them called for restructuring of whole chapters.

He has contributed immensely to this book, and I do publicly thank him, here on this BLOG, and in the (soon to be printed) acknowledgements.

Thank You for reading, everyone!
I've decided to write a short blog-type post every week here on this forum. These posts are exclusive to this forum, and they will primarily be about the writing of the book.

I obtained the gitmol.com domain, and I created a GitHub account at http://github.com/gitmol. Hopefully I'll have the source code of the scripts in the ZIP file up on that GitHub. I also plan to have other scripts such as the ones I used to check the exercises.

In one more week, the book will be in production, which promises new experiences for me in the book authoring process. When I think of all the stuff that comes with putting a book together, writing seems to be easiest part of it!

Once again, another short entry, because I have to keep my nose to the grindstone.

Thanks for reading, everybody!
I've decided to write a short blog-type post every week here on this forum. These posts are exclusive to this forum, and they will primarily be about the writing of the book.

The work is nearly over. The book is going to go into production at the end of the month, so I have to start thinking about ending this little BLOG. I have enjoyed posting about the book-writing/authoring process here.

I'm in the midst of the last dash of edits from the last external review. I'm also bracing myself for the inevitable requests to update my diagrams and screenshots. Remember my post on tedium? It's more of the same.

Readers should still have a place to visit, so I am going to post a short Git article in this same space every three or four weeks. I have my share of leftover Git topics that I hope I can spin out when the book is finally out.

This is a short entry, because I'm still in the thick of things! I'll have more next week and beyond, until the book gets into production. I'll keep you posted.

Thanks for reading, everyone!
I've decided to write a short blog-type post every week here on this forum. These posts are exclusive to this forum, and they will primarily be about the writing of the book.

The book is getting down to the wire. One of the details to keep on top of is figure renumbering. Whenever I add a new figure, I have to renumber not just the figure's file (which I've already discussed), but the figure's caption in the book.

Microsoft Word makes this a somewhat easier task because it allows me to search by font. In MS Word, if you access the context menu (right mouse button click) any selected text, Word can display the font properties.

In the figure below, I've selected the string "Figure", and Word says the font is Arial, and the size is 8-point.

image

To search by font, you need to use Advanced Find. In the figure below, I just typed CTRL-F, but you can access this from a menu as well.

image

In the dialog window that apears (see below), I enter the string "Figure". Then I click on the button labeled "More".

image

Clicking on "More" presents other ways to search for text. All the way at the bottom is a button labeled "Format". Click on that.

image

The "Format" button presents another menu. It shows the different kinds of Formatting that you can search on. Click on "Font".

image

The Font dialog window lets you specify what font characteristics you want to find. Below, I've entered Arial, 8-point, and Regular.

image

Now MS Word will find all the times I've entered Figure with an Arial, 8-point font. Below, I clicked on the menu "Reading Highlight", and the menu item "Highlight All". MS Word then highlights all of these instances.

image

Using the MS Word scrollbar below, I can click on the blue arrows, allowing me to navigate quickly to the next instance of the word "Figure" in Arial, 8-point font.

image

This technique beats doing a search by hand, or by scrolling manually!

Thank You for reading!
I've decided to write a short blog-type post every week here on this forum. These posts are exclusive to this forum, and they will primarily be about the writing of the book.

One of the things that has made the writing easy is that the interface to Git has remained consistent. Since its release, Git's core commands (git init, git add, git commit, git status, git log, git push, git fetch, and git merge) have always meant the same thing.

Switches have been added, and the underlying details have changed, but for the most part these commands work the same across the major versions of Git. What this means for me and you is that the contents of this book should remain current for years to come.

One area that has had a bit of churn recently is Git hosting. In chapters 12 and 18, I make brief mention of gitorious.org, a website that hosts Git repositories. Just this week (March 3, 2015), GitLab announced that it was acquiring Gitorious, and shutting down the gitorious.org hosting.

This means, of course, changing the content a bit of 12 and 18. The book's website will probably have links to errata and updates, but I hope Git's core commands and how they're used will withstand the test of time.

Thanks, everybody, for reading!
I've decided to write a short blog-type post every week here on this forum. These posts are exclusive to this forum, and they will primarily be about the writing of the book.

Ben Melançon is one of the main authors of the "The Definitive Guide to Drupal 7". This is one of those classic 'big computer books'. It is more than 1100 pages. Over ten writers contributed whole chapters to this book. It covers a wide variety of topics suitable for beginner to intermediate to even advanced users of Drupal, the very popular CMS.

In the book, Ben encourages readers to embrace Git, and to commit often. His style is informal, and I enjoyed reading the chapters that he wrote and contributed to. I first met him at a local Drupal meet-up, and we cross paths every once and again at various Drupal conferences.

He helped connect me to the people who were considering doing a similar book for Drupal 8, and it planted the idea that I could make a contribution by writing. He offered to help technically review an earlier book project. His easy-going manner and his willingness to make connections stayed with me.

Thanks, everyone, for reading!
I've decided to write a short blog-type post every week here on this forum. These posts are exclusive to this forum, and they will primarily be about the writing of the book.

A little more than a year has passed since the start of this project. I joked with my editor that I have been at this "for 389 days, but who's counting?" But it turns out that I am counting.

I submitted the proposal for this book in February 7, 2014, after starting it on January 24, 2014, which was a few days after chatting with Mike Stephens. Since early March, when I started in earnest, I have worked practically every evening. There have been two breaks (family vacation, and a conference), but aside from that, it's been a daily part of my evening routine.

In status e-mails with the publisher, I see two columns of dates: the ones denoted in the contract, and the revised dates. I'm grateful for every extension, especially since the contract stated the book was due a month ago. Now I'm on track to finish by the end of March. By then I'll have been at it for over 400 days, but who's counting?

Thank You for reading!
I've decided to write a short blog-type post every week here on this forum. These posts are exclusive to this forum, and they will primarily be about the writing of the book.

One of the recent changes to the book has been to limit the exposure of Git's default editor, vi.

Feedback from the recent second external review (2P) suggested that vi in chapter 4 "detracts from the topic" of making Git commit messages. I gave it some thought, and decided the feedback was appropriate. The goal of chapter 4 is to introduce Git basics. The reader would be absorbing a lot of new ideas in this chapter, and adding vi to that was a burden that could easily be avoided (using the -m switch to git commit).

I couldn't avoid the vi editor in the chapters on git pull and git rebase, but in those later chapters I can point readers to chapter 20, which shows how to change Git's default editor (with git config). I advise readers to skip ahead to that section, and perhaps before this book goes to print, the git config content in chapter 20 may be moved earlier. We'll see. (I'm not a fan of customizing software until you understand its default settings.)

For people reading this post, feel free to comment/reply to this thread about your preference or feedback regarding how the default editor is handled. I'm now of the opinion that I should avoid vi as much as I can, so that beginners to Git can avoid the learning curve that is vi. (Git is hard enough!)

Of course, if you already know vi, you might think my hand-wringing is unnecessary. I know one thing: I'm glad the default editor isn't Emacs!

Thank You, everyone, for reading!
I've decided to write a short blog-type post every week here on this forum. These posts are exclusive to this forum, and they will primarily be about the writing of the book.

I've been adding a table of Git commands to the end of every chapter (where applicable). It was a good suggestion, and it's been a good exercise. I'm nearly done with this, but I will admit it has been tedious.

Tedium largely describes the work between now and when the book moves into production. I'll be correcting problems found by reviewers. I'll be reacting to edits from the editors. I'll even revisit old diagrams and figures, manipulating them where necessary.

In some places that I've worked, this part of a project is known as polishing. I like that. The image in my head is me using a tool to smooth down the rough edges of my creation. Nothing big needs to get fixed, but there's lot of smaller details to attend to.

The last bit of new writing that needs to be done is the preface and introduction. I'm actually looking forward to writing these last few pages. I do have to get through a few weeks of this detailed work first.

Thank You for reading!
I've decided to write a short blog-type post every week here on this forum. These posts are exclusive to this forum, and they will primarily be about the writing of the book.

There are over 330 figures and screen shots in this book. I know because not only did I make the figures or take the screenshots, I also had to rename these files.

When I first started this project, and I had to draw a figure or take a screenshot, I saved the corresponding file into something that made sense to me at the time. For example, figure 1 in chapter 1 is from a file named single_point_of_contention.png. Easy enough!

But a few chapters later, I learned that the production process demands that all figure and screen shot files follow the convention CC_NN. CC is for chapter, and NN is for the figure number in that chapter. So single_point_of_content.png had to be renamed 01_01.png. Again, easy enough: a renaming exercise.

However, I realized I had a severe issue after I learned I needed to renumber certain chapters and figures. This does happen in the editing process. 01_01.png might end up being 02_01.png. Or vice-versa! It led to a momentary bit of insanity. I realized I needed a script that could do the renaming on-demand.

The first few lines of that script:

# Chapter 01 - Before You Begin
cp single_point_of_contention.png $image_dir/01_01.png # Frowny faces
cp distributed.png                $image_dir/01_02.png # Happy faces

# Chapter 02 - An Overview of Git and Version Control
cp vc-personal.png                $image_dir/02_01.png # Revs not Vs
cp vc-personal-with-saves.png     $image_dir/02_02.png


With this convention, I still save files with an easy-to-remember name, but when I need to rename them, I run the script and generate the correctly named files. Any renumbering can be done by editing the script. (Unfortunately, it's not as easy in a Word document. Renumbering figure captions was a tedious slog.)

I haven't had to deal with actual production folks yet, but I'm hoping this saves my sanity about a month from now!

Thank You everyone, for reading.

There won't be a BLOG post next week, due to the American holiday known as the Super Bowl.
I've decided to write a short blog-type post every week here on this forum. These posts are exclusive to this forum, and they will primarily be about the writing of the book.

When I tell people about the book project, some of them say that this is my secret path to financial riches. I'm very quick to point out that as I write the book, it generates no income, and even when it does get printed, I'm going to still need a day job.

There are two components in my financial proceeds from this book: the advance and the royalty. In the case of the advance, the money is enough to buy a new couch. It's a nice reward, but it is not anything that approaches what I make as a programmer. The royalty, on the other hand, is a wildcard. If enough people buy the book, it could become something significant. If no one buys it, I'll get nothing.

My goal is that the book earns my advance, so that I can make royalties. After that threshold is reached, it's all gravy. By my uncorroborated calculations, I think that 1500 copies of the book would have to be sold before that happens. I hope my book stays in Manning's catalog a good long time.

Thank You for reading!
I've decided to write a short blog-type post every week here on this forum. These posts are exclusive to this forum, and they will primarily be about the writing of the book. I first discussed dedications in Book Blog #21.

I attended high school at St. Peter's Prep, a Jesuit preparatory high school in Jersey City, New Jersey, during the early 1980s. That was an exciting time at the Prep (as it was affectionately known). They were piloting a computer science class, the first ever for the school, and its computer lab was expanding from a small room to a classroom-sized lab. I was there during all of this.

Fr. David Stump, SJ, helped lead all this change. He was a teacher who ran the computer lab with much humor and generosity. Before the computer science class was formalized, he formed the computer club, where students could sign up to use Apple-compatible computers. During our allotted time, we learned BASIC, using computer-based learning programs.

He took a sabbatical to learn computer science at a California school. I remember being struck by that: a teacher going back to school. When he returned, he helped formalize the computer science program. In his class, we learned Pascal, and I remember being grateful because that was the computer language for my freshman year in college.

Fr. Stump was the first teacher to introduce me to algorithms, and he valued clarity in our coding. He offered extra assignments for interested people, and often kept the lab open after school. I took advantage of this. Those assignments were similar to the problems you might find on Project Euler, and they helped stretch my thinking.

The summer after I graduated, I helped him on some data entry at a nearby college. We did this work on a punch card system, and the hours I worked there felt like a bridge from the past to the present. Fr. Stump started my formal learning of computers, a journey that I'm very grateful to still be on.

Thank You for reading!
I've decided to write a short blog-type post every week here on this forum. These posts are exclusive to this forum, and they will primarily be about the writing of the book.

Happy New Year 2015!

Over the past holiday week I've been putting together Chapter 19. There is one more chapter to write after that. Though the work isn't finished yet (revisions, always revisions), I am beginning to feel lighter, now that I can see the finish line. I'm almost there.

I plan to keep writing these entries until the book enters production, which is actually sometime in February or March.

I still learn interesting Git bits. For example, just this week, I learned you can obtain the key paths from which Git obtains its executables and manual pages, by typing:

git --exec-path

git --man-path


Esoteric, to be sure, but helpful when debugging.

Thank You everyone for reading!
I've decided to write a short blog-type post every week here on this forum. These posts are exclusive to this forum, and they will primarily be about the writing of the book.

I always thought it would be interesting to examine the commits for my book using some data visualization. It would be a way to visualize all the work I've been doing. This thought simmered as a side project for many months, then in November I installed GitLab. Once I uploaded my book's repository into GitLab, I had a few visualizations that were interesting.

image

Clearly I'm busier during the middle of the week than towards the end of the week. And it looks like Saturday might well be a considered a day off as far as working on the book goes.

image

This shows that this book is clearly an after-hours project. I do manage to sneak in a few commits during the business day, and I would have to guess those are notes or scripts as opposed to actual manuscript writing.

Both of these graphs intuitively make sense to me!

There won't be a BLOG post next week, due to the Christmas holiday. Thanks for reading everyone!
I've decided to write a short blog-type post every week here on this forum. These posts are exclusive to this forum, and they will primarily be about the writing of the book.

One of the things that I do with the MS Word manuscript files is compare versions. However, in Git your working directory represents only one commit. How do I compare two commits at the same time? (I can get a rough comparison with git diff, but for this post, how can I use MS Word's comparison tool, which wants an old version and a new version of a file?)

Clearly I need two copies of the MS Word file that I want to compare. I looked briefly at git diff, which somehow compares two files. The code for git diff is in C, with plenty of Git internals. I didn't go down that path, and in the end, I did a possibly low-tech solution:

git clone gitbook gitbook-timetravel


This command created a clone of my repository named gitbook-timetravel. Since it's a clone, I can access any commit. And because its origin remote is my active repo, I can update it at any time by doing a git pull.

With these two directories (gitbook and gitbook-timetravel), I can now compare files using Word. I use the gitbook-timetravel for the older version, leaving gitbook at the current revision.

A solution to a technical problem doesn't have to be technical! Thanks for reading, everyone!
I've decided to write a short blog-type post every week here on this forum. These posts are exclusive to this forum, and they will primarily be about the writing of the book.

I'm the only person committing to my repository. However, despite working alone, I still can flub up my Git repo. This means that I sometimes forget to pull in work from the last time I pushed work (the workflow I described in Part 1 of this series).

Using the command 'git log --merges', I can see every time where this time happened. For the record, this happened 21 times (so far). Every merge means I forgot about work I did!

One of the first times this happened was when I performed a git commit --amend. This command allows you to update the latest commit of your current branch. However, I had already pushed my change to BitBucket, so when I pushed again, Git complained.

More typical though is that I make a change to a text file on my Linux machine, then make a change to an MS Word document on my PC machine. Git forces me to merge these two pieces of work. It's amazing to me how quickly I can forget what I've already done.

It's cool that Git can help me figure out what I was doing in another part of the repository. No work is forgotten if you are diligent about committing to your repository. A simple git log or (if need be) a more involved git checkout operation is enough to remind myself that Git can keep even a solo worker organized.

Thanks for reading!
I've decided to write a short blog-type post every week here on this forum. These posts are exclusive to this forum, and they will primarily be about the writing of the book.

One of the benefits of Git is that you can obtain the differences between commits. So how does this feature work with Microsoft Word? The short answer: it's somewhat OK.

Git for Windows (http://msysgit.github.io/) came with a piece of software called antiword. This program takes an MS Word document (with the ".doc" extension), and extracts all of its text. Git Bash then has a configuration such that any use of git diff on a Word document would first be converted by antiword. Git then takes the difference between the extracted text. This nifty piece of configuration prevents Git from saying that it cannot obtain the difference between two binary files, but unfortunately, Git cannot apply a diff to a binary Word document.

I found the configuration interesting, but over the course of the writing, I found myself not needing it. If I need to compare files, I resort to Word's "Compare Documents" tool. This allows me to compare any two Word documents. Further, Word's venerable "Track Changes" feature records each change to the document. These changes can then be inspected by anyone else. It's the equivalent of an editor's red pen!

antiword does have its uses, however. For one thing, with the extracted text I can use command line tools to do analysis (word count and frequency). Also, having the chapters as text makes it very easy to search with the grep command line tool across all my files (each chapter is a separate Word document, so globally searching the book isn't possible with Word). Finally: it's faster to open a text file than a Word document, so if I just want to reread something, I usually will check the text file.

There won't be a BLOG post next week, because of the Thanksgiving holiday (in the US). Thank You, everyone, for reading!
I've decided to write a short blog-type post every week here on this forum. These posts are exclusive to this forum, and they will primarily be about the writing of the book.

I plan to elaborate on this topic over at least two parts, and in more detail on my Tech BLOG (http://tech.rickumali.com). For this post, I wanted to describe at a high level how I use Git for this book.

I work over three machines (described in Book Blog #14). Each of those machines has Git installed. For the book files, I created the initial repository on my Windows machine, then pushed it up to a private repository on Atlassian's BitBucket. The repo now contains almost 400 files, over almost 800 commits.

Since I'm the only contributor to this repository, my Git workflow is very simple. Whenever I start work on the book, I first run git pull. This synchronizes my working directory with the latest changes. Whenever I finish work, I run git push. This uploads my changes to BitBucket for use the next day.

In between the git pull and git push, I'll perform the standard git add/git commit to save my changes. Whenever I upload code to the publisher's system (Nuxeo), I tag the repository. I use three tags so far: CODE, SUBMIT, and V (for the table of contents). I add a number to each tag (I'm up to SUBMIT #50, for example).

In future parts, I'll discuss using Git with MS Word files, and issues I've run into with this simple workflow (yes....even just by myself, I've run into issues).

Thank You for reading!
I've decided to write a short blog-type post every week here on this forum. These posts are exclusive to this forum, and they will primarily be about the writing of the book.

Most books have some kind of dedication page, near the very front. It's a bare page, with just a name or a sentence indicating who the book is dedicated to. Over the past few months I spent time thinking who I might dedicate this book to.

When I took up the matter with my wife, I learned that not all books have dedications. This led me to look at other Manning titles. Some of them had dedications, and some didn't.

This hasn't stopped me from thinking about the short list of people for this special page. One name that persistently pops up is Peter Winston. He is the CEO of ICS, a technology company specializing in UX design utilizing Qt and Motif. He was the first person to hire me out of college.

I remember that in my interview with him, he asked me what I wanted to be when I grew up. I hardly remember my answer now. What I do remember is that he's the only person who ever asked me that question so directly.

I enjoyed my time with ICS. Because it was a start-up, I was able to see and participate in a lot of the non-technical functions of a software company (training, support, technical sales). ICS was a great first job, and I look back on it with great fondness. It's a testament to Peter's business acumen that ICS is still flourishing.

Thank you for reading!
I've decided to write a short blog-type post every week here on this forum. These posts are exclusive to this forum, and they will primarily be about the writing of the book. I last discussed revisions in Book Blog #11.

I remember one of the very first articles I wrote for my high school newspaper. It was a front-page piece, and I was anxious to see the edits after I submitted the story. When my piece came back completely red, I felt hurt. Whole sentences were crossed out. Word selections were questioned. Even how I structured the article had to change.

Fast-forward to this book, and I feel like I'm back at that high school newspaper. As my editors today give me feedback, I remind myself that every edit is provided to increase the quality of the book. When I submit a chapter, I'm convinced it's ready to print. But when I get the edits back, I can see how much better it could be.

I still feel stung looking at the edits. I then remind myself that I'm not a high school kid anymore. Finishing this project means considering and reacting to each edit. I have to get past my feelings, and remember that revisions make the book better.

There won't be a BLOG post next week, as I'll be giving a presentation about Git at the New England Drupal Camp in Providence, Rhode Island on Saturday, November 1. Thanks for reading everyone!
I've decided to write a short blog-type post every week here on this forum. These posts are exclusive to this forum, and they will primarily be about the writing of the book.

I subscribe to Bruce Schneier's CRYPTO-GRAM newsletter. It's a very interesting e-mail covering the world of security. He sends it out once a month, and in his October 2014 e-mail, he announced that he had just finished writing a book.

This new book clocks in at 80,000 words, and its title is "Data and Goliath: The Hidden Battles to Collect Your Data and Control Your World" (publisher: Norton). In his newsletter, he writes about what he's going to do now that he's done with the "all-consuming" task of writing. (His answer: write shorter pieces!)

I crave the ending of my own project. I want to get back to playing the guitar. I want to attend more meet-ups. Mostly, I want to dig into new technology. (I have Manning's book on Solr and a book on Ruby internals by Pat Shaughnessy.) It'll be fun to have discretionary time again. Until then, I'll be writing.

Thank You for reading!
I've decided to write a short blog-type post every week here on this forum. These posts are exclusive to this forum, and they will primarily be about the writing of the book.

Around November 2013, I joined a mailing list for people seeking to be technical reviewers for Manning Publications. This was an opportunity to read some books that were still in development, and to provide feedback. The reviews editor sends out a list of books for review to this list, and we just raise our hands to volunteer.

In December 2013, I volunteered to review five chapters from the early manuscript of Git in Practice, by Mike McQuaid. The reviews editor, Ozren Harlovic, gave me access to that book, and provided a detailed questionnaire to organize the feedback. It's a good process.

There was one question in that questionnaire that started it all for me: "What technology experts (perhaps lesser known) do you think would make good authors?" I wrote "Me!" Ozren noticed that (I didn't think anybody would), and a few weeks later I was staring at a contract to write this book.

File this post under "be careful what you wish for!" Thank You everyone for reading.