hamvocke-dotfiles: a Linux desktop setup kept in one repository

What is actually in the tree

The repository is described plainly as a collection of my personal dotfiles, and the primary language is recorded as Vim Script, which is a clue about which part of it carries the most hand-written configuration.

The top level listing is a map of a complete Linux desktop. Terminal emulators have their own directories, alacritty, foot and ghostty. Editors have theirs, vim and nvim. The multiplexer is tmux, the window manager is sway, and there is also an i3 directory for the older tiling window manager arrangement. The shell is zsh, and the shell experience is tied to starship for the prompt. Then there is the toolchain: mise for managing language versions and tools, and a nix directory. Version control and remotes are covered by git and ssh, and there are directories for the everyday command line tools, bat, fzf and X/ for the X related configuration.

So this is not a vim configuration with some extras. It is a full desktop, and the fact that three terminal emulators sit side by side is the first sign of a person who moves between machines and wanted the same look in each.

The repository also contains a gnupg directory, which is the one entry that is not about looks at all. GnuPG is the encryption tool, and a gnupg directory in a dotfiles tree is a sign that the author keeps their key configuration under version control alongside everything else, which is a convenience with a security cost that anyone copying the layout should think about.

The default branch is master, the licence is not one GitHub could classify, and the last push was on 2026-10-18. There are no releases, which is what you would expect from a repository that is updated by push rather than published.

Installing with stow, or by hand with symbolic links

The installation is deliberately manual, and the two documented routes differ in what they give you.

The first step is always the same, cloning the repository into a dotfiles directory in your home:

    git clone https://github.com/hamvocke/dotfiles.git ~/.dotfiles

The manual route then creates symbolic links for the configurations you want to use, one per application, for example:

    ln -s ~/.dotfiles/vim/.vimrc ~/.vimrc

The GNU Stow route is the recommended one, and it needs stow installed first. The guide lists the four commands for the four common distributions:

    Mac:      brew install stow
    Ubuntu:   apt-get install stow
    Fedora:   yum install stow
    Arch:     pacman -S stow

Then the install is a directory change and one stow command per configuration:

    cd ~/.dotfiles
    stow vim
    stow tmux

The difference matters more than it looks. Stow works on the directory structure, creating a symlink for each file in a named subdirectory, so `stow vim` links everything under vim/ into your home directory. Doing it by hand means you choose which individual files to link, which is more work but more control, and it also means the linking step does not scale to a configuration with fifty files.

The other thing to know is that installation is only the first step. The guide says that some of the configurations need additional setup or configuration, and in that case you can find a README.md file in the application's directory, and to make sure you take a look at it to see what else there is to do. That is the pattern for the whole repository: the top level README gets you started, and each subdirectory carries the specific instructions for its own tool.

One colour scheme, inherited rather than repeated

The consistent colours section is the most transferable idea in the repository, and it is a solution to a problem that has become common.

The approach is to define the preferred colour scheme once at the terminal emulator level and then tell all applications to inherit those colours as much as possible. The problem being solved is that a lot of modern CLI applications think they are better off inventing their own way of doing things, which sometimes forces multiple colour scheme declarations to be kept in sync.

The practical implementation is to use Root Loops to find a colour scheme, set it for the terminal emulator of choice, and then use schemes for CLI applications that simply use the sixteen ANSI colours the terminal declares. Only when that is not an option, with fzf named as the example, does the author provide a custom colour scheme that matches the terminal scheme. The current setup is described as a specific Root Loops recipe, with its parameters given as a link with the sugar, colours, sogginess, flavor, fruit and milk values spelled out in the query string.

Root Loops is a generator for terminal colour schemes, so the whole approach is: pick a recipe, let it generate a scheme, and wire the terminal to it. The scheme is not written by hand in this repository, which is the point. A generated scheme can be regenerated with different parameters without editing anything, and the recipe link is the source of truth.

The sixteen-ANSI-colour constraint is what makes this work across a whole toolchain. Most modern CLI tools accept a palette of sixteen colours and map their own styles onto them, so a terminal that declares a good sixteen-colour palette gives you a consistent look across the shell for free. The tools that insist on a full twenty-four-bit palette are the exceptions, and the author keeps a custom scheme for those rather than trying to force everything to sixteen.

The fonts section is the companion decision. The author relies on Nerd Fonts in some configurations, which are special fonts with extra glyphs that let you display small icons and UI elements on the command line, and notes that you do not have to use them but that if you do not some things could look a little less good.

A window manager and a terminal, configured together

The configuration set is coherent in a way that is worth reading for what it says about a modern Linux desktop.

The window manager is sway, an i3-compatible tiling window manager, and there is also an i3 directory for the older arrangement. The terminal side has alacritty, foot and ghostty, three terminal emulators, and tmux for multiplexing inside them. The shell is zsh with starship providing the prompt, which is a common combination.

The presence of mise and nix together is the most interesting pairing. mise is a polyglot tool manager and nix is a package manager. Having both in one tree suggests a division of labour, with mise handling language versions and dev tools and nix handling the system, but the repository does not document that split, so the reader has to work it out from the directories.

Then there is X/ for the X related configuration, which is what a sway or i3 setup needs for the keybindings, and the miscellaneous tools: bat and fzf, fzf for fuzzy finding, and gnupg for encryption.

Two of these deserve a note on their own. fzf is the one application the author singles out as unable to inherit the terminal colours, which is a real limitation of the whole approach rather than a quirk, and bat and fzf are the two tools in most dotfiles repositories that carry their own configuration because they are more than a config file, they are a habit.

The screenshot in the repository shows the result, described as a preview with the Root Loops theme enabled, and the image is a tmux screenshot, which tells you the terminal and the multiplexer are where the visual result is most visible.

What this repository is and is not for you

The comparison worth making is with the two other ways to set up a Linux desktop from a repository.

The first is a distribution or a curated dotfiles manager, something like a framework that asks you a few questions and generates a complete desktop for you. That is better if you want a working environment and do not care what the decisions are. It is worse if you want to understand and change each piece, because the configuration is generated and the questions were answered by somebody else.

A personal dotfiles repository is the opposite of a framework. It is a record of one person's decisions, made over time, with the reasoning visible only partly. The reasoning here is visible in the README for the colour scheme, and absent for everything else, which is the honest description of the format.

The second comparison is with a from-scratch setup on your own machine. A personal dotfiles tree wins on the parts you would not think of, the fact that vim and nvim are both configured, the fact that there is a working sway setup, the fact that the colours match across the toolchain, and the fact that you can reinstall a machine in an afternoon. It loses on the parts where the tree encodes one person's hardware and taste, the specific terminal, the specific tiling behaviour, the specific prompt, none of which is right for you, and each of which you now have to unpick.

So the sensible way to read a repository like this is as a set of solved problems rather than as a configuration to install. The colour scheme section is the clearest case, because the problem, keeping the command line tools visually consistent, is general and the solution, generate one palette and let everything else inherit it, is general too. The window manager layout is not general at all.

The stow-based install makes that reading easier, incidentally, because stow is per-directory. You can take the colour approach, the shell and starship, and the fzf and bat configuration, and leave the terminal emulator, the window manager and the editors alone.

Editorial conclusion

Adopt this repository as a reference rather than as a package, because a personal dotfiles tree is a set of decisions made for one machine and one person's taste, and the install is a set of symbolic links rather than a supported upgrade path. Do not expect it to work as a drop-in, since each configuration directory may need its own extra setup described in a README inside it, and check first which colour scheme recipe the terminal is set to, because every other tool is expected to inherit it rather than declare colours of its own.

Frequently asked questions

Official sources

1. hamvocke/dotfiles on GitHub
2. Issues
3. README