For howebrew, check out brew bundle. It creates a manifest file for you that you can then use to re-install the same stuff on another macOS machine (more or less, the versions aren’t pinned)
Thanks for sharing this. This has been my favorite approach for managing my core dotfiles across my personal *nix computers ever since I read about it here. One of my favorite “features” is that because it’s just git, I can maintain a parallel branch of things like .tmux.conf with customizations specific to my computers at the office.
I’ve been wonder recently – how is this method of managing configuration any better than using configuration management software, like, say, CFEngine, Ansible, Salt or whatnot?
I’m not convinced it even is way simpler! Sure, you can do very complicated things with configuration management tools, but you don’t have to!
The simplest option is to just store your config files in a format and directory structure compatible with your favourite configuration management tool, and manually copy/paste them into place. This is only marginally more complicated than a plain, unstructured, version controlled directory, but gives you the option of writing directives to install the configuration and associated software if desired!
Have you considered to check out your dotfiles repo at ~/.config? Thats my current way to go, requires no aliases but some symlinks for some programs that dont know about .config yet.
I’d avoid using ~/.config if you want to use a repo like this for cross-platform config sharing (which is what I do, anyway) because it conflicts with the usual value of $XDG_CONFIG_HOME. For my part I put the bare repo in ~/.cfg.
Like may of us, I built my own (git-based) solution for this as well – WSUP. In my case, I have several computers, and change to new ones fairly often. I wanted version controlled dotfiles, with the ability to install different “layers” depending on the use or sharing needs. I have a layer for work, one for personal configs, one for just emacs, one for private files, etc.
For howebrew, check out
brew bundle. It creates a manifest file for you that you can then use to re-install the same stuff on another macOS machine (more or less, the versions aren’t pinned)Thank you! I forgot about
Brewfile:)I’ll plug
vcsh- a plain oldPOSIXshell +Gitsolution.I don’t see the point of these wrappers. I have a git repo and there is an install.sh script in there.
I used to have an mkfile that served the same purpuse as your script. Now I’m just using stow[0].
Here’s an example for mantaining an email setup (assuming it consists of mutt and mbsync):
Then you can deploy it with
[0] https://www.gnu.org/software/stow/
Thanks for sharing this. This has been my favorite approach for managing my core dotfiles across my personal *nix computers ever since I read about it here. One of my favorite “features” is that because it’s just git, I can maintain a parallel branch of things like
.tmux.confwith customizations specific to my computers at the office.One thing I’d add to the setup is running:
to keep things sane in your
git statusoutput.I’ve been wonder recently – how is this method of managing configuration any better than using configuration management software, like, say, CFEngine, Ansible, Salt or whatnot?
I’m not sure if better, but definitely WAY simpler :)
I’m not convinced it even is way simpler! Sure, you can do very complicated things with configuration management tools, but you don’t have to!
The simplest option is to just store your config files in a format and directory structure compatible with your favourite configuration management tool, and manually copy/paste them into place. This is only marginally more complicated than a plain, unstructured, version controlled directory, but gives you the option of writing directives to install the configuration and associated software if desired!
I hope someone finds this useful! :)
Have you considered to check out your dotfiles repo at ~/.config? Thats my current way to go, requires no aliases but some symlinks for some programs that dont know about .config yet.
I’d avoid using
~/.configif you want to use a repo like this for cross-platform config sharing (which is what I do, anyway) because it conflicts with the usual value of$XDG_CONFIG_HOME. For my part I put the bare repo in~/.cfg.Thats not a problem, thats the purpose of how i do it - to track $XDG_CONFIG_HOME in git, which is usually at
.config.I have, but IMHO one alias is way simpler than managing symlinks with, let’s say, GNU stow (https://www.gnu.org/software/stow/)
The same can work without external software (beside a posix shell):
https://github.com/nero/etc/blob/master/deploy.sh
This does it for me:
Like may of us, I built my own (git-based) solution for this as well – WSUP. In my case, I have several computers, and change to new ones fairly often. I wanted version controlled dotfiles, with the ability to install different “layers” depending on the use or sharing needs. I have a layer for work, one for personal configs, one for just emacs, one for private files, etc.