I can definitely attest that this is very easy, and best of all it's just a git repo, so there's no special tooling required. The process was seamless when I upgraded my MacBook.
With that said, i did forget the commands, and had to lookup the article. I knew how it worked, a sort of redirected git repo usable from anywhere, and used with an alternate command, but I just didn't remember the commands offhand.
The nice thing is too, is that the initial setup of things like the "myconfig" command (I use `dot`) only requires being setup once, even after switching machines. Since a new machine just requires you to setup the git repo with a couple (hard to remember lol) commands, and then suddenly your `dot` command works "magically". Because of course, it's included in your dot files.
It really is magical, and shockingly simple. I've been using it for over a year now and am fully happy.
Not really. It's two commands on Linux, three on a mac. Or one, if you just put them in a script in the repo (which is how I do it, with a few extra lines to detect my environment and use the proper install option).
I think having to have that special git alias just bugs me as being a bit unnecessarily complex, but different strokes for different folks I suppose.
FWIW I don't actually use stow, I just wrote a simple Python script to do it[0]. It doesn't handle deleting things but it just means I don't have to mess about having a special non-standard git repo in $HOME, I can just treat my dotfiles like any other git project I have.
I've starting just using GNU Make for my dotfiles [1] after struggling to choose from the abundance of dotfile managers [2] for a while. So far it's working out nicely.
I was going to say that I do something similar with mine[1], but I looked at your makefile and saw that it's about 10x more sophisticated than mine, although I've never really had sufficient problems to warrant learning the makefile black magic. I think I'm now thankful that my dotfile needs are so basic!
I've been experimenting with dotbot [1] for the last little bit and it is similar to what is described here. The main difference being that the placement of the dot files is configured in a JSON/YAML file instead of a directly structure.
It doesn't have any external dependencies, unless you consider python an external dependency, but most all distros come with that built-in these days.
It's not a management system either. It's just a tool for describing where to copy things to. So if you simply choose not to use it later it's not that difficult to migrate.
I saw the author's structure with .bashrc under the bash "app subdirectory" in stow, and thought that it would also be handy to allow your vim app subdirectory to include some bash snippets to be included in bashrc.
You can't just have multiple .bashrc files that get linked to the same ~/.bashrc destination, but you can have a ~/.bashrc.d directory and have the end of your central .bashrc source everything in that directory (in some well-defined order). then your vim app subdirectory could add shell aliases/functions for, say, invoking vimdiff in a particular way, by adding a file in ~/dotfiles/vim/.bashrc.d/vim.bashrc .
Pro-tip for NixOS: NixOS won't really enforce state in /home, expecting users to save files there as normal (who wants to edit configuration.nix every time you want to save a LibreOffice file?) and to have normal backups of /home.
If you want to define your /home contents statically (because, for instance, you're running a single-user home machine and you consider your dotfiles part of your system configuration), you should instead create a /etc/users/<name> directory and set it as the home directory for your user. NixOS then allows you to define its contents as part of configuration.nix, just like anything else under /etc.
I actually use this same method manually with git. I have a .theme folder in my home directory, which is a git repository, containing the directories bin and user. The bin directory houses utility and convenience scripts which are tacked on to my PATH while the user directory holds all my relevant dot files. Then, a setup script in the root .theme directory symlinks the relevant dot files from the user directory to $HOME.
The great part is that I can keep branches for each computer which share my configuration. And being that I consistently use Arch, I also employ an install script with my common packages to speed up new installations.
In the end, it shaves a good hour or so off my installation process.
If you often switch different versions of any of your config files, confetti may suit your needs better than stow: https://github.com/aviaviavi/confetti.
If you just use stow for basic dotfiles management, confetti will also work just fine, but is less general than stow.
For those of you who like me are never quite happy with your emacs configuration or your bash prompt, I can heartily recommend stow. I used to manage my dot files with symlinks by hand; stow makes it much easier to keep all my systems configured and it's one of those admirable simple programs that does one thing well.
