I fail to see how this comes with the convenience of directory-specific symbolic links, dotfile-specific backups, individual removal & replacement of dotfiles, etc etc.
I've been using stow for years to manage my dotfiles and it's never been more involved than
$ stow dotfiles/urxvt
or what have you. In fact I would say that managing a git repository is more of a waste of time and far more over-engineered for a task easily solved by a tiny binary.
Not sure what you're referring to by an 'install script', have you ever used stow?
In any case, the real answer is that you should be using whatever works best for your use case, and for me that's stow.
>A package directory is the root of a tree containing the installation image for a particular package. Each package directory must reside in a stow directory — e.g., the package directory /usr/local/stow/perl must reside in the stow directory /usr/local/stow. The name of a package is the name of its directory within the stow directory — e.g., perl.
I use xstow, which permits slashes; usually I do just cd into the dotfiles directory and stow out from there (otherwise you need to specify a target directory) but I left that part out for brevity.
I tried this but git uses ~/.git for any subdirectory of $HOME. For example, if you type `git add .` while in ~/code/some-project, you will add it to your dotfiles repository. It's easy to undo but still kind of annoying.
I do a variation on this where I have an alias in bash for `dit` that makes it `git --git-dir=~/.config/dit --work-tree=~` and use that to manage my dot files. Avoids a bunch of the common issues with using git directly.
I agree. I looked at quite a few dotfile managers, and all of them were overly complicated and couldn't replace my use of stow. Stow was not created as a "dotfiles manager" though, and keeping dotfiles seperate from all the other crud under ~/ is a lot cleaner in my opinion. I don't want my home directory to be a git repo either.
I do pretty much this but I have public dotfiles (on github), then an overlay for work files so I need a script to maintain those symlinks, and then work ones that I don't share with coworkers (contain private passwords).
So I have a script that manages the symlinks for multiple such repos, knows to remove the broken links as needed, and I have something I can just paste into the terminal of any machine and it'll set that box up with my public/work/private dotfiles as appropriate.
It's not perfect, but it works, just pointing out that even for relatively simple cases having a dotfile manager (or writing your own) can make sense.
Okey, but prepere for some super-lame ad-hoc code. Also I was
misremembering about it handling multiple repos, in the one place
where I have >1 I just do that manually.
Basically doing a find on my ~ directory and finding any broken links
pointing to the known location of the overlay repo.
I see now that there's a potential bug in it where it narrows its
search in such a way that it could miss it if you add/remove new
~/.??* files. This could be solved, but I have it like that because I
only ever add/remove stuff in e.g. ~/.bashrc.d/ or ~/.screenrc.d/, so
this way the find takes less time to run.
Then I have a generated one-liner that I can paste into new machines
that clones my dotfiles.git into ~/g/, moves the .git to ~/, then
sources bashrc which bootstraps the rest.
This seems like an astonishingly good idea. It maybe lacks features for my home computer, but would be good for throw away servers like those you get from DigitalOcean, where I systematically set up everything over and over again each time.
I did this for a while. I had to switch to stow when I got a new job that had data security requirements - I had to keep the "work" bits of my dotfiles separate from the non-work parts, and so couldn't keep everything in the same git repository. Ended up writing a set of rcs that just imported appropriate .d directories, keeping two git repos, and stowing both of them.
I manage my dotfiles in a separate git repo in ~/.dotfiles, and I have simple scripts that link and unlink everything. It's worked well for me for quite some time:
That's a really nice solution actually, letting git do the magic. I'm definitely gonna try it. At the moment I use a python install script that backup already existing files and set up the symlinks.