3 ms·

It took me 20 years to have an important realization about version controlled dotfiles: what I wanted to do was manage a set of sensible, personalized, non-stan

It took me 20 years to have an important realization about version controlled dotfiles: what I wanted to do was manage a set of sensible, personalized, non-standard behaviours for each tool I used, and have a way of distributing those across systems. What I didn’t need at all, after all, was anything that installed different things on different hosts or classes of hosts. Luckily, every tool I want to configure has a config file option to include another file, so I have a working copy of my version controlled defaults here: ~/.config/defaults …and a one time installation script that makes various tool’s config files look like this: # begin defaults source ~/.config/defaults/tool.conf # end defaults local specific config here I am quite happy managing the local bits by editing files on local machines. All my configuration stuff splits into either “used everywhere” or “used just on this one host”, so that makes it easier. As soon as I figured this out I had to pinch myself as to why it had taken so long to come up with this idea.

jacobmischka 4y ago
I do something similar, though I use the "defaults" as the starting point and add overrides in local files which aren't checked in. Something like this: # .dotfiles/.bashrc # shared baseline config... if [ -f ~/.bashrc.local ]; then . ~/.bashrc.local fi
OJFord 4y ago
I still want the versioning of host-specific stuff though, as well as the backup (by having the repo on GitHub too), and easy reference to other hosts' config that I might want on my current one after all (or setting it up for the first time). I do this by having ~/.config/tool/blah.conf as you'd expect; but also ~/.config/by-host/$hostname/tool/blah.conf I agree 'classes of hosts' is way overkill for probably anyone's personal machines though. Only thing close to that I do is with aconfmgr for more system-oriented stuff - but that's all simply on the basis 'if SSD enable TRIM' type 'classes', no manual specification.

jacobmischka 4y ago

I do something similar, though I use the "defaults" as the starting point and add overrides in local files which aren't checked in. Something like this: # .dotfiles/.bashrc # shared baseline config... if [ -f ~/.bashrc.local ]; then . ~/.bashrc.local fi

OJFord 4y ago

I still want the versioning of host-specific stuff though, as well as the backup (by having the repo on GitHub too), and easy reference to other hosts' config that I might want on my current one after all (or setting it up for the first time). I do this by having ~/.config/tool/blah.conf as you'd expect; but also ~/.config/by-host/$hostname/tool/blah.conf I agree 'classes of hosts' is way overkill for probably anyone's personal machines though. Only thing close to that I do is with aconfmgr for more system-oriented stuff - but that's all simply on the basis 'if SSD enable TRIM' type 'classes', no manual specification.