I also don't get these, but for another reason: why write a dotfiles-specific configuration management tool with templating, conditions and all of that when we already have proper SCMs like salt or ansible that perfectly scale down to a single user and a small number of configs, but are still orders of magnitude more powerful when you need it.

I will do a lot of work to avoid having to touch ansible and friends. Fortunately, I don't have to do a lot of work because I spent 10 minutes writing a 50 line Go program a decade ago that has done everything I've needed it to do in the interim (IIRC the only change I made to it was supporting Go modules back in ~2015).

> I just have a git repo with a branch for every machine.

Aren't you supposed to "not" commit secrets/sensitive values to git repos as "best practice"?

I guess it's a private repo...

For many dotfile configs such as text editors, aliases or else not involving security, I personally don't care if it's public. Take this example https://github.com/AzogMugen/shortcuts-config/tree/master/ho...

Perhaps SSH/GPG private keys are .gitignored?

I protect my ssh keys with passphrases, and then load the keys using ssh-add.

Where does their comment indicate they commit secrets?

Are your per-machine branches mostly distinct, or do they share a lot?

I use https://github.com/thoughtbot/rcm and I find my dotfiles share _quite a bit_ in some respects (e.g. neovim config) but are drastically different in others (SSH config as one example) -- keeping things synced _across_ branches sounds very difficult. rcm handles this well, without branches, IMO.

You can have shared files and source them

> not just yaml toml and JSON

those are the formats available for configuring rotz itself; it's agnostic to the content of your actual dotfiles