Review your commit changes with 'git add --patch'

I found that git is particularly useful for reviewing changes I'm going to commit.

When I'm ready to commit and my change is more than couple of lines of code in one file, I do

  $ git add --patch .

Then git nicely shows me every hunk of change I made in the code.

I see two benefits of working that way:

1. Obviously it is opportunity to skim through my own code, and it leads to more focused reviews than if I just read through whole source, or even skim through full patch to be committed.
2. It leads to atomic commits which I'm big fan of:

• I don't forget to add things to index. This is not much important when using git, 'cause I always can amend my commits, or even rebase interactively, but it's always nice to form nice commit earlier rather than later. Of course I can do just 'git add .' or even 'git commit -a' for that which leads to next point:
• if for some reason I made several unrelated changes, I have an opportunity to split my change into several logical changes if needed. That is where real power comes.

The workflow is as follows:

  $ <hack hack hack>

  $ git add --patch . # interactive session where I select what comes to commit

  $ git stash save --keep-index # I stash my unstaged index; needed for the next step:

  $ <compile and run tests to make sure you haven't screw with partial adding patches>

  $ git commit

  $ git stash pop # get the remainder of my changes back in working copy

  $ <repeat with git add>

If I have screw somewhere:

  $ git reset # moves staged changes from index (they are still in working copy)

If I want to review the changes one more time after adding but before commit:

  $ git diff --staged

It sound like a lot of work should be done for every commit. I don't know. First of all I do it fast enough (shell history can help do it even faster). And I use this technique only if I've touched code in several places.

Advanced techniques and details of git add you can add in the documentation, and in Markus Prinz'es article.

Hacking in front of a kid

I've been hacking a simple breakout/arcanoid game clone last time. It uses pygame for graphics/audio/input/windows/etc. so that I can concentrate on the game logic.

My goal is to implement something cool for my 6-year old son. But also I try to show my son what daddy can do with his text editor and terminal. The game logic itself is the next to trivial for such a simple game, so I trick myself for developing new features in front him.

I must say that that is amazing experience. We do it in 10-20 minutes sessions. During that time I'm implementing some game feature, and afterwards he plays a bit. While I'm hacking he is sitting next to me and staring at python code. And for sure if I don't produce something exciting in 5 minutes or so, he get bored. So I'm coding in real time like hell. (And using dynamic language with extremely short "hack-try-fail-fix-try-works" cycle suits really well.)

No tests, no design (except some half-minute thinking in advance), just pure hacking.

At this point of time I just want to show the kid what you can do with programming. I think you need to excite somebody with before teaching them  industrial methods. Like, you buy your children Lego, and you show them what they can build with it, and then you want them to play with it. And only later on you teach them that they should design their buildings first and that they should pass some regulatory mandated tests and follow the industrial good practices. And hacking simple python games using nice game engine is just like that -- constructing Lego buildings.

I think I'm halfway done with exciting my son with programming, because after third of fourth session he asked me what it takes to be a programmer :)

P.S. Disclaimer: I make up the code a bit while he is sleeping though, so when we start next day it doesn't look like complete mess. One day I will share it on github.