sobolevn's dotfiles install a macOS and shell setup with dotbot, minus the parts you comment out

The install is three commands, and the pruning happens first

The setup path is deliberately short, and the order of the steps is the interesting part.

Step zero comes before any command: decide what you want to install by commenting out the run_dotbot lines for the steps you do not need. The installation guide states it plainly, comment out run_dotbot 'steps/...' that you don't need.

git clone https://github.com/sobolevn/dotfiles dotfiles
cd dotfiles/
bash ./install

The clone, the directory change, then the install script. The pruning is presented as step zero, before the clone even, which tells you the intended workflow: this repository is a template you edit first and run second, not a package you install and then configure.

The mechanism is dotbot, a small shell-based dotfile manager, and the repository carries a dotbot directory and a dotbot-brewfile at the top level alongside the steps/ directory that holds the individual installation scripts. The README describes the project as using dotbot to set things up, and the top-level entry list shows config/ for the shell configuration files, shell/ for the shell-specific pieces, macos/ for the operating system settings, vscode/ for the editor, firefox/ for the browser, and crontab/ for scheduled jobs.

There is also a .gitmodules file, which means some parts of the setup are git submodules rather than plain files, and a CONTRIBUTING.md, which tells you the repository is set up to receive changes from other people.

The stated principles forbid auto-formatting and keep the history

The main principles section is short, and one line in it is a design constraint rather than a preference: please, do not touch my code, no auto-formatting or code flow interruptions. Anyone porting this setup to their own work should note that, because it is the opposite of what most editor configurations do by default, and it changes how the tooling feels.

The rest of the principles read as a single coherent stance. Minimalism in everything, tooling and styling. Simplicity. Reduced visual noise, only important things should be shown. History is valuable, let's preserve it everywhere we can. And security: do not share anything with anyone.

That last one has a practical consequence for a dotfiles repository, and the repository is careful about it. The description of the setup covers what a reader gets: all brew dependencies including applications and fonts in the Brewfile, all macOS configuration, all shell configuration including a custom sobole zsh theme, all vscode configuration including a custom pustota theme, and the firefox settings.

The home page is the author's own site, and the project also links to a set of articles about the environment and to talks and podcasts about it. That context matters for reading the repository: it is a published record of one person's daily environment, and the code reflects the specific tools that person uses.

The shell stack is zsh, oh-my-zsh, zplug and fzf

The command line setup is where most of the opinions live. The shell is zsh with oh-my-zsh, and plugins are managed with zplug through a zplugrc file in config/.

The tool list is where the minimalism principle gets tested, and the author is explicit about it: there are some tools, scripts and aliases to make the working experience better, but he tries to keep them minimal, only the ones he truly uses. The named tools are bat, zoxide, fzf, ag, fd, delta and gh. fzf carries most of the weight, and the configuration explains why.

There is a completions directory in shell/ that wires fzf into several commands, with fzf-tab handling tab completion, and custom completions for zoxide, make and killall using fzf's preview feature. On top of that sit three keybinds: ctrl+r for fuzzy search of command history, ctrl+t for fuzzy search of files and directories in the current tree with instant previews for text files and directories, and ctrl+g plus subcommands such as ctrl+l to open fzf-simple-git for git browsing.

For in-terminal editing, the choice is a powered-up nano with a nanorc file in config/. That is a deliberate move away from a modal editor for quick edits, and the contrast with fzf-driven workflows is worth noting: the same setup that leans on fuzzy finding for the shell uses a plain editor for changing text.

The main language is python, with node, elixir, rust and c installed but not used daily.

VS Code is configured around a theme the author also wrote

The editor section explains a migration rather than a fresh setup. The author previously used Sublime and calls it fast and beautiful, but the main reason for the switch is that Sublime is almost unmaintained, and its packages are also abandoned. The replacement is VS Code, installed through a Homebrew cask, and the stated effect is that it solved almost all the issues with Sublime.

The setup is deliberately small. The listed packages are pustota, the author's own theme, the Python plugin, editorconfig integration, and subframe7536.custom-ui-style for better customization. The author says he tries to keep the vscode setup as simple as possible, and the configuration was heavily influenced by makevscodeawesome.

Three keybinds carry most of the navigation weight, and each one is about not moving your eyes. cmd+p opens file navigation in the middle of the screen so you do not have to move your eyes to find the most common UI element, ctrl+f opens global search, and cmd+t opens the global symbols index.

The pustota theme and the sobole shell theme are separate repositories by the same author, and the same is true of the senya terminal theme and fzf-simple-git. That is a meaningful dependency for anyone adopting this: the dotfiles point at four or five personal projects, so a fork of this repository is not self-contained unless you also decide what to do with those references.

Homebrew carries apps, fonts and the App Store purchases

Package management is consolidated into one file. The author uses brew to install all free apps for his Mac, and syncs App Store apps with brew via mas, so the resulting Brewfile contains everything, including applications and fonts.

The Brewfile is also where the VS Code extension list lives, described as a list of packages with the vscode calls at the bottom of the file. So one file is the single source of truth for what is on the machine, which is a sensible design for a dotfiles repository: after running the install, the Brewfile is the inventory.

The consequence for an adopter is scale. A Brewfile that includes applications, fonts and casks is not a lightweight list of command line tools, and the install will pull in things you may already have, including GUI applications that a minimal server or container environment has no use for. That is the trade-off of the one-file approach, and it is the first thing to check before running the installer on a machine you care about.

The browser layer follows the same consolidation idea. The author uses the zen browser as his main browser, notes that it has no visible UI even in regular non-fullscreen mode, and hardens it with arkenfox for extra privacy. Since zen is based on firefox, the firefox/ configuration in the repository can be copied and used with regular firefox.

Infrastructure is containerized, and the licence is not a standard one

The infrastructure section states the intent directly: the author tries to containerize everything, with docker as the main development and development tool. The README is truncated in the middle of that sentence, so the detail of how the Docker setup is arranged is not visible here.

The top-level entry list adds a crontab/ directory to the picture, which means scheduled jobs are part of the managed configuration, and the .gitmodules file indicates that some directories are submodules. Combined with dotbot, steps/, config/ and shell/, the repository is a full machine description rather than a collection of shell aliases.

The licence needs attention. The repository's licence is recorded as a custom licence that GitHub cannot classify, with the LICENSE file at the root as the reference, which is different from the MIT, BSD or Apache licences that a dotfiles project would normally carry. That is worth reading in full before you copy this setup into a work machine, and it is a real distinction from a repository released under a standard permissive licence. Nothing here is legal advice, but the practical point is that you should not assume the terms are the ones you are used to.

On maintenance, the repository is not archived and the last push was on 2026-10-07, so the configuration is being kept current. There are no GitHub releases, which is normal for a dotfiles repository where the branch is the artifact, and the same applies to the tags you would use to pin a version.

Editorial conclusion

These dotfiles fit a macOS developer who wants a complete, coherent environment rather than a menu of fragments, and who is willing to read the steps directory before running anything, since the install script writes to real system locations. They do not fit a Linux user without editing the macos/ steps, and they do not fit anyone who wants a maintained base to build on, because the licence is a custom one rather than a standard permissive licence. Before adopting it, open the LICENSE file at the repository root, read the steps/ scripts you have not commented out, and check the Brewfile against the tools you already have, since the installer pulls applications, fonts and casks along with the command line tools.

Frequently asked questions

Official sources

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