Programming
GIT GIGGLE
Giggle has become my new best friend. Giggle is a graphical front-end for Git: you start it in a Git repository and it keeps excellent track of all of your branches, their history, mergings, and so on. Since one of my big initiatives in my current position has been refactoring an inappropriately large model class (multiple things being modeled in one class, and a metric ton of combinatorial excess around different kinds of people being modeled) and its attendent view (another, orthogonal mess of combinatorial excess about different lists-of-lists, not to mention a couple of one-shot views on the bottom that really need isolation), I've been making a variety of stabs towards cleaning them up.
Git tracks not versions but changes, and there are changes galore: one branch here is master, but there's _merge_roles _(take the five common roles in our model-- all of which have the exact same signature-- and provide a simple integer field for the role-type), merge_filters ("lists of lists" views partitioned into a get-list function followed by a generic draw-list function), new_toolbar (some advanced navigational features in the look'n'feel wrapper), new_homepage (break out those one-shots that need isolation), and new_deployment (our old deployment needed a bit of an upgrade).
If I were doing this by hand, I'd go insane with patchfiles. But with Git, it's simple. And with Giggle, I can actually see how simple it is.
There are some caveats, but they're more about using git svn than about using giggle. Always rebase, never merge, is probably the most important: Subversion has no idea what a git branch is all about, so as long as you rebase your master with whatever experimental branch you're bringing into the mainline before you run git svn dcommit, all will be well.