Folder structure

This document outlines several recommended approaches for structuring your .hermitgrab directory. Each has its pros and cons, so choose the one that best fits your workflow.

Flexible Structure

When HermitGrab starts, it scans the .hermitgrab folder for all hermit.toml files it contains. This allows you to arrange your subdirectories in any way that suits your organizational preferences.

Pros

• It provides maximum flexibility for organizing your files.

Cons

• The resulting folder structure may not be compatible with other tools that expect a more conventional layout, such as GNU Stow.

Home-aligned Hierarchy

With this approach, the structure inside .hermitgrab mirrors the target structure in your home directory. For instance, a config.fish file destined for ~/.config/fish would live at .hermitgrab/.config/fish/config.fish, with its hermit.toml in the same directory.

Pros

• This structure is highly compatible with other dotfile managers, with the only addition being the hermit.toml files.

Cons

• The root hermit.toml can become crowded with configurations for many different tools.
• A top-level requires key in the root hermit.toml is problematic. For example, requires = ["bash", "zsh"] could imply an illogical dependency.

Dedicated hermit.toml Folder

This strategy introduces a .hermitgrab/hermit_configs/ directory to hold your hermit.toml files, separated from the dotfiles they manage. You can create subdirectories within hermit_configs for each tool or group of tools. The rest of your dotfiles remain aligned with the home directory structure.

Pros

• This layout remains compatible with most other dotfile managers.
• The hermit_configs folder allows for a clean and organized separation of configurations.
• Each hermit.toml can make effective use of a top-level requires key.

Cons

• Source paths within your hermit.toml files will need to use .. to reference the dotfiles in the parent directory structure.