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:

1
2
3
4
5
6

# Chapter 01 - Before You Begin 
cp single_point_of_contention.png image_dir/01_01.png # Frowny faces
cp distributed.pngimage_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.pngimage_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 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!

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!

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!

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!

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!

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.

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.

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

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

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

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

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.

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.

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

Thank You for reading!

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

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 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!

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!