This site seems much more like an some of the awesome-<insert tech here> repositories on github than a guide. Although it does give some extra information on the packages.
To not make it took negative. I personally use Chezmoi, which I've been super happy with. The ability to maintain files in a central repository and then pull them into the file system on an update is quite nice.
You can handle merge conflicts and whatnot between your local copy and the upstream dot files. You can opt your files into using go templates in your files which is useful when I need to maintain differences in configs between mac and linux, or in general for just storing secrets out of your dotfiles.
There are some small annoyances but overall it is the only dotfile manager, I've managed to stick with.
Third here, it's the easiest tool to setup dotfiles that work on machines ranging from RHEL7 to latest MacOS. Haven't dealt with Windows dotfiles though.
Another happy chezmoi user here... I progressed from symlinks -> Homeshick -> yadm -> chezmoi
One of chezmoi killer features is how it handles secrets. Either the secret can be encrypted using age/gpg or (super cool) it integrates with you password manager (I used Bitwarden).
This is super useful for me, as I pair chezmoi with dotenv, so when I switch directories, my environment variables are auto populated, including secrets that are pulled directly from my password manager.
I guess I don’t quite get it. It’s not a ton of work for me to manage things with git, symlinks, and a makefile. Clearly chezmoi adds some polish and maybe additional features, but I don’t see how that outweighs learning a custom tool for this one thing.
The thing is that there isn't a lot to learn unless you have complex use cases (I have one, so I need to use chezmoi's advanced features). It just uses git under the hood and does a diff between your repository and the actual locations of your dotfiles, so if you wanted to (and I often do) you can just `cd` straight into chezmoi's repo and use `git`.
My complex use case is that I use all three of the main OS' and so there are some dotfiles for desktop apps that live in Windows' home directory and some that live in WSL, so having something manage that for me is pretty nice.
I just use stow and git with a Makefile as well, and I could certainly do without stow these days (I can just write a Makefile target for it, but haven’t bothered).
Using the GNU stow utility makes this super easy. It even has a --dotfiles flag so you can author your dotfiles as dot-zshrc and when the utility symlinks it, it will be .zshrc. Makes it nice so your source files are not hidden but the actual dotfiles are (as expected).
Although GNU stow is very interesting, I like this simple script because it has no external dependencies. Stow is not available on macos by default, for example.
It is available though in every package manager for macOS except the App Store, and any user of a script like this on macOS is probably also using Homebrew, macports, Nix, or srcpkg.
This will not handle cases other targets than $HOME. The automatic deletion seems also very risky. In my own script, I move all pre-existing targets to a separate directory, so I can check later.
You can set the source and target directories to whatever you'd like, this is just what I need for my own use. The automatic deletion is for directories, to prevent recursive symlinks. Of course, you can program your own however you wish, maybe add a confirmation step before removing and/or create a backup beforehand.
I made it Python, added a simple json-config and mustache-templating. Very portable (where symlinks are), very flexible (also used it for termux for a bit) and very simple.
Sure, maybe. Though eventually one may find lots of edge cases. What about files in the root that get deleted? What about programs that put wanted state within config dirs? What about programs that ignore symlinked files? What about when you’re hacking on your dotfiles and break everything because the active config is the config being edited? What about when you need to vary based on system? What about…
I mean, yea, if it works for you, great! But all of the above are problems I did have. I grew a custom install script for years. Now I use Home Manager and the impermanence module.
My approach to coding is to tackle these types of problems once they occur, instead of thinking "What about...", "What if...". I don't have these problems you're describing, so the script works great.
Similar experience here, like: What about when your editor is set to auto save when unfocusing a tab or window and saves while you were mid-edit on your dotfiles and now every new shell is crashing? etc etc
I'm sorry, but running `rm -rf ...` in a script against $HOME is a bit too reckless for me.
Maybe you haven't lost data from this yet, but this is where Chezmoi has nice guardrails and protects against, e.g., modifications or additions accidentally being made to $HOME instead of the dotfiles dir, which look like they would be silently blown out by your current process.
Just my 2¢ from someone who used to do it this way and lost data because of it.
I've been bikeshedding with dotfiles for 20 years and ended up with Chezmoi[0] in the end.
It came down to the fact that it's easy to install and easy to bootstrap as long as your dotfiles are in a public Github repo. It also integrates with a bunch of password managers to grab any secrets you might need in addition.
I use the "run_onchange_install-packages.sh.tmpl" to install basic packages to computers I bootstrap chezmoi on, it adapts based on the operating system using chezmoi's templating system[1]
It takes a few tries to remember the flow of "chezmoi add"ing a file after editing it so that you can push it to Github. After that it's just a matter of chezmoi update on your other computers to bring them up to date.
For .gitconfig I use a .gitconfig.local file on my work computer to override my personal credentials and not have to mess with templating the file.
I can't speak for the OP, but I've used a bare git repo for a number of years to manage my dotfiles, and in the few cases where I need to handle differences between machines, I've always been able to find a simple and straightforward, albeit ad-hoc, solution: for my shell, I `source local-config.${hostname}` when it exists; for my emacs config, I have a couple `cond` blocks in my config.el file; my preferred terminal emulator (kitty) can load multiple configuration files in sequence via passed arguments, so I can write a simple wrapper script and use a per-machine override .conf if necessary; etc etc. I don't currently put secrets in any text configuration files (nor can I envision myself doing so in the near future; I generally use a password manager, ssh/scp, or magic-wormhole to move secrets between workstations and servers where I have a user account), so I don't have a good answer for that one.
I imagine these solutions would scale poorly if I had a large number (dozens? hundreds?) of machines which all needed unique configurations, or if I used more tools which needed per-machine configuration, or if I needed to stick secrets in configuration files for some reason. Luckily for me, that's not the case, and my system has served me quite well as a result.
Nix + Home Manager is by far the easiest-to-manage system for dotfile management to date for me.
The added bonus is:
1. No need for complicated directory structures that a symlink-like script needs to manage.
2. Dotfile management coupled with package management. Dotfiles only make sense as configuration to packages you have - why would you not tie these together?
3. Minor-to-no tweaks required to have a fully reproduced setup on any machine.
Seriously, I transitioned my dotfiles from my NixOS machine at home to my work-issued M2 within... an hour?
I have also ended up with Home-Manager. It's an extremely powerful tool that I am unlikely to replace in the next ten or so years, but you also need to learn a whole programming language (Nix) plus a DSL (the NixOS module system) to get the most out of it.
On the upside: you do get a whole purpose-build language for configuring your system, piecing together your configurations dynamically, installing your packages and so much more.
Ability to install packages is another huge thing. Home-Manager does not just configure my tools, it also installs them (including my DE), so I can get started with my custom config on a new system in a matter of minutes.
I started managing my dotfiles in git and followed the pattern I found in Anders Knudsen's repository below. The most painful thing has been coming up with config that works across Linux and MacOS, but that's been chosen pain that can easily be avoided.
This method, using a bare git repo, is really an elegant, efficient, and easy way to manage one's dotfiles.
In the end, how you do it is personal pref. I liken it to editor wars, vim vs emacs, etc. What works for me, may not work for you.
PS: these are my dotfiles (link is my repo), and I've used this method for some 5 plus yrs now and it works well for me. I really like how easy it is to spool up a new linux instance and have my config ready to go in mere seconds.
I've not used branches yet, for different OS'en, so my zshrc and bashrc have conditional checks for OS. I will be looking at using branches in the future since it does sound like it would make shell rc files cleaner.
Gnu stow has finally been updated to fix a long standing issue so I can once again wholeheartedly recommend it again! It’s lightweight and uses symlinks. Last I checked, chezmoi has a symlink mode but it’s a bit worse.
Curious what the issue you were running into was? I’ve been using stow for my dotfiles for at least 8 years now and have been loving it the whole time.
Basically, the --dotfiles option was not working with directories so you had to have things that look like this: lazygit/.config/lazygit and now it looks like: lazygit/dot-config/lazygit.
Really a small issue that bugged me forever - shouldn't have made it seem like it was core a problem with stow!
Basically, the --dotfiles option was not working with directories so you had to have things that look like this: lazygit/.config/lazygit and now it looks like: lazygit/dot-config/lazygit.
Really a small issue that bugged me forever - shouldn't have made it seem like it was core a problem with stow!
I'm currently using a git based approach for my dotfiles, similar to the one notes here[1]. I've got one significant change, though:
All my dotfile management works over my cfg[2] script that helps me maintain a main branch for dotfiles for all machines and then branches that branch off of that main like 'main.arch.MACHINE_NAME' that are merged like a waterfall during sync (main -[merge]-> main.arch -[merge]-> main.arch.MACHINE_NAME).
(I can also cherry pick up the waterfall)
Yes, I've gone through every style of dotfile management. Stow, bare git repo, custom script, and now nix with home-manager. Using Nix is definitely the best solution so far, largely because not only does it manage the configurations, but also installs the programs you need.
The one thing that makes me hesitate with nix is that it only really supports Linux and Darwin; of the BSDs only FreeBSD has any support (somewhat suboptimal still), and AIUI Windows is also unsupported.
I’ve tried a bunch of these out and settled on yadm as well. It’s basically a shim for Git that tracks your home directory with a bare repo stored elsewhere.
I use yadm too but I found the differences between versions a bit tricky. The upgrade scripts didn't quite work, although I did try to jump from v1 to v3
I highly recommend dotter, especially if your dotfiles have variation from machine to machine and or if you don't need all of them at a given time. It's pretty simple and lightweight
I've had really good luck with vcsh and git-crypt. vcsh can be a little awkward to use because git commands need to be scoped to the vcsh project, but you get used to it. I like having separate git repos for separate roles (e.g., fish-common, fish-personal, fish-work). Then, depending on what I'm doing on a particular machine I can pull in just the roles I need. It may seem like overkill, but I've found it very helpful in sharing my dev config without pulling personal stuff onto a work machine, vice versa.
git-crypt allows me to protect sensitive files while still tracking them in a git repo. I don't think I'd rely on it for shared projects, but it works well for me.
> Submodules make managing dotfile dependencies so much easier.
I'm impressed by the dedication of anyone who has enough dotfile config to use a submodule!
I still like Vorta for dotfiles, just because it's trivial to set up and only uses tools I already use for other things. Most of the dotfiles I want to back up have secrets, so GitHub isn't really an option.
SyncThing seems like it could work well for dotfiles too, with some kind of frontend that copied stuff to a sync folder.
Am I missing something or is the use of "GitHub" weird here? Are they GitHub employees? None of the creators seem associated with GitHub. They're _users_ of GitHub, nothing more.
To not make it took negative. I personally use Chezmoi, which I've been super happy with. The ability to maintain files in a central repository and then pull them into the file system on an update is quite nice.
You can handle merge conflicts and whatnot between your local copy and the upstream dot files. You can opt your files into using go templates in your files which is useful when I need to maintain differences in configs between mac and linux, or in general for just storing secrets out of your dotfiles.
There are some small annoyances but overall it is the only dotfile manager, I've managed to stick with.