HN Reader

I've seen projects like this for years and I still have the genuinely honest question: what are people doing that managing their dotfiles is significant problem for them?

I've managed my dotfiles (12 different configuration files all compatible with cygwin, wsl, linux, macOS) for the past decade in a git repo with a 50 LOC shell script that creates symlinks for me in an intelligent way. What am I missing?

I just use a git repo and GNU Stow similar to the approach in this post (I'm not the author of the post):

https://tamerlan.dev/how-i-manage-my-dotfiles-using-gnu-stow...

Stow is usually trivially installable using the package manager while I'm installing git. Not nearly as full featured as chezmoi but gets the job done for me.

Now that 20225 has become “The Year of the Terminal”(R), I have been looking at how managing my dot files in a more coherent way. I was thinking straight up git vs stow, but I should would be very interested in comparisons from those who have used this tool.

I've been using dotter for 5+ years and it's been an amazing tool. Doesn't go all in like NixOS, but lets you get close to that functionality by allowing templating to reuse a single dotfile repo across different systems. I also like how you can easily conditionally select configurations and scripts to load depending on environment.

Why is "written in Rust" as important as what the software is about? I noticed this tendency of specifying when something is written in Rust.

Should it be an indicator of better stability? Or performance? And if so, am I interested in the performance of a dotfile tool?

Genuinely curious.

git bare repo handles dotfiles better than any bespoke platform

1. git is already there and familiar

2. sync dotfiles over ssh . no internet access or separate credentials needed (for github, s3 etc)

3. handles merge conflicts

4. easily push & pull subdirectories into /etc , /usr/local or wherever else you need configuration using git subtree.

git bare repo works for tracking files anywhere on the FS as well. (check debian etckeeper for automating that)

credit: https://www.atlassian.com/git/tutorials/dotfiles

I've never really had any of the issues that is mentioned in the bullet points. I use the Atlassian post on storing dotfiles [1] for several years now.

* It's easy to setup on a new machine, no creating symlinks on every setup

* I create separate branches for different machines/environments. Like, currently, I have a branch for macos and my master branch is for devcontainer, but I have had a linux branch too.

I copied the post to a markdown as a README in the repository in the off chance Atlassian deletes the post for some reason.

Most recently, I started moving any config files I could into the .config to keep the home directory clean. i.e. .config/git .config/fish and .config/zsh

1: https://www.atlassian.com/git/tutorials/dotfiles

I have a backup/restore set of scripts that copies my dot files over as well as a few directories as a whole via rsync.

My only big issue is how big ~/.config/ gets as a directory compared to how much I really want to keep/need in terms of a fresh setup. Similar for my ~/src/ directory, with all the ./.git/ files. I kind of wish there were a "smarter" backup/restore tool that could handle a few of these things better than ham-fisting and rsyncing all the things.. I was more selective in my restore when configuring my new computer earlier in the year.

I wish it had more examples or some basic documentation website, it looks interesting cuz i have a lot of context switching through all my tools.