The dotfiles use `GNU stow` to link themselves in the home directory. You can clone this repository anywhere (though I have mine in `~/.dotfiles` as it seemed most logical for me).
I would recommend doing a `git clone --recursive` for this repository, since it contains git [submodules](https://nering.dev/2016/git-submodules-vs-subtrees/), which will then automatically get pulled in as well. Of course, you can do it non-recursively and then just pull those modules selectively which you actually want.
Once in the repository directory, when you then run `./install.sh` it will install many of the packages I use (though they are probably slightly out-of-date) and link the dotfiles into the home directory.
Since it is based on `stow`, it will not overwrite anything already in the home directory (though you can force it to if you really want, using `stow --override='.*'` -- I do not recommend this).
If you do not want to install any packages, but only link the dotfiles run `stow -S */` from the main repository directory.
After all files are linked and you open a new shell session, the `dotlink` alias will allow you to re-link all dotfiles from anywhere on the system.[^1]
[^1]: This alias only works when the dotfiles are cloned into `~/.dotfiles` mirroring my setup.
This is due to a hard-coded cd into this directory.
If your dotfiles lie in another directory and you want to use the dotlink alias, simply change the corresponding line in `_bootstrap/.config/sh/alias.d/dotlink.sh`]
Both automatic installation paths are presumably somewhat brittle. In any case, I would suggest to manually look through the files for things you want instead of copying and activating everything.
Dotfiles are too personal to be standardized like that.
* Generally, most configuration for applications attempts to follow the XDG specifications, keeping configuration in .config directory and supplementary files in .local/share directory. Over time, I am moving more applications to this standard: it keeps the home directory clean, and the separation of configuration, binaries, and data relatively clear.
*`.config/shell` contains all the general zsh/bash/sh configuration and environment variables usually contained in `.zshrc`, `.zprofile` and similar. It is divided in login shell config (loginrc.d), general shell config (rc.d) and zsh specific (zsh.d). Over time this should be migrated to specific `stow` 'units', but for now here is where it is.
* The `zsh` directory contains all setup for the z-shell, my daily work environment. It should not be required for working with any other module but will add additional functionality to many (such as command auto-completion and so on). `sh` sets some base functionality for any shell you may wish to work in. It is, for now, the only module that is required for some other modules to work.[^shreq]
*`rofi` contains additional scripts and a simple theming framework for rofi and should probably be reorganized to put the correct files into the correct directories (per xdg) at some point.
*`.local/bin` in `scripts``stow` unit contains most executable user scripts. Most of these have been migrated to their corresponding modules (e.g. if a script exclusively targets git functionality, it will live there), some stand-alone scripts remain however.
*`.xinitrc` is used for x initialization and program startup. At some point, some of the consistently running applications may be moved to runit as supervised services.
* Generally, directories starting with a . are only meaningful for the *repository* not for the functionality of the machine that these dotfiles are deployed on. That means `.gitlab-ci.yml`, `.assets/`, `.stowrc` and similar files and directories will not show up in the final deployment in any home directory. Perhaps they should be called dotdot-files since they're the dotfiles for my dotfiles. 🙂 (Also, 'dotfiles'.)
[^shreq]: I may remove this requirement in the future to make modules more self-contained. However, relying on some base utility scripts makes it easier to avoid duplicating such functionality for each individual script in other modules.
