Ask HN: Why do people need more than git to manage dotfiles?

I did use git for a long time for just this purpose. I don&#x27;t even remember the details now, but it worked well enough for a single machine.<p>The main reason I switched to Nix about 8-9 years ago to manage my configurations was the deterministic package versioning. This is mainly because I started managing a lot more machines and each machine had different versions of different software and some config options were deprecated or removed, or syntax was changed, etc etc.<p>This is around the same time I started to get fed up with Ansible for provisioning and Nix along with NixOS solved both problems quite nicely, enough that I haven&#x27;t felt a need to change nor any regret since. If not for that, I&#x27;d probably still be using pure git.

Well, firstly, stow existed long before git, so some of it might just be &quot;don&#x27;t break what isn&#x27;t broken&quot;.<p>In the 90&#x27;s, I worked at a place that had DEC Alphas with OSF&#x2F;1, Sun UltraSPARCs with Solaris, x86 Linux boxes, and a few random SGI, HP, *BSD boxes and so on. The commercial Unix variants come with a fairly limited set of programs. So that we had a useful environment, no matter what machine was being used, we had a large tree of FOSS NFS-mounted onto each box.<p>That tree used a shared source tree, build trees for each machine-os platform, and then we stowed the built stuff.<p>Stow was mostly useful when uninstalling (because not everything had a reliable `make uninstall` option), or to quickly switch between active versions.<p>I don&#x27;t think I&#x27;d attempt to put that whole thing into git today: stow is the right tool for the job.

I have several reasons for my custom make + stow + shell scripts:<p>* git status only shows me changes to config. Similarly it is easy to determine if I&#x27;ve forgotten to add something when adding a new config.<p>* accidentally adding giant directory trees to the repo is much, much harder - absentmindedly &quot;cd ..&quot;ing one too many times and committing a bunch of proprietary work code causes a lot more work to cleanup than a lifetime of extra character strokes in &quot;cd dotfiles&#x2F;repo&#x2F;dir &amp;&amp; git commit -a&quot;.<p>* it allows me to have some goodies for the heterogeneous environments I compute in. Depending on if I&#x27;m on a mac or linux, if the machine is at home or work, a server or desktop, etc. I can tailor the subset of configs and details thereof. The net result is ironically a more consistent personal compute environment across systems.<p>* it allows me to store examples, notes, documentation, etc in my dotfiles repo without cluttering up my homedir<p>* i don&#x27;t have to remember if config live in .prog, .prog&#x2F;config, .config&#x2F;prog&#x2F;, etc<p>* it lets me store system setup scripts in my repo too. I can log onto (or install) a new machine and run my initialization script (os appropriate) and be 95% or moreready to go in a few moments. [note: things like vim + plugins, fontconfig, etc that need extra commands to set up are all automated in these], without always having those commands in my ~&#x2F;bin path.<p>Overall, for me it boils down to: I get more control over my environment on multiple, different machines by using a bit of scripting in my dotfiles repo.

If you’re talking about the symlinks in your repo, this only really works on Linux and Unix (macOS) systems.<p>I did this in a project at work to try and retain some backward compatibility, while better structuring something, and it worked great for me on the Mac, but a co-worker on Windows touched the file and broke it without even knowing it or actively trying to do anything to it. He just wanted to see what it looked like and how it worked.<p>Not so much an issue for a home folder backup, but an issue for teams working on different platforms.

I only have about 5 of them I want to version, and they very rarely change.<p>Vorta&#x2F;Borg has encryption, and I&#x27;m already using it for actual backups, so it was just easier to make a profile for them.