What configuration do you have, and how much of it matters

On *NIX based systems, there are a number of places that your configuration might be found. Traditionally, system configuration can be found in /etc in a number of text files which are nominally human-readable and human-editable. The equivalent of those files for your specific user are found in your home directory, but rather than being conveniently kept in ~/etc they are typically kept directly in ~ but hidden from view. The *NIX idiom of hiding files from listings if they start with a full-stop (e.g. .xinitrc) means that your configuration files typically start with a full-stop and are thus referred to as your dot-files.

If you want to see just how many of these things there are, try comparing the output of ls ~ and ls -a ~. For me, the difference is 180 entries. Not every single one of those entries is a configuration file which I might care about. For example ~/.cache is simply where the applications you run store their cache data; and ~/.cabal is where your locally installed Haskell applications and libraries live. Both of those contain data it might be valuable to keep, but neither are very amenable to management outside of the tools and programs which write to them.

I like to separate configuration into that which I feel I need to keep (and/or keep synchronised between systems) and that which I do not mind if I lose. For example, I would be lost without my personalised ZShell configuration but would not lose very much sleep at all over my libreoffice personalisations going missing. In some cases this separation can also be made based on whether or not I wrote the configuration file by hand. I don't tend to feel that software-managed configuration files are precious.

How can you keep your configuration safe

Having decided which of your configuration files are precious, there now comes the realisation that, just like your programming projects, you need to keep your precious configuration files safe. And, as we have said before, that means both tracking changes and keeping copies.

There are a number of ways of achieving this. Some people like to treat their entire home directory as a revision controlled space, explicitly choosing to add files or ignore them as and when they turn up. For example, Joey Hess likes to do this, or at least he did when he wrote that blog posting. Some people like to keep specific bits of their configuration in revision control, such as John Wiegley's Emacs config. Others, such as myself, choose to keep their "precious" dotfiles in revision control. I do this in my git repository and amazingly so do Richard Maw and Lars Wirzenius -- anyone would think we were all friends who talked about this stuff a lot.

In the past I, and no doubt others (who perhaps persist in doing so to this day), kept my precious files in a tarball and periodically refreshed the tarball and sent it to my various systems. But in 1999 when I got my first real job, I was suddenly plunged into a situation where I had to deal with around 6 different platforms, in varying operating systems, across around 15 different machines and that's what finally caused me to take the plunge and keep my dotfiles in revision control. Initially I used Perforce since that was what was available at my place of work, but then I moved via CVS, Subversion, TLA and Bazaar-NG before finally ending up where I am right now (in Git).

Whatever approach you take, keeping your precious dotfiles safe will give you a sense of security and "home" whenever you have a new system you need to get a foothold in.

Keeping your safe-keeping safe

In all the above, I've not mentioned one of my favourite things -- security. You will be tempted to commit config files which contain passwords. You will be tempted to commit secret keys. You might be tempted to commit configurations which happen to leak secret information about your employer such as customer names in your folder list in your email configuration. There are a number of approaches to this issue. One is simply not to publish your dotfile repository for others to see. Another is to keep a separate clone of the repository and merge changes from your open repository to your private repository when you need to (my chosen approach). Finally you might choose to make full use of the functionality of your revision control system and have your private repository use something like git submodules to bring in your public repository as and when it needs to.

Whatever approach you choose, please remember to keep your private data private at the same time as you keep your precious configuration safe.