dotfiles

Portable shell configuration, synced across Debian and macOS machines.

Everything in $HOME is a symlink back into this repo, so editing a file here changes it everywhere the repo is checked out.

Install

git clone git@git.edwork.org:edwork/dotfiles ~/Projects/dotfiles
cd ~/Projects/dotfiles && ./dotfiles.sh

From a network that cannot reach git.edwork.org, clone git@git.whiskey.edwork.org:edwork/dotfiles instead — it is the same repo, and updates work either way (see below).

Existing real files are moved to ~/.dotfiles-backup/<timestamp>/ before being replaced — nothing is overwritten in place.

Updating

dotfiles          # pull, re-link, reload the current shell

The script is idempotent — run it as often as you like. A link that is already correct is left alone silently, so a quiet run means the machine is in sync. This is also how new files reach existing machines: add a line to LINKS in dotfiles.sh and the next run picks it up.

DRY_RUN=1 ~/.dotfiles.sh prints what would happen without touching anything.

Automatic updates

.zshrc and .bashrc check the mtime of ~/.edworkdotfiles on shell startup and run dotfiles if it is more than 30 days old.

File	Effect
~/.edworkdotfiles	Sentinel; its mtime is the 30-day clock. Touched on every run.
~/.edworkoffline	Kill switch. If present, auto-update never runs. disableupdate creates it.

The repo is served under two names, and the updater fetches from whichever answers: your configured origin first, then the other one if origin does not respond within 5 seconds. Only fetching falls back — origin is never rewritten, so git push still goes wherever the machine was cloned from.

URL
git@git.edwork.org:edwork/dotfiles.git	internal
git@git.whiskey.edwork.org:edwork/dotfiles.git	reachable from networks that cannot see the internal name

Being unable to fetch (offline, or both names down) is a warning, not an error — links are still reconciled from whatever is on disk, and the sentinel is still touched, so an offline laptop does not retry on every new shell. Git runs with BatchMode and a 5-second connect timeout per URL, so an unreachable server can never hang a new terminal; worst case a new shell waits 5 seconds per name before carrying on.

Fixing a client that cannot reach the server

A machine that already cannot see git.edwork.org will never pick the fallback up on its own — the code that does the falling back lives in the repo it cannot fetch. Those need one manual nudge, run once on the affected machine:

cd ~/Projects/dotfiles
git remote set-url origin "$(git config --get remote.origin.url | sed 's/git.edwork.org/git.whiskey.edwork.org/')"
dotfiles

That repoints origin at the mirror, and dotfiles then pulls — including the new dotfiles.sh — and re-links. Safe to run more than once: it rewrites nothing if the URL is already the mirror, and it keeps the rest of the URL as it is, so https clones and non-standard paths survive.

Only clients that are already stuck need it. Once a machine has the current dotfiles.sh, both names are tried automatically and origin can point at either.

Per-machine customisation

~/.local_aliases is created empty on first run, sourced last by both shells, and is not tracked. Machine-specific aliases, paths, and secrets belong there.

What's here

File	Links to
.aliases	~/.aliases — shared aliases and functions for both shells
.bashrc / .bash_profile	~/.bashrc, ~/.bash_profile
.zshrc	~/.zshrc
.gitconfig	~/.gitconfig — only when $USER is edwork; for any other user an existing link is removed
.htoprc	~/.config/htop/htoprc
.tmux.conf	~/.tmux.conf
.vimrc	~/.vimrc
.selected_editor	~/.selected_editor — Debian select-editor; inert elsewhere
dotfiles.sh	~/.dotfiles.sh

Shell history from both shells is unified into ~/.shell_history.

Many aliases (update, upgrade, memdiag, ports, ip) are Debian-only by design and are not expected to work on macOS.