Git version 1.7.8, which is shortly to be released at this writing, contains a handy new program git jump. The idea is that you can say things like git jump diff to have your $EDITOR go directly to the lines within your files that contain unstaged changes.

The design of git jump is particularly helpful for Vim users, but what if you prefer Emacs?

One of the great things about Git is that it makes branching and merging so simple as to be a delight, not a chore. One of the consequences of that is that you tend to use far more branches than you would if you were using a lesser revision-control system. Which can make it easy to forget which branch you’re on at any given moment. So wouldn’t it be nice if you had a simple, easy-to-see reminder of where you are, visible at all times?

Nearly a year ago, Mark Jason Dominus blogged about runN, a program he’d written. I’ve stol– uh, I mean, adapted his version for my own ends, with a couple of differences. This is a rationale for my changes.

SSH is great; it’s highly secure, and actually easier to use than insecure alternatives like rsh or Telnet. In fact, it’s so easy to integrate SSH with everything else you do that it’s commonplace to rely on it for all sorts of things. But oddly, that very ubiquity tends to reveal an unexpected problem when you try to use SSH for, say, accessing a revision-control system: merely connecting to the remote end and performing the handshaking necessary to set up the encrypted channel takes an appreciable amount of time.

So herewith instructions on how to eliminate that overhead.

Something I find awkward about Git is that it doesn’t seem to deal with the concept of a tracked but uncommitted file — that is, the situation you’d get into with CVS after running cvs add on a new file, but before committing that file to the central repository.

Eric Sink has an interesting piece about MeWare, ThemWare, and UsWare. The basic idea is that one way of categorising software is by who uses it:

• MeWare: only the developer
• UsWare: the developer, among others
• ThemWare: people other than the developer

I think most programmers can see what Eric’s getting at there. If you’ve ever worked on, say, a piece of software used exclusively by people in a different department of the company you work for, you know how hard it can be to ensure that the software actually meets those people’s needs.

However, I took issue with one particular thing Eric says.

A colleague approached me today regarding a unit test he was writing. He was constructing a series of test cases from a data structure; his code at the time used a multi-line string of which each line had several fields which together described a test to run.

GNU Screen is an extremely useful piece of software, but one that requires an annoying amount of hackery to make it useful. Herewith a description of why you want to use it, and what you have to do to make it work better.

Some people prefer dark-on-light colour schemes for their terminals. Others prefer light-on-dark.

I’m in the latter camp. I suspect that’s mainly just out of habit, rather than anything well-reasoned; certainly I find myself agreeing with the idea that matching the properties of paper is a good thing.