What’s the deal with dotfiles anyway?

I have a collection of configuration files that I use to make devices essentially ephemeral. The names comes from the fact that a lot of them start with a ., which in unix makes it “hidden”. These files are stored in a globally accessible git repository that I can simply pull, run a single command and be right back at home.

I use an old unix utility called stow to manage my dotfiles due to its ubiquitous presence in various linux distribution package managers. It is usually one of the first programs I install on a new system (along with git of course). stow works by taking all the files and directories within a source - specified with -S <source> - and symlinking it to a target - specified with -t. For example, my bash configuration is stored in the root of the repo and the structure looks like this.

bash
├── .bash_profile
├── .bashrc
├── .config
│   └── bash
│       ├── aliases.bash
│       └── functions.bash
└── .local
    ├── bin
    │   └── nvimw
    └── fzf-tab-completion # git submodule
        └── ...

stow will then take .bash_profile and .bashrc and put symlinks to those directly in the target directory. For directories it will symlink from the deepest existing directory, which means that if .config does not exists the created symlink will be directly to .config, and if it does exist, it will symlink .config/bash.

My dotfiles are currently in a private repository, but the flow looks like this.

git clone <some-remote-hosting-dotfiles>/dotfiles
cd dotfiles
# I use some submodules so i also do the following
git submodule update --init --recursive 
stow -t$HOME -S *

At that point my new system ready to go and all I have to do is remember to push all the changes I make to my dotfiles all the time.

As a closing remark, a back-up version of my dotfiles can be found here if you are interested in having a look.