A minimal dotfiles setup that survives reinstalls
Every Linux user eventually rebuilds a machine and spends the first afternoon re-tuning their shell, editor and terminal from memory. The fix is old and boring: keep your config in a git repo and stop treating a fresh install as a fresh start. The trick is doing it without the over-engineering that makes dotfiles repos rot.
Keep it boring
A dotfiles repo wants three things: it should be readable a year from now, it should set up a new machine in one command, and it should not need a framework to understand. That rules out the sprawling "do everything" setups. Mine is four files and a short install script.
.config/fish/config.fish— aliases, paths, a couple of functions. Nothing clever..config/nvim/init.lua— a lean editor config; if I can't read it tomorrow, it doesn't belong..tmux.conf— sane keybindings and a status line that fits on a laptop..gitconfig— identity, a few aliases, sensible defaults.
One command to rule the reinstall
The whole point is the bootstrap. A tiny install.sh that symlinks the files into place is enough for most people — no dependencies, nothing to learn. If you outgrow a shell script, GNU Stow manages the symlinks for you, and chezmoi adds templating and per-machine differences once you have more than one box to manage. Start with the shell script; reach for the others only when the pain is real.
Secrets stay out
Nothing private goes in the repo — no tokens, no keys, no machine-specific paths hard-coded. Keep those in a separate, untracked file the config sources if it exists. Your dotfiles should be safe to make public even if you never do.
The payoff
The reward is small and addictive: a new install, git clone, ./install.sh, and the machine feels like yours before the coffee is cold. It is not impressive engineering. That is exactly why it keeps working.
$ cat ./prev open-source and digital tools for planning an overseas trip