Chris Hannah

Using Stow to Make Managing Your Dotfiles Easier

As someone who regularly switches between various macOS and Linux machines, keeping my dotfiles synced everywhere gets a bit annoying. Fortunately, I've recently come across a tool called Stow from GNU, which helps you manage your dotfiles.

Stow, combined with a git repository, makes managing and syncing dotfiles between devices much, much easier.

To install Stow, you'll likely find it in your package manager under "stow". For example, for macOS running Homebrew, you'd literally just need to run brew install stow.


As for using Stow, it's probably useful to first know how it works. That way you'll have a better picture of how it ties everything together.

Let's take this scenario - you have your Neovim configuration saved under ~/.config/nvim like normal.

If you want to synchronise this between devices, then maybe you could just turn that directory into a git repository itself.

But if you have a bunch of configs for tools, some in .config, others inside your home directory, and some just plain config files mixed in there, it can get a bit messy.

That's where Stow comes in. You can have a central place where you store all your configurations for various tools. And then you can then choose to "stow" (load into the relevant directory) the configuration for whichever tool you want.

This means you can have one git repository, with a collection of individually defined packages, which then can be synchronised to various devices. And then on each of these devices, you can choose a subset of these packages to use.

Let's go back to a real world scenario again. Let's say this is your home directory:

.
├── .config/
│   ├── nvim/
│   │   ├── init.lua
│   │   └── lua/
│   │       └── stuff.lua
│   └── tmux/
│       └── tmux.conf
└── .zshrc

You can see there are three different things being configured, Neovim, tmux, and zsh. With Stow, you could have these as three differently defined packages.

Each package in stow, is defined by it being a directory with its name being the package name. Inside the directory would be the folder structure as if it were in the home directory.

This would mean, the above configuration inside a central dotfiles directory, would look like this:

.
├── nvim/
│   └── .config/
│       └── nvim/
│           ├── init.lua
│           └── lua/
│               └── stuff.lua
├── tmux/
│   └── .config/
│       └── tmux/
│           └── tmux.conf
└── zsh/
    └── .zshrc

With that dotfile directory, to configure all of these packages in the local machine, you would just need to run this command in the directory:

stow nvim tmux zsh

That command would then load all of the packages, by creating a symbolic link from all the relevant files and folders into the correct place.

To get an example, here is a screenshot showing my .config directory with all the symbolic links, and my .dotfile directory.

Just as a tip, the default behaviour of the stow [package] command, is that it works when you are in a directory that is one level below your home directory.

You can read the full capabilities of the stow command via the man page, or via the documentation. However, if you want a simpler life, you can just do what I do, and create a directory for your dotfiles like this: ~/.dotfiles/.


Once you start building up your collection of config packages, and tracking the directory via git, it becomes really easy to move between machines.

All you would need to do is to pull the git repository, and then use stow to load whichever packages you wanted to load on that particular machine.

You could even have slightly different versions of a given configuration, and then load a specific version based on the machine you were on. Maybe you have something that fits your use case at work or home, or even a different platform such as Mac or Linux.

Once you start using it, it doesn't take long until you start to feel the benefits.

Definitely looking forwarding to watching Gladiator II after watching the trailer. Although I must admit I didn't expect to hear a song like "No Church in the Wild" by Jay-Z and Kanye West. That threw me a bit.

Protocols, platforms and priorities →

It appears that the polarisation of social media is leaking into Micro.blog.

This tonal shift highlights what remains an issue with Mastodon. Unlike Micro.blog, it largely replicates the interface paradigms of Twitter, software fine-tuned for polarisation and outrage.

What's Holding Me Back From Android?

I've been creating a list of what I use my iPhone for, and what would happen if I switched to Android.

For most cases, it wouldn't make any difference. For example, for things like Notes, Email, Photos, etc. I use standard Apple apps, so I'd just as happily use Google apps.

For social networking, entertainment, and all the third-party stuff, everything is available on Android.

However, there are a few minor hurdles that could annoy me. They wouldn't necessarily stop me switching though. But they are things like iCloud Drive, Apple Photo sync, Universal Clipboard, AirPlay, etc.

All of those I can live without. However, even though all of my group chats are on iMessage, most private chats are on iMessage. So that would definitely cause some friction.

Therefore, when iOS gains support for RCS, and you can send photos across much easier between the platforms, there would be nothing major holding me to the iOS platform.

That's not to say I'd switch immediately, and never go back. But I'd certainly feel less locked in.

I do sometimes use a Pixel 6 as my main phone. But it's only ever been for a short period of time. So most annoyances don't really matter as I've usually still got my iPhone near me anyway.

But for a long-term switch. That's not only tempting, but also looking more possible by the day.

If I ever switch away from using an iPhone, it would cause a massive cascading effect on nearly every part of my digital (and some physical) life.

Simply because, if I could ever bring myself to break out of Apple's walled garden, I would want to steer clear of anything similar. I wouldn't want to just replace everything Apple with everything Google, for example.

And yet, as much as I can imagine this would be hard work, I wouldn't say it's a major part in why I still use an iPhone. And if I'm honest, the list of reasons is slowly getting smaller and smaller.

Last year I decided to upgrade to the big iPhone 15 Pro Max, after two years of the iPhone 13 Pro. And while there are definitely benefits of a larger phone, (and I've definitely enjoyed having it at times) there have been quite a few times where I've been frustrated that it's not really usable with a single hand.

Not sure what that means for my next phone though. Because at times, I thought the 13 Pro was too small for me.