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.
Over the last seven months I’ve been building a startup, and our AI harness grew with it. Skills, agent definitions, slash commands, MCP servers. What started as a handful of files under .claude/ turned into something I could no longer hold in my head.
Once a month I sit down and clean it up. Cut the skills nobody calls. Simplify the ones that drifted. Rewrite agent identities that got too vague. Normal gardening.
You plan a route on Mount Shuksan for weeks, and three days out the forecast falls apart. Now what?
People who have climbed here for twenty years answer this from memory. Storm coming off the ocean? Go east of the crest. Marine layer? Head south. They have a mental database built from hundreds of weekends, some of them ruined.
I don’t have that database. I’ve been climbing in the Cascades for a few years, and when my primary objective gets stormed out, I have no honest basis for picking a backup. I could copy what more experienced friends do, but I wanted to actually understand it. I wanted an answer I could check against 20 years of records, not secondhand rules of thumb.
The result is Climbable.day, an interactive map that ranks backup objectives for any of 500 Washington peaks, conditioned on the season and the incoming weather pattern. This post is about how I got there.
I’ve been building Claude Code skills since November, one friction point at a time. A task I did twice became a command. A command I kept tweaking became a skill.
I went through my session logs and pulled usage numbers. For each skill I’m showing two stats: the percentage of active Claude days where I used it at least once, and the raw invocation count over the last four weeks.
Run env in your terminal. Everything you see there, your AI agent can see too.
Claude Code, Cursor, Codex, Windsurf, whatever you use. These tools run as processes on your machine with the same permissions as your shell. If you have AWS_SECRET_ACCESS_KEY in your .zshrc, the agent has it. If you have a .env file with database credentials, the agent can read it. If you exported a Stripe API key three months ago and forgot about it, the agent still knows.
This isn’t a bug. It’s how processes work on Unix.
Comments