Olical dotfiles and a chezmoi-managed Linux workstation

What chezmoi changes about the shape of a dotfiles repository

The repository is managed with chezmoi, and that single fact determines most of the design decisions in it.

The top-level entries explain the convention. There is a .chezmoi.toml.tmpl, which is chezmoi's template file for configuration, and a .chezmoiignore, which controls what chezmoi should leave alone. Then there is a dot_config/ directory, and the name is the encoding: chezmoi writes a source file named dot_config to the destination .config, so the directory tree in the repository is a mangled version of the tree you end up with. There are also dot_gitconfig and dot_gitexcludes, which become .gitconfig and .gitexcludes.

That naming is unpleasant to read once and then invisible forever, because the mapping is mechanical and the alternative, a repository of literal dotfiles, is what makes dotfiles repositories hard to review. The value of the template repository is that a change to the source is a change you can see in a diff and a commit, rather than a change you make in your home directory and forget.

The .tmpl extension on the configuration file is the other half of the mechanism. It means the configuration is a template rather than a static file, which is what lets one repository produce different files on different machines without branches.

The primary language listed for the repository is Fennel, and that is an unusual entry for a dotfiles project. Fennel is a small Lisp that compiles to Lua or JavaScript, and its presence suggests that part of the configuration is generated rather than written by hand. The repository root does not expose a scripts directory, so the generated pieces are likely small and specific rather than a whole toolchain written in Lisp.

The audience is a single user, and the readme says so plainly, with the personal nature of the configuration showing in the systemd unit names, which are named after the account rather than after the service.

The package philosophy, which is the real content

Four rules govern where every binary comes from, and this list is the most reusable thing in the repository.

The first is that main Fedora dnf is the default for everything available there. The second is Homebrew for anything not in the main Fedora repositories, and it says Homebrew is preferred over COPR. The third is COPR only when brew does not have a Linux package, with ghostty given as the example. The fourth is curl scripts only as a last resort when neither dnf nor brew has the package.

The ordering is the point. It establishes a default that is native to the distribution, an escape hatch that is uniform across projects, a narrower escape hatch for packages that need a personal or third-party build, and a final fallback that has no package metadata at all.

That last tier is where the real risk sits, and the readme is honest about it. The one curl script in the setup list is the Claude install script, and the comment above it says no brew formula is available yet. A script piped into a shell with no version pin and no checksum is the weakest link in an otherwise careful supply chain, and it is the reason the readme keeps it to a single documented instance.

There is a small inconsistency worth noticing. The philosophy says Homebrew is preferred over COPR, and the first-time setup installs ghostty from COPR while the comment notes it is not in the main Fedora repos and is desktop only, not for headless hosts. The practical effect is that on a headless machine you get a different toolset, which is the right call but worth knowing before you compare two machines.

The topics include arch-linux alongside fish, neovim and vim, which is a reminder that the package policy is Fedora-specific. The installation commands are dnf and dnf copr throughout, and the Homebrew install is the Linuxbrew script pointed at /home/linuxbrew. A repository of someone's own workstation is a statement about one machine, and the instructions are the evidence.

The daily loop and the first-time setup

Two separate workflows are documented, and the split between them is the useful part.

The daily usage is four commands. chezmoi update pulls and applies the latest changes to the repository. chezmoi re-adds changed files from your home directory back into the chezmoi source, which is how a configuration you edited by hand gets committed. chezmoi cd drops you into the source repository for git operations. And sync updates system packages and Neovim plugins, which is a wrapper for the two package systems rather than a chezmoi operation.

The re-add step is the one that matters most for anyone adopting this pattern. Without it, every configuration change you make in your home directory is a change chezmoi does not know about, and the next chezmoi update will overwrite it. The workflow only works if the direction of travel between your home directory and the source repository is explicit, and re-add is what makes it explicit.

The first-time setup is a longer list, and the order is the ordering of the package policy again. The development tools group and the base utilities come first, then the Linuxbrew install script and the eval that puts brew on PATH for the session. Then the main Fedora repo packages, listed one per line: neovim, helix, fish, difftastic, syncthing, tailscale, gh, bat, fzf, zoxide and htop. Then ghostty from COPR, which is marked as desktop only and not for headless hosts. Then the Homebrew set, which is the list of tools deliberately not in the Fedora repos: lazygit, mise, sops, age, topgrade, yazi, zellij, duckdb, fisher and a tap for chojs23. Then the systemd units are enabled for syncthing and tailscaled, tailscale login runs, and the Claude install script goes in under the no brew formula available yet comment. The last line changes the login shell to fish.

The fish finishing step is short: exec fish, then fisher update to install the fish plugins including the tide prompt from the fish_plugins file, then mise use -g usage to generate the mise completions and a redirect that writes them into the fish completions directory. That last redirect is a nice detail, because it means the completions are regenerated as part of setup rather than being a file somebody remembered to commit.

The toolchain the package list implies

The first-time setup list is short enough to read as a description of a working environment, and the shape of it says more than the individual packages do.

The editors come in three. Neovim and Helix are both installed from the main Fedora repositories, and Helix is the one that is usually a compromise in a setup like this, installed because it is a fast, batteries-included alternative for the times when a Neovim configuration needs fighting. The fish shell is the third, and it is installed from the same repository, with the shell change at the end of the setup making it the interactive default.

The terminal is Ghostty, and it is the only tool in the Fedora list that comes from a COPR, with the comment noting it is desktop only and not for headless hosts. That exception is the tell. A terminal emulator is a graphical application, and the person who wrote this list runs headless machines as well as desktops, so the desktop-only tool is marked as such rather than installed everywhere.

The rest of the list is the working set. difftastic, bat, fzf, zoxide and htop are the standard replacements for diff, cat, find, cd and top. gh is the GitHub CLI, syncthing and tailscale handle file sync and networking, and they are the two that get systemd units enabled with --now, so they start on their own rather than being started by hand.

The Homebrew set is the interesting part, because it is the list of tools the Fedora repositories do not carry. lazygit for git, mise as a version manager, sops and age for secrets, topgrade for system updates, yazi as a file manager, zellij as a terminal multiplexer, duckdb as an embedded database, and fisher as the fish plugin manager. A tap for chojs23 is also in the list, which is the mechanism for a package that is not in Homebrew core.

What this adds up to is a workstation where the distribution provides the basics and the tooling that has to be current comes from Homebrew, with a COPR for the one graphical application the distribution cannot supply. The reasons for each choice are not written down, but the list is specific enough to be a reasonable starting point for a Fedora machine of your own.

New machine setup, and what this repository does not cover

The shortest path in the readme is the new machine setup, and it is worth quoting in full because it shows the intended relationship between the repository and the machine:

sudo dnf install chezmoi
chezmoi init --apply Olical

Two commands. The first installs the tool that manages everything else, and the second points it at the source repository and applies it. The --apply flag means the files land immediately rather than waiting for a separate chezmoi apply, which is the difference between a two-command setup and a three-command one on the day you are setting up a machine.

What the repository does not cover is equally informative. There is no install script. The first-time setup is a list of commands to read and paste, not a program to run. There is no dotfiles bootstrapper, no Ansible role and no container image.

That is a deliberate division. chezmoi applies files; it does not install packages, and this repository keeps those two jobs separate. The first-time setup section is the manual counterpart, and it exists because package installation is the part that needs a human to make judgement calls: whether this machine is a desktop or headless, whether it needs the syncthing and tailscale units enabled, whether the Claude install script is acceptable on this particular host.

The most important thing to know before adopting any of this is that it is one person's configuration. The dot_config/ directory is the actual content and the readme does not describe it, so you would be reading the tree to see what is configured, and the documentation you have is about how the tooling is wired rather than about what each setting does.

The homepage is oli.me.uk, the repository is not archived, and the last push was on 2026-10-19, so it is maintained as a working system rather than archived as a reference.

Editorial conclusion

Olical dotfiles is a good fit for a Fedora user who wants a reproducible workstation with a defined answer to where each tool comes from, because the package philosophy is written down and enforced by the setup script rather than left to whoever is configuring the machine. It is a poor fit if you are on Arch, despite arch-linux being one of the repository topics, since every installation command in the readme is a dnf command, and a poor fit if you want a full end-to-end installer, because the first-time setup list is a curated set of packages rather than something that adapts. Before adopting, read the package philosophy list and decide whether you agree with Homebrew on Linux at all, since that choice determines whether most of your tooling comes from a Red Hat repository or from a macOS-oriented package manager.

Frequently asked questions

Official sources

1. Issues
2. Olical/dotfiles on GitHub
3. Project website
4. README