I’ve been using git for various projects and want to share tips for making it more convenient.
One of git’s advantages is cheap branches. A branch is just a file in .git/refs/heads containing the id of the last commit, so creating a new branch takes very little time. With such capabilities, most programmers use branches extensively.
Whatever model you choose for branches, you can eventually forget which branch you’re on and commit code to the wrong place. Although this is easily fixed, you can avoid it by adding branch information to your bash prompt.
Installing git bash completion
Git includes several useful scripts, including git-completion.bash. After loading it, bash completion will include git commands, local and remote branch names, tags, and more. The script also defines useful functions for getting environment information.
% git
add -- add file contents to index
am -- apply patches from a mailbox
apply -- apply patch to files and/or to index
archimport -- import an Arch repository into git
archive -- create archive of files from named tree
bisect -- find, by binary search, change that introduced a bug
blame -- show what revision and author last modified each line of a file
br -- alias for 'branch'
branch -- list, create, or delete branches
bundle -- move objects and refs by archive
cat-file -- provide content or type information for repository objects
check-attr -- display gitattributes information
check-ref-format -- ensure that a reference name is well formed
checkout -- checkout branch or paths to working tree
checkout-index -- copy files from index to working directory
cherry -- find commits not merged upstream
</pre>
If you use MacPorts, ensure git-core is installed with the +bash_completion variant:
% sudo port install git-core +bash_completion
---> Computing dependencies for git-core
---> Cleaning git-core
If you installed git from source, search for the script:
**Update:** Enclose colors in PS1 with [], otherwise bash will incorrectly calculate prompt length and handle line wrapping incorrectly.
After setup, if the current directory is under git control, the command line will display the current branch name.
A friend dropped this in our Slack the other day about Steve Yegge’s Gas Town:
I think Gas Town is directionally correct but you have to admit also unhinged in a bunch of ways. I can’t help but be attracted to the absolute gonzo yolo mentality that birthed it, but I wouldn’t want to live there.
It’s been rattling around in my head since. He’s right on both counts. And I say that as someone who actually lives there.
The main thing I keep noticing isn’t the tools. It’s where the work goes.
Over the last six months living in Gas Town, the biggest shift hasn’t been speed, it’s attention. This post is about how that attention moves upstream into design and guardrails, and how the feedback loops change once you stop reading every line.
I’ve been using Claude Code and Codex a lot lately, and something unexpected happened: I started having more ideas than I could track.
Not because I’m suddenly more creative. Because building stuff got faster. When you can go from “I wonder if…” to a working prototype in an afternoon, you start noticing more itches worth scratching. A dashboard for ski conditions. A break-even calculator for EV charging. A CLI for searching mountain peaks.
A lot of these are afternoon builds. Some would take weeks. A few will never happen. But I kept losing them, scattered across Notion pages, random notes, half-remembered thoughts.
Yesterday we were driving up to Snoqualmie Pass to ski with the family, and I realized I’d forgotten to charge the Rivian overnight. So we had to stop in Issaquah and top up at Electrify America, going from about 10% to 85%. The price there was roughly $0.56/kWh, which naturally turned into a conversation with my dad about how charging a Rivian really compares to fueling a gas car.
We came up with some rough numbers on the spot, but I was curious what this actually looks like in perspective.
A couple of months ago I realized I run way too many parallel Claude Code sessions.
Some are rapid-fire sessions where I’m iterating on code quickly. Others are slow burners that sit around for days while I context-switch to other work. The problem: when you come back to one of those slow sessions, you get that familiar moment of staring at the transcript thinking, what was I doing here again?
Claude Code doesn’t help. There’s no at-a-glance “this session is about X” indicator. You end up scrolling up, re-reading, trying to reconstruct context like you’re debugging your own brain.
So I built a thing.
Comments