Bare repos are fine, but I don't think it is the method to manage dotfiles, the other approaches people use, stow among them, have their merits too. For me a bare repo never really worked that well. I use different dotfiles "profiles" that I mix and match for different environments (remote server, docker container, dev workstation, ...) and situations (terminal, xorg, dev, testing, etc.). I found a bare repo less than ideal for this, personally. It's perfectly fine for simple setups, granted.

I think one reason some people prefer symbolic links over directly managing $HOME with git is that there's less chance that things go wrong due to a bad accidental git command. For example, `git clean` (with the appropriate arguments, e.g. '-fdx') could delete all non-dotfiles from all of $HOME.

Admittedly, the chance of this happening does seem much lower when the git directory is in e.g. '~/.cfg/' while the work tree is $HOME, as the linked article proposes, than when it's set up with just a `git init` run in $HOME (because a `git clean` in a non-git-repository directory somewhere under $HOME won't cause any problems, because there will be no '--work-tree' argument). Still, at least to me, the symlink approach feels more comfortable.

I wonder, does anyone else have other reasons to prefer symbolic links?

I can't use this because I'd like to be able to put files outside of $HOME :(

I prefer dotfiles too, I recently built a new machine and was able to configure most of stuff just by using dotfiles.

By carefully managing scripts (mostly .zshrc) I can even use the same dotfiles between mac and linux.

> no surprising behavior

What surprising behavior does it avoid?

Symlinks breaking perhaps? Anything else?

Does it work for all kinds of files ???

that’s the way everyone first tries it

It is not.