3 ms·
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 separat
by tonymet 1y ago
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 https://www.atlassian.com/git/tutorials/dotfiles
- eviks 1y agoHow does your bare repo handle a config file in different paths on Windows and MacOS where you want to ignore "last_update_time" field diff noise and also have OS-specific path references?
- jitl 1y agousing windows is out of scope for my lifestyle
- hk1337 1y agoDifferent branches for each OS.
- tonymet 1y agobranches and symlinks . Don't throw out the 99% solution because it's missing 1%
- eviks 1y agoHow do either of those help ignore "last_update_time" field diff noise? Also, who is going to set those symlinks correctly, Mr. Git? Your solution is only 99% if you ignore the other 50% of real-life complications.
- blankdata 1y agoCould you elaborate on using git subtree for adding dotfiles to /etc or any other root directory?
- tonymet 1y agomind 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.
- tonymet 1y agohttps://dev.to/tonymet/how-to-put-everything-in-git-2b3d https://dev.to/tonymet/how-to-put-everything-in-git-2b3d This is a variation of the same idea with some illustrations
- tonymet 1y agoyou could think of it as a "monorepo" for multiple machines
- tonymet 1y agohere'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
- tonymet 1y agoand 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