X-Combinator

Since my upgrade to OS X 10.5 I have been having a terrible time getting colors to work with git.

Originally I was using OS X 10.5.4, git version 1.5.3.1, and iTerm or Terminal.app. $TERM=xterm or xterm-color. I have color with PS1, ls, vim and most git tasks. However, git diff (or git show) always screws up the diff by showing the ESC[ characters instead of colors. For instance:

  [nathan@nate ~/s3]$ git show 67d254ec17f
  ESC[33mcommit 67d254ec17fdc507765ddee1feb2a14e5896e79fESC[m

I searched and searched wasn’t able to figure out how to fix this. It was suggested on the github forum that I upgrade to git 1.5.6.4. Unfortunately not only did it not fix the color in git diff, it broke the color in git status which was working previously.

After about a week of poking around on and off I discovered that the problem was not git, but my GIT_PAGER which is more. If I tried GIT_PAGER=cat git-diff then the color output just fine. less and more use the same environment variable LESS (man less for details). And less was outputting the colors as raw escape codes.

man less shows that the option -R is defined as follows:

       -R or --RAW-CONTROL-CHARS
              Like  -r,  but  only  ANSI "color" escape
              sequences are output in "raw" form.

That would do it.

After perusing the man page for a while I settled on adding this to my
~/.profile:

  export LESS="-erX"

At the end of the day, this tip is really about less and how it interprets colors and probably has little to do with git. Even so, I only found this odd behavior while using git. Hopefully this post will help someone who is having similar issues.

As a side note, below is an example of how to configure your colors for git-diff and other commands.

[user]
    name = Your Name
    email = y...@yours.com
[color]
    branch = auto
    status = auto
    diff = auto
[color "diff"]
    meta = yellow
    frag = cyan
    old = red
    new = green
[color "branch"]
    current = yellow reverse
    local = yellow
    remote = green
[color "status"]
    added = yellow
    changed = green
    untracked = cyan
[alias]
    st = status
    ci = commit
    co = checkout
    br = branch

Nathaniel Talbott (from Terralien) gave a great talk on a number of interesting hacks in ruby. There was one in particular that I want to focus on here: gitjour. Gitjour is a fun and novel app that will discover git repositories on a local network via Bonjour. It’s hardly going to change your life, but it is fantastic for ad-hoc sharing of code on a local network and quick collaboration without too much ceremony, e.g. at a conference, or ruby users group, etc.

It’s a fun tool and you should definitely try it out.

While I’m on the topic of git, I’d like to point out that the community at RailsConf was completely sold on using git and using GitHub in particular. Even though I am a git-switcher myself, it was really surprising to see that almost the whole community had either switched or was planning on switching.

GitHub did a great job marketing at the conference. They gave out free t-shirts that said “Fork You” on the front. On the back the shirt said “http://github.com/________” and you were expected to take a sharpee and write your GitHub user name so that others could see your projects (my projects are here). The successful result was that at nearly every session or meal someone would use the phrase “I think I’ll put this code up on GitHub”.

UPDATE: I’ve found a picture of the shirt here

John Wiegley recently wrote a great article about git called Git from the Bottom Up (pdf). I found it to be very helpful in clarifying how git works and that understanding makes git feel more accessible.

Understanding commits is the key to grokking Git. You’ll know you have reached the Zen plateau of branching wisdom when your mind contains only commit topologies, leaving behind the confusion of branches, tags, local and remote repositories, etc.

Even after reading his pdf it took me two days for this idea to sink in. I finally had my “ah-ha!-moment” after I poked around in the .git/refs folder for a while.

Git Pieces: Taken from John Wiegley’s article, “Git from the Bottom Up”

I think I resisted learning the git internals for a while because I didn’t want to understand it I just wanted to use it. The problem was I wanted to use it like svn and git requires a mental paradigm shift. After reading John’s article I’ve come to realize once again that there are no shortcuts to progress and often the quickest way to learn is to first take the time to understand.

I’d highly recommend that anyone that still working on “grokking git” should take the 30 minutes required to read John’s article.