dotfiles

How the dotfiles are managed

This repository is a collection of configuration files the author uses across different machines. The management tool is chezmoi, which templates and applies dotfiles from a source repository to a target home directory. The README walks through the common chezmoi commands. You initialize with chezmoi init pointed at the git repository, add a file or directory with chezmoi add, review changes with chezmoi diff, and apply them with chezmoi apply. To pull remote changes you run chezmoi git pull with an autostash and rebase, then diff, or you run chezmoi update to pull and apply in one step. Navigating to the source directory is done with chezmoi cd, and chezmoi merge reconciles machine state with source state. The setup for a brand new machine is a single command that fetches the chezmoi installer and initializes and applies the configuration using the author's GitHub username. On macOS the same one liner first installs Command Line Tools if needed, then runs the chezmoi init and apply. This design means a fresh machine can be brought to a known state from one command, which is the main appeal of keeping dotfiles in version control in the first place. The diff and merge commands make it safe to experiment, because you can always see what changed before applying it to your live home directory.

Automatic sync with Dagu

Beyond manual chezmoi commands, the repository adds automatic synchronization, and that piece depends on Dagu. The README states that automatic sync also requires Dagu, and that the tool is already declared in the mise configuration, so you install it with mise install dagu before applying the dotfiles. Once in place, Dagu runs independent sync workflows for two things: the agent-vault directory under the home folder and the chezmoi source repository. Each workflow runs every 15 minutes. It commits local changes without GPG signing, fetches and rebases onto the configured upstream branch, and then pushes only when the local branch is ahead of the remote. The scheduler itself starts at login. On Arch Linux it runs as a systemd user service, and on macOS it runs as a LaunchAgent. The web interface is not started automatically; when you need it you run dagu server and open the local port in a browser. The README notes that both repositories must have a checked out branch with a remote upstream for the sync to work. If a rebase fails, the failure is left in place on purpose and a desktop notification is triggered, so the user can inspect the Dagu run and fix the conflict rather than have the automation silently force something through.

Platform notes and notifications

The repository handles Linux and macOS with some platform specific behavior. Linux desktop notifications rely on notify-send, which Arch provides through the libnotify package, while macOS uses the built in osascript for the same purpose. On macOS, applying the dotfiles also installs Homebrew if it is not already present, and then runs brew bundle from the included Brewfile to set up native applications where they are available. The README notes that Hyprland, Waybar, and a Linux webapp installer are skipped on macOS, since those are Linux specific and have no macOS equivalent. This conditional setup keeps one repository usable on both operating systems without breaking the macOS apply with Linux only tooling. Because the configuration is personal, the README presents it as the author's own setup rather than a general purpose distribution, and a reader is expected to fork and adjust paths and package lists to taste. The lack of a declared license is worth noting: without an explicit license, the default copyright still rests with the author, so reusing the files verbatim in another public repository is legally unclear even though the patterns are easy to copy. The Lua primary language tag reflects the Neovim and related configuration present in the set.

Editorial conclusion

The repository declares no license and is written mostly in Lua configuration files.