Adding lots of git love to your prompt

There are two things that are really useful to see *at a glance* while writing code:

  1. What branch am I on?
  2. Have I modified stuff?

NINJA EDIT: Alan Antonuk has mentioned that there already are such bash prompts in git. Here’s what I’m now using:

#git ps_1
if [ -f ~/ ]; then
    export GIT_PS1_SHOWDIRTYSTATE="true"
    export GIT_PS1_SHOWSTASHSTATE="true"
    . ~/
    export PS1="\$(__git_ps1)$"

You can get the latest from

And here’s what I used to use:
I added some stuff to PS1 so my bash prompt shows both the the branch name and the diff status.

Define two functions in your ~/.bash_profile:

    function parse_git_branch {
        git branch --no-color 2> /dev/null | sed -e '/^[^*]/d' -e 's/* \(.*\)/ \[\1\]/'
    function check_modified_git {
        if git diff --quiet 2> /dev/null && git diff --cached --quiet 2> /dev/null
            echo "*"
            echo ""

and wrap the change to PS1 with a test for git – just in case your bash_profile is executed on a machine without git installed:

if hash git 2>/dev/null; then
    export PS1="\$(parse_git_branch)\$(check_modified_git)$"

Of course, you can do fancy things with colors. There’s lots of explanations of the bash color codes online; here’s one:

Ruby Love #1

In my post about Elegant code and craftsmanship, I talked about how DRY – or Don’t Repeat Yourself – is one of the prime directives I try to follow as I develop.

In this series of posts, I’m going to post small tidbits of cool language constructs in various languages that help keep things DRY. They’ll all be tagged under language love, so you’ll be able to search and keep track of them in an easy way.

Today’s tidbit: generating methods in Ruby.

Sometimes you write a lot of code that looks like this:

    def commit_all
      @productions.each do |k,v|

    def dump_all(d)
      @productions.each do |k,v|

    def	reset_all
      @productions.each do |k,v|

Doesn’t feel very DRY, does it? In fact, if you end up changing how you store your productions, you’ll have to change the code at least three times. Urgh.

Ruby allows you to define methods dynamically, on the fly. So you can instead write something like this:

   [:reset, :commit, :dump].each do |m|
      define_method(m.to_s+"_all") do |*args|
        @productions.each do |k,v|
          v.send m, *args

Note how the _all* methods also correctly forward the arguments, if any, to each production’s method.

Cool, no? Of course, this is really just classic metaprogramming much like Lisp. I just love how Ruby expresses it! The syntactic sugar is a nice mix between too verbose and too sparse, while still being flexible enough to allow lots of metaprogramming magic. (I will admit the way Ruby expresses variable arguments is a little confusing, though…)

Elegant code and craftsmanship, or, how lagrangian mechanics is the same as Ruby on Rails

Recently, I’ve been working on a project that customizes my task management software. I’ve been writing it in Ruby, which is a pretty interesting language.

At this point, I’ve probably rewritten the code 3 times.


Because it’s more elegant the second (third!) time around. Because it’s more beautiful, easier to maintain and understand, and easier to extend and grow. But, most importantly, because it feels good.

In fact, every time that feeling hits: “Wait, I could do this better!“, I think of college and my time as a physics major. We all used to work on our problem sets in this one room in Leconte Hall:

Leconte Hall

Leconte Hall

I was never that good at physics. My solutions were always ugly, three or four pages long, full of copied terms that never went away, even though everything started beautifully elegant and short, like this lagrangian: 1

Lagrangian in spherical coordinate system

When I compared with my classmates, I knew they were out of my league. Not only did they get the right answers, but their answers were beautiful. Short. Concise. Elegant. The answers, in other words, at the back of the book.¬†Invariably, my classmates would say: “Well, you see, if you just chose this” or “Well, if you just rearrange this…”

I never really “grokked” physics deeply enough to feel my way to those insights without help.

But I think I can articulate what, fundamentally, is the most important feeling that guides me to great, elegant code:

Don’t Repeat Yourself, ever.

There’s a whole bunch of reasons why you should write elegant, concise code. I think a lot of people have made convincing arguments, showing that it increases maintainability, flexibility, and so on. I’m going to take a step further. I claim those things are simply gravy.

In the long run, if you want to keep on solving hard problems, or hacking together great prototypes in 8 hours in an all night hackaton, or growing your product, you need to love what you are doing.

The first step towards loving your work is respecting the work you create and honoring the feelings you have while creating it. Don’t stuff those “I can do this better” feelings away because it means you have to rewrite something or take 2 more hours to do it right.

It’s worth it to do it right.

EDIT: I’ve kicked off my language love series, which will be short posts about fun things that I find really elegant in different languages: the first is about dynamically adding methods in ruby.

1. This is a pretty elegant lagrangian for the total energy of a particle in spherical coordinate system. And yes, I got it from wikipedia; I haven’t installed LaTeX in years.