Ramblings of an aging IT geek
← Ramblings of an aging IT geek
tooling

my dotfiles, finally in order

After years of a tangled symlink script, moving my dotfiles to a bare git repo tracked against my home directory, and why the dullest approach turned out to be the best one.

A mechanical keyboard beside a terminal

For years my dotfiles lived in a repo with a hand-rolled install.sh that symlinked everything into place. It worked until it didn't, which was every time I set up a new machine and discovered the script assumed some directory existed, or clobbered a file it shouldn't have, or symlinked .config as a whole and broke three other things. The repo wasn't the problem. The machinery around the repo was.

This week I finally did the thing people have been quietly recommending for a decade: the bare git repo against $HOME. No symlinks, no install script, no framework.

git init --bare $HOME/.dotfiles
alias dot='git --git-dir=$HOME/.dotfiles --work-tree=$HOME'
dot config status.showUntrackedFiles no

That's the whole trick. The working tree is your home directory, the git directory lives off to the side, and dot is just git pointed at both. dot add .vimrc, dot commit, dot push. On a new box you clone it bare and check out, and your files land exactly where they belong because they were never anywhere else.

The showUntrackedFiles no line is the bit that makes it liveable, otherwise dot status drowns you in every file in your home directory. With it, the alias behaves like a normal repo that happens to only know about the handful of files you've explicitly added.

No yadm, no chezmoi, no stow. I'm sure those earn their keep for people managing secrets and templated configs across many hosts, and I may want that one day. But for one human with a laptop and a couple of servers, a bare repo and a four-character alias is the right amount of clever, which is to say almost none. The best tooling decision I made this month was deleting code.