Yes. I don't understand why everyone keeps reinventing this tiny, full-featured symlink manager.

It can also unstow and restow, ignore patterns, etc. Highly recommended.

reinventing the wheel != creating a universal standard

With this stow solution, I wonder what happens when some program makes modifications directly to its own configuration files, without being aware that they're not directly under your home directory but symlinked under dotfiles somewhere. Will the symlinked file get modified? Or will the symlink be removed completely and a new file be put in its place, directly under your home directory and not under your stow directory at all.

One program which I'm thinking of that can make modifications of its own config files is znc. weechat is another. There might be some other random program that does this too. I'm concerned that using stow for them might lead to disaster.

Any advice from someone who's tried it with apps like that?

Why wouldn't it work? You can write to a symlink.

    $ touch file
    $ ln -s file symlink
    $ echo text > symlink
    $ cat file
    text

Some applications write to a temp file and then move that over the old file.

One way to work around this is to symlink the entire directory.

That blog post suggests putting the top-level "dotfiles" directory under version control. But doesn't it make more sense, at least with git, to put each individual subdirectory under dotfiles under in its own separate repo?

With the blog post's solution, when you want to revert to an older revision of, say, your .vim or .emacs.d dotfiles you're also going to be automatially reverting your .bash and whatever other random dotfiles you have. With the latter solution, when you revert your dotfiles/vim or dotfiles/emacs subdirectory, you only get an older revision of your vim or your emacs files.

Does that make sense?

You can revert changes to individual files or subtrees in git.

I've occasionally ran into bugs where symlinks have caused problems. At the very least this is something to be aware of.

That looks really cool! The only minor problem I would have is you have to install stow before bootstrapping your dotfiles on a new machine, but that's obviously not a huge deal. I guess I could replace my bootstrap.sh script with a line to install stow, then a line to run stow.