Git Tip of the Day – squashing merges

You certainly develop your new features in so-called feature branches – i.e. other branches than master. What’s your approach when your new feature is complete and you want to put that code into the master branch?

Up till now, I used one of these two methods:

Merge the branches

If my feature branch, let’s call it newstuff, contains just a single or very few commits and all of them being high-quality (well separated code changes, descriptive commit messages), I would simply merge master and newstuff.

$ git checkout master
$ git merge newstuff

Diff-n-patch

If my newstuff branch contains loads of commits, or they are of poor-quality (my favorite “WIP” strings as commit messages, etc), I would create one big patch against master and then apply it there. Therefore I wouldn’t pollute master with low-quality changes.

$ git checkout newstuff
$ git rebase master  # or 'git merge master'
$ git checkout master
$ git diff --binary master newstuff > patch
$ git apply patch
$ rm patch

This is somewhat tedious approach.

But today is my lucky day. I found a way to do the second approach much easier:

Squash merging

I decided to the the second approach (diff-n-patch) but I want something faster, without the intermediate step of creating a patch file. That’s exactly what squash merging can do:

$ git checkout master
$ git merge --squash newstuff

This has several advantages. First, it’s simpler (yay!). And second, you don’t necessarily need to make sure that newstuff is on top of master first (by merging or rebasing), because this approach uses git intelligent merging algorithm to detect and resolve conflicts.

The net effect is that you’ve just put your new code to master with just a single commit.

Git Tip of the Day – check for whitespace errors in diff

When creating and applying patches, git often complains about whitespace errors. Whitespace changes are generally not desirable, because they make the diff longer and diverts your focus from (very probably) more important changes. From this reason git tries to provide warnings for whitespace changes that might have not been needed. This includes trailing whitespace, spaces before tabs in indentation and empty newlines at the end of a file.

If you execute

$ git diff

and have colored output enabled, git marks these changes with light red background.

But if you don’t have colored output enabled, or maybe your patch is too long and you don’t want to scroll through it, there’s an easier way to check for whitespace errors. Just execute

$ git diff --check

You can then receive output like this:

$ git diff --check
README:7: trailing whitespace.
+or ask in #fedora-qa on the freenode IRC network.  
README:13: space before tab in indent.
+       'autoqa' is the main binary that kicks off tests
TODO:14: new blank line at EOF.

And now you know what to fix.

If you’re working on a patch for some project and you’re about to send it, use this simple command to check for whitespace errors. It will then save a little work for everyone who’s going to read the diff (or the commit log).

Happy gitting!

sendKindle: send files to your Kindle from command line

Do you have an Amazon Kindle device and do you find the standard way of transferring files via email too uncomfortable? I’ve created a simple tool that may be of help.

I have lots of books (PDFs, PDBs, etc) on my computer. I also frequently download something from the web (HTML pages, images, …) I want to read later on my Kindle. But I am too lazy to find the data cable and I am also too lazy to open up web client and send the files as attachments. I wanted something simpler, so I created it.

The tool is called sendKindle. It’s a simple Python CLI script that takes all files specified as arguments and sends them to your Kindle device via your email provider (you need to create a configuration file with access details first).

You can find the code at:

https://github.com/kparal/sendKindle

You can check-out the code and run the tool directly, or install using easy_install:

# easy_install -U sendKindle

And then you just do:

$ sendKindle FILE...

On the first run you will be asked to create a configuration file at ~/.config/sendkindle/sendkindle.cfg with appropriate email settings (just copy and paste and change appropriately).

And that’s all, my friends. I hope some of you will find it useful.

Enjoy.