This is my dotfiles repo. There are many like it, but this one is mine.
It is laid out exactly how it goes in the $HOME
dir.
git clone --bare https://github.com/john-kurkowski/dotfiles.git $HOME/.dotfiles
alias dotfiles='GIT_DIR=$HOME/.dotfiles/ GIT_WORK_TREE=$HOME git'
dotfiles config --local core.worktree $HOME
dotfiles config --local status.showUntrackedFiles no
dotfiles config --local user.email john.kurkowski@gmail.com
dotfiles checkout
# If not a personal device
git config --global user.email john.kurkowski@company.com
# If zsh is not the default shell
chsh -s zsh
dotfiles pull
The dotfiles are now in your home folder, in the conventional location. Your tools automatically pick them up.
To interact with version control, instead of using git
directly, use the alias
dotfiles-env git
, or dotfiles
for short. For example, dotfiles add -p
,
dotfiles commit -v
.
Why the alias? While there are a lot of bespoke tools to
version control and ship your dotfiles to your $HOME
dir, you probably already
use Git. With a bare Git repo and an alias, Git can manage your dotfiles'
lifecycle for you. Same interface as
git
. No extra, bespoke tool. The repo layout stays in sync with how the files
are used.
See the docs folder.
My development workhorses are the terminal and Vim. They make up the majority of
the custom code in this repo. Their entry points are .zshrc
and .vimrc
,
respectively.
These tools are what I'm productive with. Use whatever IDE makes you productive. Keep investing in and sharpening your tools to shorten the feedback loop. The quicker it is to try an idea or to cross reference it, the quicker it is to improve upon or discard.1
Hacking dotfile configs yourself carries the risk of making the configs idiosyncratic, so they're high cost to the author and they don't benefit others. It's a balance. When building a custom prompt, it can be full of inscrutable symbols and directives. When you see this, outsource to plugins. Then the majority of the custom code becomes listing plugins and configuring them. I strive to show this in this repo. Plugins do the thing 90% as good as the best dotfile hacker, with little code to maintain. Hitch your wagon to the community. Functionality is an asset. Code is a liability.
The other files here configure miscellaneous tools, which come up for schleps and experiments with little convention.2 They should be the exception rather than the rule. Prune your unused dotfiles and plugins regularly.
1. While programming, keep in mind, programming doesn't have to be this way. It can be better. See Inventing on Principle.
2. Their configuration should be explicit in the projects that
use them. This enforces consistency across collaborators. It reduces project
holy wars. Copy a dotfile like .editorconfig
into the root of
your project, so all collaborators can agree on e.g. spaces vs. tabs, and
trailing whitespace. Or .eslintrc.js
to enforce the best parts of
JavaScript, pylintrc
for Python, etc. Use CI to enforce the
dotfiles.