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:

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.

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 .

The problem # From time to time, I have scripts and binaries that I only really need on one system. Since the base dotfiles repo includes a bin directory (for dfm itself), if I just drop files in there, git continually shows me that they are untracked. For instance, if I have a script called only_on_my_mac, then running dfm status shows: # On branch personal # Untracked files: # (use "git add <file>.

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.

A couple days ago, I did a presentation on my dotfiles manager (dfm) at the local Perl Mongers meeting. It was a phenomenally rewarding experience. The Perl community has always been fun and engaging and this meeting was no different. Here’s the source for the slides and a PDF rendering for ease of perusing. It’s a good overview of current usage as well as a laundry list of future features.

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.