I recently split dfm out into its own git repository. This should make it easier to add new features and grow the test suite without cluttering up the original dotfiles repository. I’ll sync dfm over at regular intervals, so anyone who wants to keep up to date by merging with master will be ok. I also just finished up a major new feature: dfm can now import files. So instead of:

Subversion is a useful tool. It does most of what I need it to do, but sometimes there are missing features. Sometimes, it’s something that git does natively. Other times, it’s a repeated command sequence. It’s easy to write small scripts to do these new things, but they never feel like they fit in with the rest of the commands. I’ve always been fond of the way that git can be extended by simply creating a script with the right name; git-foo [args] becomes git foo [args].

Well, I was going to write about a nifty bit of bash to help with ssh-agent in tmux, but someone beat me to it, so I’ll just write up his idea instead. Every once in a while, it’s nice to have a bit of bash initialization that only runs on one system. You could just throw that at the end of the .bashrc for that system, but that’s not very persistent.

I’ve been using git_backup to back up the websites I run for quite a while now. It works well and I only need to scan the daily cron emails to see if the backup went well or if there were any odd files changed the day before. One thing that I didn’t expect when I started using it was how it would enable developing those websites in a sandbox without any danger of affecting the production instances.

Most of the time, when looking at history in a git repository, I am most interested in changes at a higher level than an individual commit. From time to time, however, I really want to look at each commit on its own. So, I created git-walklog. For each commit in the range specified, it: Shows the standard log format: author, date, and commit message. Then it waits for input. Hitting enter then runs git difftool on just that commit, showing you any differences in your configured difftool 1.

Last year, when I made my list of pros and cons comparing git subtrees with submodules, one of the downsides listed for subtrees was that it’s hard to figure out where the code came from originally. Well, it seems that the internet hasn’t been sitting on its hands. While the main repository remained stable, a couple forks took it upon themselves to teach git-subtree to keep a record of what it merges in a .

Problem # I copy and paste all the time. Most of the time, I copy short pieces of information that are too long to type (I’m lazy) but too short to setup anything more complex (wget, scp, etc.). For a while, this was fine as most of my copy targets were either local to my system or in a terminal window on a remote server. However, as I increased my use of splits in tmux and windows in vim, highlighting remote text with my mouse became horribly cumbersome.

In my dfm talk a couple weeks ago, I listed out some low hanging fruit; just a few things that I thought would be easy to add to the system. Well, this past weekend, I went to the jQuery conference in Boston. It was a great conference in its own right, and I hope to post on it this week, but for now I want to talk about the improvements I made to dfm while on the plane.

After a few months of managing my dotfiles with git, I felt the need to organize my vim plugins a little better. I chose to use pathogen (created by Tim Pope), which allows me to keep each plugin in its own subdirectory. It fits well with using git to manage dotfiles because git has two ways of tracking content from other repositories. The first is submodules, which keep a remote URL and commit SHA1 so that the other content can be pulled in after cloning.

I have quite a few dotfiles. I have so many that keeping them in sync is impossible with conventional methods. So, I turned to my old friend: version control. For a while, I kept them in subversion at work. This worked well as that was where I spent most of my time. Recently, however, I’ve wanted those same dotfiles to be available at home and other non-work areas. So, I investigated moving them over to a git repository.

For a while now, I’ve been backing up the few WordPress blogs that I run for various people with a very simple script that followed this algorithm: Copy files to a temporary directory. Dump the MySQL data into a file in that directory. Tarball it up. Scp that file to another server that I run. At the time, I did this because it was the simplest thing that could possibly work.