16 comments

[ 10.3 ms ] story [ 729 ms ] thread
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 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.
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 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.

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

Could you elaborate on using git subtree for adding dotfiles to /etc or any other root directory?
mind you it's one of a number of patterns that subtree let's you fan-in and fan-out from a single repo. It's helpful if you want to manage multiple directories and machines from a single repo.

1. git init /etc

2. git init /home

3. (in home) git remote add s/etc /etc

4. (in home) git subtree add -P etc s/etc master # adds a prefix etc , from remote s/etc . This starts the subtree syncing

You can now edit files in either place. to pull changes from /etc: git subtree pull. to push changes to etc: git subtree push. git is now managing the commit shas and diffs for both directories.

The home repo is the "canonical" one that you backup , push to github/gitlab etc. /etc can just stay local for "deployment".

You can take it a step further by editing the home repo on another machine. this pattern lets you fan in and out to multiple machines and etcs so you can manage all of the variations from a single repo.

describing it is more complicated than just doing it. It's really just push/pull which triggers a normal merge over multiple directories.

here's an example to a remote machine `pi4.local` /etc dir. If you want to deploy on push set `git config receive.denyCurrentBranch updateInstead` . if you want to deploy manually use `warn`

    git subtree push -P pi4.local pi4.local master
and remember that git can also manage symlinks . so subtree can help manage major directory differences, and git symlinks can handle variations in naming or minor directory variations.

thinking of git as a FS content & metadata tracker rather than SCM , opens up a lot of unique deployment patterns that developers often overlook

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.
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

Wish there were a detailed comparison to some other managers like chezmoi