This will be yet another description of dotfiles management by some random person on the Internet. I will try to explain what my setup is like and why it is that way.

If you're not yet using version control software for your configuration files I strongly encourage you to start doing so, whichever way you like. These pages are good places to start:

My chosen approach

After several attempts that have spanned across many years I've understood that neither tracking home directory directly with Git nor symlinking all of the dotfiles from a single directory tree is working for me. Both ways lead to a mess in the repository and made the whole endeavor of tracking changes cognitively expensive, so I inevitably started slacking off.

I've looked at the existing tools that are meant to automate some of the process and did not find one that would suit all my needs. I've ended up writing a small shell script that takes care of dotfiles installation but the main value for me is in the repo layout, not the script itself.

All configuration files are grouped into directories by topic. These directories are somewhat similar to packages in GNU stow. Topic directories recreate the directory structure for the target location, by default $HOME. Files that are meant to be installed into target location have to contain an appropriate suffix at the end of filename (any other files are ignored):

Default behavior may be altered by a dotfiles.meta file placed into the topic directory. It is essentially a shell script that is being sourced during topic installation. Its main purpose is to provide alternative values for PREFIX and SCOPE variables:

Multiple topics may be installed at once either by providing all of their names as command line arguments or by listing them all in a text file and providing path to that file as an argument to the installation script.


More examples may be found in my dotfiles repo.

Comparison with existing tools