Putting my homedir on Bitbucket

(or at least, part of it…)

In a previous blogpost I mentioned that I use Git to manage my ‘dotfiles’. In this blog I will try to give a little more insight in how it works, why it’s useful and what I learned from it.

What are these ‘dotfiles’ anyway?

If you are reading this blogpost I expect you know what dotfiles are. But to those who don’t know: when we talk about ‘dotfiles’ we usually talk about configuration files and directories in your home directory on a Unix/Linux/Mac system. These files usually have a dot at the beginning of the filename, which makes them hidden by default.

Why would I put those files in a Git repository?

Most people I know have more than one computer. If you happen to be a developer or sysadmin, you not only have to deal with your computer(s), but also with various servers you might have access to. You’re also likely to spend a good amount of time on the command line, and you might have a certain preference for how your prompt should be set up, how your shell should behave, which terminal multiplexer (screen, tmux) you use and how it should look, and of course all configuration related to your favorite code editor.

Now that you’ve grown accustomed to your personalized setup, not having that setup available everywhere isn’t just inconvenient, it is seriously impairing your productivity. By putting your setup in a Git repository, setting up your environment on a new machine is a matter of cloning the repo and running install.sh.

Also, whenever you change something to your environment on your work machine, you commit it, push the changes, and when you get home you pull the changes on your personal machine.

Deploying dotfiles

One of the first problems I encountered was deployment of the dotfiles. I could copy them into place, but how would I handle changes? I could just set up my entire home directory as a Git repository, but that would make git add . very, very dangerous. I opted for symlinks. My Git repository resides in $HOME/git/dotfiles and all files in $HOME/git/dotfiles/dotfir/* are symlinked to $HOME/*. Any files that already exist are moved to $HOME/<filename>.old. This way, changes are made directly in the Git repo, and when I pull new changes, they are immediately active.

OS support

I am a Mac user, but virtually all servers I work with are running some flavor of Linux. That means my setup needs to work on both OSX and Linux. In most cases, that will not be a problem, but my Bash config needed a lot of tweaking (and still isn’t perfect yet). Configuration of colored output of the ls command is handled completely differently, some commands take different arguments, and some aliases simply apply to a single OS. Then there are the various configuration files of the shell itself. Do we need .profile, .bash_profile, or .bashrc? And in which order should they be parsed? For now, I’ve opted to use just .bash_profile and just remove the other two, and that was fine until I installed RVM, which simply added a new .profile. I needed to clean that part up by hand.

Performance

Usually, I’m not worrying too much about performance when it comes to Bash, screen or Vim. That is, until I tried running my heavily customized Vim setup on my Raspberry Pi.

SSH configuration

In theory, I could have added my .ssh directory to my Git repository. After all, I can use HTTPS for the initial clone, and Bitbucket offers private repositories, so it’s not like you’re sharing your private key with the world.

But I didn’t. And if your SSH keys provide access to anything important, neither should you.

What’s next?

For now, I’m quite happy with my setup. Even though there are more advanced ‘dotfile-framework-tools’ out there, I don’t feel the need (yet) to use those. My installation script is simple but has worked everywhere I tried it so far, so why change?

How about that Vim setup?

I have mentioned my Vim setup a few times in various blogs now, and a few people have already asked me to share my Vim setup. Even though my Vim setup is a continuous work in progress, I am planning to do a blogpost dedicated to my Vim setup soon.