Should I use doot?

If you use Linux or macOS, you will likely have a collection of configuration files from different applications scattered around your home directory. These files are usually hidden (start with a dot) and are often called dotfiles.

It is highly recommended to store these files in a Git repository (e.g., on GitHub) to keep track of changes, share them between different machines and have a backup in case of data loss. You could do this manually, but using a dotfiles manager will make your life much easier.

doot has been designed to be extremely easy and fast to use, so I recommend giving it a try. Of course, my opinion is quite biased, so take it with a grain of salt and investigate other options as well.

Check out the Getting Started guide for detailed information on how to set up doot.

Yes, you should definitely use doot (or, honestly, any other dedicated dotfiles manager) instead of Stow. Despite being the program most people recommend for beginners, using Stow to manage dotfiles is at best unintuitive and at worst dangerous.

The main problem with Stow is that it symlinks the whole directory instead of individual files by default. This, in turn, has 3 main consequences:

1. The installation behavior is not deterministic, it depends on the previous state of your home directory. If the directory already exists, Stow will add the files as individual symlinks, and if it doesn't, it will symlink the whole directory. Which one of the two happens may seem inconsequential, but it will have a huge impact on the long run (see below).

2. If a directory is symlinked, all future files created inside it will be automatically added to your dotfiles repository (after all, that's where the directory actually resides). In a handful of cases this is desirable and saves you from having to add that file manually (in doot you would run doot add <file>), but in a lot of cases you will have to create one big (or many small) .gitignore file(s) to ignore those undesired files.

3. This is the dangerous part: if anything were to happen to your dotfiles repository (you ever need to reset the branch, decide to switch to another dotfiles manager, etc.), you will lose all the gitignored files. This is because those files were stored in the dotfiles repository (which has now been wiped), but had not been committed to Git. These lost files are often important, they were located in a config directory after all.

It is possible to avoid the problems above by using the --no-folding flag, but as far as I know it won't fix directories that have already been symlinked.

Additionally, by using a dedicated dotfiles manager such as doot, you will get other nice benefits such as:

• Support for host-specific files. If you have more than one machine, this allows you to use slightly different configurations on each one.
• Native support for private (encrypted) files.
• Advanced features like hooks, custom commands and bootstrap scripts.

Both of these projects are very mature and are a solid option for managing your dotfiles. The main problem I have with them is that they install dotfiles as regular files instead of links, which forces you to use their CLI commands instead of a generic Git client.

If you are already happy with either of them and enjoy using the terminal to manage changes, you probably don't need to use doot.
However, I still recommend giving this project a try if any of these is true:

1. You want changes in your managed files to be automagically reflected in the dotfiles repository, without having to manually run any command periodically. This is something you can only get with symlinks or hardlinks (doot supports both).

2. You prefer using a GUI client to manage your Git repositories, including your dotfiles.

3. You like trying out new things and want to experiment with other dotfile managers.

Yes, you should definitely try doot. I was also daily driving RCM before writing my own manager, and I took a lot of inspiration from RCM's design, mainly around simplicity and ease of use, while solving most of its flaws.

These are the problems with RCM that pushed me to create doot:

• It's slow. Updating my personal dotfiles repository with RCM (adding or removing 1 file and then running rcup) takes around 10 seconds, while doot does it incrementally in just 2 milliseconds (20 milliseconds with a cold cache [1]). 10 seconds doesn't seem like much time to wait, but I add and remove files from my dotfiles constantly, and waiting every time I do that gets old very quickly.

• RCM doesn't allow linking files/directories that start with a dot and are inside nested directories.

• It doesn't clean up stale/broken symlinks when a filed is moved/renamed/deleted in the dotfiles repository.

• It has some small bugs where it gets confused if the path contains spaces.

• The last release was in 2022 and doesn't seem to be actively maintained.

• No native support for encrypted files. This is not a deal-breaker, but it's nice to have.

• No support for using hardlinks instead of symlinks. This is usually only required in very specific setups where using symlinks doesn't work.

[1]: Time greatly depends on whether the file reads are cached in memory by the OS. After restarting the computer, all reads reach the disk and the command execution takes around 20ms. Subsequent executions take around 2ms since most disk reads are cached. Your mileage may vary depending on the random read speed of your disk and the size of your repo.

I would recommend you consider trying out doot, as it will save you time in the long run.

Dotbot's configuration file is mandatory, and it requires you to manually list each file to be symlinked, instead of deducing it from the directory structure. This was a deal-breaker for me as it requires double the work for no reason.