Monthly Archives: January 2017

Advanced Git Commits

This article will outline some advanced usage patterns for git commit

Skip Staging

When I was first learning Git, I had difficulty grasping the purpose of Git’s staging area. It seemed, at the time, a pointless step in the process of performing a commit. Later in this article, we will see some good reasons for using the staging area. In this section, I will show you how to skip the staging area when committing.

The standard process when committing is to first stage, then commit.

$ # Use a text editor to modify index.html
$ git add index.html # Add to staging area
$ git status         # We see that index.html has been staged
On branch master
Your branch is up-to-date with 'origin/master'.

Changes to be committed:
  (use "git reset HEAD ..." to unstage)

        modified:   index.html

$ # Commit with a message
$ git commit -m 'Added content to index.html' 
[master 1203be7] Added content to index.html
 1 file changed, 1 insertion(+)

In the above, we had to use git add index.html to stage the file. However, if we use the -a option of git-commit, we can eliminate this step:

$ git commit -am 'Added content to index.html' 

Here, the -a option causes all the modified files in the working directory to be added to staging automatically. This has the effect of putting the staging process behind the scenes.

Note that the -a is joined with the -m option for convenience. It could have been written like this:

$ git commit -a -m 'Added content to index.html' 

But that’s just more to type. Be sure, however, that the -m option is at the end since Git will expect the commit message to come directly after it.

Verbose Commits

Of course, to see what you are about to commit, you would use git diff. However, if you want to edit your commit message in a text editor (by omitting the -m option), it would be convenient to have the diff available to you in the editor for viewing.

Edit some files in your working tree and try this on for size.

$ git commit -av

As in the section Skip Staging, the -a option is used to add the files to staging automatically (of course, we could have used git add if we wanted to). The other option, -v, meaning verbose, appends a unified diff to the contents of the text editor. This is what I’m seeing in my text editor after I issued the above command.

Change content
# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
# On branch master
# Your branch is up-to-date with 'origin/master'.
# Changes to be committed:
#   modified:   index.html
# ------------------------ >8 ------------------------
# Do not touch the line above.
# Everything below will be removed.
diff --git a/tmp/index.html b/tmp/index.html
index 4b8b391..0aca176 100644
--- a/tmp/index.html
+++ b/tmp/index.html
@@ -3,7 +3,6 @@
         <title>My Document</html>
-        <p>Some content.</p>
-        <p>Some more content.</p>
+        <p>Changed the content.</p>

This makes editing the commit message convenient because you can look at a the diff and comment on exactly what you’ve done. And, if you see something you don’t want committed, you can abandon the commit by leaving the commit message blank and exiting the editor.

Commit and Patch in One Command

One of my favorite features of Git is the ability to stage selected modifications in your working tree. I wrote an article about it here. Normally you would use git add -p to go through all your modifications selecting the ones you want to commit. This is good when you have more than a few modifications. However, when I have made a small modification, and I know there are modifications in my working tree that I don’t want to commit, I use this command:

$ git commit -p

This will first take you through the patch selection process, then put you in a your text editor to write a commit message. You can also add the -v option (which I always do) to get the diff in your editor.

$ git commit -pv

Amending Commits

If you noticed that you made a mistake with your last commit, it’s quite easy to correct it. You may have a typo in the commit message or you may have noticed there was something wrong with the code you committed. Either way, all you need to do is use the --amend option in your git commit.

$ git commit --amend

Your text editor will be launch and you can edit your commit message to whatever you like. When you leave your text editor, you will notice in git log that the last commit you did now has the updated commit message. (The commit’s SHA1 hash will also be different from the original since the commit’s timestamp and message have changed.) You can also modify the code changes in the commit simply by modifying and staging you code, as you normally would, and then committing them with the --amend option. The --amend options can also be conveniently mixed with the -a, -v and -p options described above.

Bought a Chromebook

Recently, I was in the market for a new, personal laptop. I wanted something that would run Linux well. For about a decade, I’ve been installing and using Linux on my laptops, but WiFi has always been a hassle. Typically, there has always been some sort of issue with the network card’s driver which caused it to only half support Linux. This would result in hours spent resolving the issue. Often, I would end up having to buy a USB-based WiFi network card that I knew was supported by Linux.



It was my wife who suggested I buy a Chromebook. Though not a proper Linux machine, the idea of a light-weight, thin-client running a browser and little else had an appeal for me. I actually don’t use my laptop for much else other than surfing the web and SSH’ing into other machines. So, since there is an SSH client plugin for Chrome, I thought I would give a Chromebook a try. Also, I reasoned, if it didn’t work out, I could always install Linux on it. After all, Chrome OS is based on the Linux kernel so there shouldn’t be any issues with running pure Linux on it.

The Hardware

I ended up purchasing the Acer Chromebook 15. I like this machine a lot. It’s got two speakers on either side as tall as a hand and the width of two fingers. This is great for watching movies or listening to music. (On my other laptops, I’ve always needed headphones in order to properly hear speech or music.) It’s also very light-weight — probably because of the SSD hard-drive. The battery-life is terrific and the laptop has a good look and feel to it. It’s also fast – much faster than my older machines which often made simple web browsing painfully slow.


I do have several complaints about the user interface aspects of the hardware. For one, the mousepad is positioned in a way that makes it inevitable that it will get tapped accidentally. As I write this in a WYSIWYG editor, I’m constantly noticing that the cursor has been moved which causes me to inadvertently type in different sections of the text. Another irritant is that there is no caps lock button — it has been replaced by a magnifying glass button — I guess so you can Google things faster. I don’t know what the consensus is on caps lock buttons, but I rely on them and I wish this laptop came with one. Also, the function keys have been replaced by special, Chromebook keys.

The Software

It’s pretty amazing to interact with this OS. It’s essentially on as soon as you hit the power button. Once on, you log in with your Google credentials. Then you set your keyboard layout, connect to your WiFi, and you’re ready to surf the web. I like Chrome, but prefer Firefox for its Awesome Bar. However, in this instance, I was willing to make a comprise.

My next task was to ensure I could get the aforementioned, browser-based, SSH client working. This is a good piece of software from what I was able to tell. However, after editing source code on a remote server, I became aware that there is a major issue with the concept of a browser-based SSH clients: key bindings. For example, I noticed that when I used CTRL-W to change windows in Vim, I was also telling Chrome I wanted to close the tab. I found a workaround for that, but then, when I tried CTRL-D to exit a shell, I realized I was telling Chrome I wanted to bookmark the current page. At that point, I realized that I was going down a rabbit’s hole of hacks I would have to make to Vim, Bash, etc., and that I should abandon Chrome OS and install Linux.

Installing Linux

Installing Linux on Chromebooks is interesting. You actually don’t defenestrate Chrome OS; you run both operating systems at the same time (glad I got 4GB of RAM instead of 2GB), and you can switch between them swiftly with a hotkey.

When I say you run both OS’s at the same time, I’m not talking about a virtual machine. Rather, you run Linux from Chrome OS using chroot. This is all made possible by a piece of software called Crouton.

Anyway, installing Linux on a Chrome OS is a fast, straightforward process. I recommend this tutorial. However, it is a little outdated since Crouton now supports Trusty Tahr, so once Ubuntu has been installed, remember to install it with this command.

sudo sh ~/Downloads/crouton -r trusty -t xfce

You have the option of installing Xfce or Unity. I choose Xfce and that consumes pretty much all of my 4GB of RAM. (I wanted to use Ratpoison but that doesn’t appear to be supported.)

After tweaking Xfce to meet my needs, I now have a beautiful installation of Linux and Chrome OS on a very capable laptop. I code and surf in Linux and I use Chrome OS for watching Hulu, Netflix, etc. Chrome OS is more convenient for this kind of thing because it doesn’t have the hangups about DRM and Flash that Firefox and Linux do. Chrome OS is also needed for managing WiFi connections which I have not had any issues with.


For the Linux lover, Chromebooks provide an solution which is both awkward and elegant. A complete Linux experience can be had with WiFi being competently managed by Chrome OS. For DRM media offerings like Netflix and Hulu, the user can easily switch to Chrome OS for hassle-free viewing. However, little RAM is left and the small SSD hard-drive is as fast as it is limited in its storage capacity.