# bashbunni dotfiles: a Stow managed desktop config in Lua > A personal dotfiles repository laid out as GNU Stow packages for Emacs, Neovim, i3, polybar, tmux and zsh, with a NixOS configuration that is copied rather than symlinked. The instructions assume you are willing to adopt and overwrite your own settings. **bashbunni/dotfiles** — My config/dotfiles for tmux, nvim, i3, bla bla bla, nerd things. - Repository: https://github.com/bashbunni/dotfiles - Stars: 620 · Forks: 32 - Language: Lua - License: not declared - Published: 2026-10-22 · Updated: 2026-10-22 · Language: en - Canonical page: https://hysenlabs.com/projects/bashbunni-dotfiles ## The repository is a set of Stow packages, not a flat config dump The organisation is the whole point. The README explains that the author moved to GNU Stow to manage the dotfiles with symlinks, and that the directory structure should be laid out relative to the dotfiles directory as if it were the home directory. The tree below is the actual layout, and each top level entry is one Stow package. ```sh ├── banner │   └── banner ├── doom │   └── .config │   └── doom │   ├── config.el │   ├── custom.el │   ├── init.el │   └── packages.el ├── polybar │   └── .config │   └── polybar │   ├── config │   ├── launch.sh │   ├── power.sh │   └── scripts │   └── weather.sh ``` The rest of the tree continues the same way, with a package per application and the home relative path preserved inside it. ```sh ├── nvim │   └── .config │   └── nvim ├── i3 │   └── .config │   └── i3 │   ├── config │   └── config-old └── zsh └── .zshrc ``` Because each package carries its own home relative path, `stow doom` produces a symlink at ~/.config/doom pointing into the repository, and `stow` for the zsh package produces ~/.zshrc in the same way. That indirection is what lets the author keep a single copy of a file and still have it appear in the right place. ## Adopting a local config is where the risk sits The README is direct about this. If you already have a config you want to keep, you create the dotfiles repository and then run `stow .zshrc --adopt`, and the warning is given in capitals: the --adopt flag will overwrite the contents of your current directory with the contents from your target directory. Mechanically, --adopt moves your existing files into the repository and replaces them with symlinks, which is what makes the repository the source of truth afterwards. The README describes it as careful, and it is: run it against the wrong path and your working configuration is gone. The author mitigates this in practice by keeping a copy in git, since the repository itself is the backup and `git restore` puts the previous version back. The repository top level lists banner/, doom/, fish/, gitconfig/, i3/, nix-helpers/, nix/, nvim/, polybar/, sway/, swayfx/, tmux/, waybar/ and zsh/, so there are more packages than the tree in the README shows, and the tree is a simplified view rather than the full list. ## A fresh machine, one package at a time The README describes the path for a machine that already has an existing configuration for a package. You clone the repo and change into it. Then, for each package you want symlinked, you run `stow `, adding --adopt if that package already exists on the machine, which creates a symlink for the package into your dotfiles repository. The third step is a choice about which version wins. If you want to use the config you had previously stored in the repository, run `git restore `, or `git restore .` if you want the whole tree back to its committed state. If instead you want to overwrite the neovim config stored in the repository with the one currently at ~/.config/nvim, skip the restore. Those three lines create the three symlinks and nothing else. They do not install Emacs, Neovim or i3, they do not fetch plugins, and they do not touch your shell profile unless you stow the zsh package. The one thing to be careful about is that the stow commands must be run from the repository root, since the package names are resolved relative to the current directory. ## Doom Emacs expects xclip on X11 and pbcopy on macOS Clipboard support is the one piece of configuration that depends on the host system. On X11 you need xclip installed, and the README says the author installed it through the Emacs package mechanism with ` package install` and then `xclip`. On macOS the equivalent is pbcopy, installed with ` package`, and the configuration snippet turns it on. ``` emacs-lisp ;; use system clipboard (require 'pbcopy) (turn-on-pbcopy) ``` The rest of the Emacs setup is the usual Doom workflow: take the config and run `doom sync`, with the caveat that some packages may be missing and can be added with ` package-install`. The doom package in the repository holds config.el, custom.el, init.el and packages.el, which is the standard split for Doom Emacs where packages.el lists the package set and custom.el holds your own additions. ## Neovim is pinned to a nightly build because of plugin features The Neovim section starts with a cleanup step that is easy to miss. If you already have a Neovim installation, you delete any existing runtime dir you have for Neovim so the new version does not error, and the README names the path as usr/local/nvim/runtime, with a pointer to the :checkhealth output of your current install to confirm where that path actually is on your machine. The build itself is the nightly version, installed from source, because some plugins the author uses require the latest features. The README is candid that they cannot remember exactly which ones, and mentions treesitter as a possible example. The plugin manager is Packer, and after running `nvim` you run `:PackerSync` or `:PackerInstall` to pull in the plugins. There is a parenthetical note that this needs double checking on a fresh install, and a final step of `:TSUpdate` because treesitter is described as fussy. So the first run of the Neovim config is not a single command. It is a nightly build, a plugin sync and possibly a treesitter update. ## Tmux plugins arrive through tpm, and the keys are unmemorable The tmux setup is four steps: install tpm, add plugins to ~/.tmux.conf, run tmux or reload the environment with `tmux source ~/.tmux.conf`, then install the plugins with `prefix + I` where the prefix plus capital i is the install shortcut. That is the standard tpm sequence, and the README links to the tpm installation page rather than restating it. The Yubikey section is short but concrete. When creating a new SSH key you can use `ssh-keygen -t ed25519-sk -O resident` to get a 2FA SSH key stored on the Yubikey, with the resident option meaning the key data stays on the device rather than only in the private key file. The repository also carries sway/, swayfx/ and waybar/ alongside i3/ and polybar/, which means the desktop layout spans both the i3 and the Sway generation of setups. The README does not cover installing or configuring those, so they are there for the author rather than for you. ## The NixOS entry is the unfinished part The configuration.nix file at the repository root is the one configuration that is not managed by Stow. The README says the author currently just manually copies the config file into the repo, that it is not currently symlinked like the other config files, and that it could definitely use a clean up, but that is a problem for a future version of the author. The NixOS notes themselves are thin. Packages are found at search.nixos.org, and updating means running `sudo nixos-rebuild switch` to rebuild the nix configuration and update the packages added to /etc/nixos/configuration.nix. This is where the repository is weakest as a template, and it is worth being clear about the limits of the whole project. The repository has no licence file among its top level entries, so the licence status is unstated, and the only tagged release is v0.1.0 from 2022-12-11, described as a working version of the Lua config. The last push was on 2026-09-04, so the tree is being worked on, but there is no release cadence to upgrade against and no test suite to tell you whether a change broke your setup. Adopting it means adopting a snapshot of somebody's personal machine, and the copy-and-paste steps in the README are the price of that. ## Conclusion This repository suits someone who wants a working Linux or macOS desktop configuration built from Doom Emacs, Neovim, i3, polybar and tmux, and who is comfortable adopting a personal setup that was tuned on someone else's machines. It does not suit a team that needs a supported, licensed, reproducible baseline, and the NixOS entry is the least finished part. Verify first that your platform matches, then stow one package at a time and inspect the symlink before stowing the next. ## FAQ ### How do I install the bashbunni dotfiles on a new machine? Clone the repository, change into it, and run stow for each package you want symlinked, for example stow doom or stow nvim. Add --adopt when that package already exists on the machine, and run git restore if you want the committed version of those files to win. ### Is it safe to use the --adopt flag with GNU Stow for these dotfiles? The README warns in capitals that --adopt will overwrite the contents of your current directory with the contents from your target directory. Because the dotfiles repository is under git, the previous configuration can be brought back with git restore. ### How are the Neovim plugins in this dotfiles repository installed? The configuration uses Packer. After installing a nightly Neovim build and running nvim, you run :PackerSync or :PackerInstall to install the plugins, and you may need to run :TSUpdate for treesitter. ### Does this dotfiles repository include a licence file? The top level entries list a README.md, a .gitignore and the configuration directories, and no licence file appears among them, so the licence status is not stated in the repository. ## Sources - [bashbunni/dotfiles on GitHub](https://github.com/bashbunni/dotfiles) - [Issues](https://github.com/bashbunni/dotfiles/issues) - [README](https://github.com/bashbunni/dotfiles/blob/main/README.md) - [Releases](https://github.com/bashbunni/dotfiles/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/bashbunni-dotfiles