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?
You're missing the empathetic way to comment on someone's obviously unpaid, labor-of-love work. Instead the conversation is about you: your years of seeing "projects like these", your smart, minimal way of managing your config. Make a project and show it to us. Save your pathos for its documentation.
I use chezmoi, and I didn’t have to write a 50-line script - just install chezmoi on a new machine, run a command pointing it to a git repo, and up pop all the dot files and configs I need to have a consistent environment everywhere.
Chezmoi also handles variations in config files for personal vs. Work machines, or even differences between machines themselves.
I agree it’s not a tremendous lift to write a bespoke solution for this (and I did so in the past) but at some point it becomes lower-effort to use something off the shelf.
In addition to that, chezmoi templating can be used to fill in environment variables like secret keys, you just need to unlock rbw or whatever other password manager it is that you use.
I have some that I export in my shell config, and this setup allows me to have the repo in a public place and not worry about who finds it.
+1, I also don’t understand these tools. Especially these days, many apps are using ~/.config so i barely need a for loop to link everything. I like being able to slap my dotfiles on any box with my only dependencies being `bash` and either `git` or `curl | tar xzf`. At Berkeley I spent a lot of time sshing into various machines where I wasn’t root and I was only gonna use the system for a few hours. Like sshing in to each desktop in a computer lab looking for one nobody is running a build on.
It’s worked fine for me for 15 years, macOS, many Linux distros, FreeBSD.
You're missing Windows, GUI apps, and the other dozens of cli apps above 12? Also cases where symlinks break because apps delete configs before saving and the ability to differentiate between systems easier. Also the final output config is cleaner/more readable if cross-OS compatibility is offloaded to a config manager. Then templates/vars can make configs cleaner /easier to update (e.g. moved some portable apps from C to D to save ssd space, can update one var).
Also can limit config diff noise by ignoring unimportant changes like latest app window position
So during my college days and a bit after that as well I used these tools because these tools were there to be used. I then learned it is not a problem for me, it never was. I used them for the sake of using them. So I stopped using those tools and tools like config backup etc.
I think such tools will be useful for people who use hundreds of apps and have to often migrate/reset or replicate those setups.
Kind of like you, my .dotfiles folder is a private github repo now which has barely 10 files and I don't even use symlinks anymore.
So I think it's also kind of a hobby, if I may say so.
chezmoi provides a handy table for features it and other dotfile managers have. I just use a bare git repo cause it's simple but i have wanted to have easier diffs between machines and secrets management at times.
If that works for you, great. I split files up into multiple repos and manage them with VCSH. The modular approach lets me configure multiple machines differently. I have config on my work laptop that shouldn’t end up on my personal devices, vice versa. I don’t really need my i3 config on my MacBook Pro. Ditto for XDG paths, just as I have macOS config that doesn’t have a natural fit on a Linux desktop.
I could use one repo for work and one for personal and live with the mess of useless files, but I like the cleanliness and having simple git histories. I also don’t have to have conditional statements all over the place.
I deploy my dotfiles somewhat regularly. At my day job I almost exclusively work on virtual machines, with sometimes different distros. Being able to install my usual setup (fish for the shell, helix as the editor, and a bunch of tools like eza and bat) in a few commands just saves me time.
Now to be fair, since I use rotz for this, I also install extra packages with it. So its not purely dotfiles.
Depends on your requirements. For example, if you have any values you want to keep secret in your config files, then using a config manager can help you to not expose them in a Git repository. Also, if you work across multiple operating systems, you can use config managers to alter your config files based on the current OS.
I use home-manager for my dotfiles, and they manage quite a few things.
For example:
1. My editor config (neovim) including downloading and installing all my plugins, including the dependencies of the plugins (including deno, rust-analyzer, clippy, etc)
2. All the other tools I use, like ripgrep, python, and so on, including installing the same version on every machine I've got.
3. A bunch of misc programs and scripts I've written for myself, including all their dependencies
4. All the xdg configuration to open http links in the right browser profile, pdfs in evince, etc, as well as all the programs needed for that
5. systemd user units to run various daemons, like syncthing to sync some documents between computers, gpg-agent, etc etc.
And this works on all machines running any linux distro, from arch linux to nixos to ubuntu.
home-manager is just another dotfile manager, but since nix makes packages isolated, such that my user version of $pkg doesn't conflict or depend on the host version, home-manaer can also safely manage applications I run, like my editor, browser, developer tools, systemd units, etc etc etc.
I agree that most dotfile managers are weird overengineered projects that could have been a short shell script.
I think nix+home-manager is a weird overengineered project that could not have been a shell script.
Stow is usually trivially installable using the package manager while I'm installing git. Not nearly as full featured as chezmoi but gets the job done for me.
My homedir is just a git repo, similar to https://www.atlassian.com/git/tutorials/dotfiles. The .git folder has a different name so that git commands aren't accidentally applied to it. What I love most about this is keeping my homedir clean - I can see what files are new (untracked) and either delete them or add to .gitignore
Very funny to me that Java's initial appeal: it's easy to deploy "everywhere"; is now it's disadvantage (you need a whole Java setup with JAVA_HOME and God knows what else).
Now the bar for GUI apps is cross-compilation to deployable web, Windows, Linux (Electron), Android, iOS (? I don't know I don't use/develop for Apple products) versions from running a simple command.
And for the CLI world, well, almost everyone is on Linux x86-64, or maybe arm, so a few static binaries (or "virtually" static -- depending only on glibc) are king for deployment.
I don’t find installing a JVM a massive amount of work (no more so than any other interpreted language), but nowadays you can AOT compile Java to a native binary if that’s your hang-up:
It's not as painless as you make it seem though. Among other things, the compiler needs to know reflectively accessed program elements ahead-of-time.
Unfortunately people writing libraries do all kinds of things just because they can and as such I've almost never been able to just simply AOT compile something without more manual efforts.
There are trade-offs using Native Image, for sure. Part of eliminating the JVM is that you won't have the JVM at runtime so you can dynamically load classes. Consequently you need to AOT compile any code you'd dynamically load as well. Release-over-release the tooling and support for dealing with reflection have become more user friendly. More of it is auto-detected during native image build and the remainder can be generated by a runtime agent (at least in my experience). I expect it'll be even easier with the new 25 release.
We've been shipping TruffleRuby as native image builds for years. Other Truffle languages have as well. And it's been quite popular with microservice frameworks. Recently I saw someone on the GraalVM Slack say they AOT compiled a large JavaFX application.
It's work, but probably far less than a rewrite in another language and the tooling is getting better. Obviously I can't speak to your experience, but if you haven't looked at it in a while it might be worth giving newer releases a shot.
Thank you for the insight. It has been a while and now I do want to give it a try again! Maybe it could be nice for small CLI applications instead of using Go.
How is it performance wise? Are there some big things/roadblocks to be aware of?
Half the battle is figuring out which JDK (or is it JRE??) version to install. I still have nightmares navigating the maze which is Oracle's site and trying to find the right download, only to have installed the wrong thing.
Installing the latest OpenJDK LTS release will almost certainly work for you. Java is pretty good about backwards compatibility. I'm not sure when you last tried, but you probably don't need to muck around with Oracle JDK builds at at all.
A standalone POSIX shell is far easier to deploy. Something in Rust needs to be packaged for your distro. Want to use another distro where it isn't packaged? Build it from source.
In fact, I'm gonna rewrite my dotfiles manager from Rust into POSIX sh.
It means I can install it easily and it's probably going to work well on the first try, and it'll likely start up and run fast.
It also uses clap for argument parsing so I know I can run it with `--help` to discover its options, and that the parsing of flags is likely not buggy, and consistent with other Rust tools I use.
None of this is _guaranteed_ with Rust, but the tooling and libraries make it so much easier for you to succeed at making a fast and robust piece of software. So for me "written in Rust" is usually a quality indicator of sorts. It's not 100% though, there will always be misses because it's still very possible to write bad software in any language.
It can also serve an indicator of being in the know and with the times while also being performance-, close-to-the-metal oriented. "A dot file manager not written in Fortran, but one that could have been written in Python, but actually written in Rust"
Likely no dependency hell in pip or npm. Likely fast and well thought out. Not sure fire things, but given the choice between a program written in Rust (or Go) vs one written in JavaScript or (especially) Python, the former two win every time.
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 haven't looked at this one yet, but until someone compares it to Chezmoi and points out where it's better I'm not even looking attention I fear. Chezmoi is just that good.
For the sake of answering the parent question with regard to Chezmoi specifically: Chezmoi is a very comprehensive dotfiles manager. It can do a lot of things. More than any other I'm aware of.
More does not necessarily equal better, though. I think that's a matter of personal preference. I tried Chezmoi for a while and ultimately decided it was just a lot more levers at my disposal than I really wanted to even think about.
Dotter, by contrast, is a lot more minimal. Dotter is little more than a symlink manager plus templating engine plus config files to declare what machines need what config.
Chezmoi is all that, and does a lot more: encryption/decryption (even has password manager integrations), automatic push/pull. It's also designed so that you can add or manage files regardless of what your current working directory is (via commands like `chezmoi edit/add`).
In my case, after deciding I wanted to go for the minimal end of things, I almost went for GNU Stow however, I wanted templating functionality and I liked dotter's "packages" system for defining what files a given computer needs.
And very much a personal bias here: I found the learning curve of Chezmoi templates not great. I'm also not a big fan of the fact that Chezmoi relies on you naming your source files in particular ways in order to determine what the target file permissions should be.
Chezmoi manages stuff that's in my /home - configurations, scripts in ~/bin/ etc. It also installs a bunch of applications with a runonce_ -script both on Linux and MacOS.
Ansible makes sure the correct system-level packages are installed, things in /etc/ are set up the way I like etc. There's a bunch of overlap with the packages installed by ansible and Chezmoi - but I run `chezmoi update` multiple times a week an I can run it on any computer I'm on. Ansible is for Big Things.
Then I have an opentofu setup that manages a bunch of docker containers, keeping them as stateful as possible.
For daily simple things, I can just edit any config file, add it to chezmoi and push it to git. Then on any machine I can `chezmoi update` and everything is synced.
For example in my dotfiles repo I'll have `etc/pacman.d/01-options.conf` and the dotfiles install script will symlink that to `/etc/pacman.d/01-options.conf`. This way the source of truth is always in a single dotfiles repo.
This strategy has worked well for dotfiles I use on Arch, Debian, Ubuntu and macOS. It includes support for WSL 2 too. The install script has been working with this set up for years to run 1 single command and have everything work where work in this case is installing and configuring a bunch of tools I use. An example is here https://github.com/nickjj/dotfiles.
I found it quite useful. My main use case for it is managing the same dotfiles for Windows and Linux. Specifically that neovim uses different folders and I can set that per OS in dotter.
It also allows for including our not including a config based on an executable being available which can be useful.
It requires some configuration, depending on how many of its features you use but I think it's worth it.
If all you want is GNU Stow with a bit nicer UX, I wrote and have been using https://github.com/bbkane/fling for a few years now. See the demo gif in the README for the UX
I was using "just git" until I realized I've started writing a whole bunch of scripts of various types to recreate ("ad-hoc, informally specified and bug-ridden...") functionality that chezmoi offers out of the box and has already tested in the field.
How 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?
How 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.
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
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`
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
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.
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 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?
You're missing the empathetic way to comment on someone's obviously unpaid, labor-of-love work. Instead the conversation is about you: your years of seeing "projects like these", your smart, minimal way of managing your config. Make a project and show it to us. Save your pathos for its documentation.
I use chezmoi, and I didn’t have to write a 50-line script - just install chezmoi on a new machine, run a command pointing it to a git repo, and up pop all the dot files and configs I need to have a consistent environment everywhere.
Chezmoi also handles variations in config files for personal vs. Work machines, or even differences between machines themselves.
I agree it’s not a tremendous lift to write a bespoke solution for this (and I did so in the past) but at some point it becomes lower-effort to use something off the shelf.
In addition to that, chezmoi templating can be used to fill in environment variables like secret keys, you just need to unlock rbw or whatever other password manager it is that you use. I have some that I export in my shell config, and this setup allows me to have the repo in a public place and not worry about who finds it.
+1, I also don’t understand these tools. Especially these days, many apps are using ~/.config so i barely need a for loop to link everything. I like being able to slap my dotfiles on any box with my only dependencies being `bash` and either `git` or `curl | tar xzf`. At Berkeley I spent a lot of time sshing into various machines where I wasn’t root and I was only gonna use the system for a few hours. Like sshing in to each desktop in a computer lab looking for one nobody is running a build on.
It’s worked fine for me for 15 years, macOS, many Linux distros, FreeBSD.
You're missing Windows, GUI apps, and the other dozens of cli apps above 12? Also cases where symlinks break because apps delete configs before saving and the ability to differentiate between systems easier. Also the final output config is cleaner/more readable if cross-OS compatibility is offloaded to a config manager. Then templates/vars can make configs cleaner /easier to update (e.g. moved some portable apps from C to D to save ssd space, can update one var). Also can limit config diff noise by ignoring unimportant changes like latest app window position
So during my college days and a bit after that as well I used these tools because these tools were there to be used. I then learned it is not a problem for me, it never was. I used them for the sake of using them. So I stopped using those tools and tools like config backup etc.
I think such tools will be useful for people who use hundreds of apps and have to often migrate/reset or replicate those setups.
Kind of like you, my .dotfiles folder is a private github repo now which has barely 10 files and I don't even use symlinks anymore.
So I think it's also kind of a hobby, if I may say so.
chezmoi provides a handy table for features it and other dotfile managers have. I just use a bare git repo cause it's simple but i have wanted to have easier diffs between machines and secrets management at times.
https://www.chezmoi.io/comparison-table/
If that works for you, great. I split files up into multiple repos and manage them with VCSH. The modular approach lets me configure multiple machines differently. I have config on my work laptop that shouldn’t end up on my personal devices, vice versa. I don’t really need my i3 config on my MacBook Pro. Ditto for XDG paths, just as I have macOS config that doesn’t have a natural fit on a Linux desktop.
I could use one repo for work and one for personal and live with the mess of useless files, but I like the cleanliness and having simple git histories. I also don’t have to have conditional statements all over the place.
I deploy my dotfiles somewhat regularly. At my day job I almost exclusively work on virtual machines, with sometimes different distros. Being able to install my usual setup (fish for the shell, helix as the editor, and a bunch of tools like eza and bat) in a few commands just saves me time.
Now to be fair, since I use rotz for this, I also install extra packages with it. So its not purely dotfiles.
> What am I missing?
Depends on your requirements. For example, if you have any values you want to keep secret in your config files, then using a config manager can help you to not expose them in a Git repository. Also, if you work across multiple operating systems, you can use config managers to alter your config files based on the current OS.
I use home-manager for my dotfiles, and they manage quite a few things.
For example:
1. My editor config (neovim) including downloading and installing all my plugins, including the dependencies of the plugins (including deno, rust-analyzer, clippy, etc)
2. All the other tools I use, like ripgrep, python, and so on, including installing the same version on every machine I've got.
3. A bunch of misc programs and scripts I've written for myself, including all their dependencies
4. All the xdg configuration to open http links in the right browser profile, pdfs in evince, etc, as well as all the programs needed for that
5. systemd user units to run various daemons, like syncthing to sync some documents between computers, gpg-agent, etc etc.
And this works on all machines running any linux distro, from arch linux to nixos to ubuntu.
home-manager is just another dotfile manager, but since nix makes packages isolated, such that my user version of $pkg doesn't conflict or depend on the host version, home-manaer can also safely manage applications I run, like my editor, browser, developer tools, systemd units, etc etc etc.
I agree that most dotfile managers are weird overengineered projects that could have been a short shell script.
I think nix+home-manager is a weird overengineered project that could not have been a shell script.
I just use a git repo and GNU Stow similar to the approach in this post (I'm not the author of the post):
https://tamerlan.dev/how-i-manage-my-dotfiles-using-gnu-stow...
Stow is usually trivially installable using the package manager while I'm installing git. Not nearly as full featured as chezmoi but gets the job done for me.
My homedir is just a git repo, similar to https://www.atlassian.com/git/tutorials/dotfiles. The .git folder has a different name so that git commands aren't accidentally applied to it. What I love most about this is keeping my homedir clean - I can see what files are new (untracked) and either delete them or add to .gitignore
Thanks for the post, it's from your post that I adapt and find a way for my own use.
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.
Easy to deploy, usually single static binaries. Same goes with Golang projects. Polar opposite of java (which I'll totally ignore).
Very funny to me that Java's initial appeal: it's easy to deploy "everywhere"; is now it's disadvantage (you need a whole Java setup with JAVA_HOME and God knows what else).
Now the bar for GUI apps is cross-compilation to deployable web, Windows, Linux (Electron), Android, iOS (? I don't know I don't use/develop for Apple products) versions from running a simple command.
And for the CLI world, well, almost everyone is on Linux x86-64, or maybe arm, so a few static binaries (or "virtually" static -- depending only on glibc) are king for deployment.
I don’t find installing a JVM a massive amount of work (no more so than any other interpreted language), but nowadays you can AOT compile Java to a native binary if that’s your hang-up:
https://www.graalvm.org/jdk24/reference-manual/native-image/
There’s a new LTS release with improvements coming out next week.
It's not as painless as you make it seem though. Among other things, the compiler needs to know reflectively accessed program elements ahead-of-time.
Unfortunately people writing libraries do all kinds of things just because they can and as such I've almost never been able to just simply AOT compile something without more manual efforts.
There are trade-offs using Native Image, for sure. Part of eliminating the JVM is that you won't have the JVM at runtime so you can dynamically load classes. Consequently you need to AOT compile any code you'd dynamically load as well. Release-over-release the tooling and support for dealing with reflection have become more user friendly. More of it is auto-detected during native image build and the remainder can be generated by a runtime agent (at least in my experience). I expect it'll be even easier with the new 25 release.
We've been shipping TruffleRuby as native image builds for years. Other Truffle languages have as well. And it's been quite popular with microservice frameworks. Recently I saw someone on the GraalVM Slack say they AOT compiled a large JavaFX application.
It's work, but probably far less than a rewrite in another language and the tooling is getting better. Obviously I can't speak to your experience, but if you haven't looked at it in a while it might be worth giving newer releases a shot.
Thank you for the insight. It has been a while and now I do want to give it a try again! Maybe it could be nice for small CLI applications instead of using Go.
How is it performance wise? Are there some big things/roadblocks to be aware of?
Half the battle is figuring out which JDK (or is it JRE??) version to install. I still have nightmares navigating the maze which is Oracle's site and trying to find the right download, only to have installed the wrong thing.
Installing the latest OpenJDK LTS release will almost certainly work for you. Java is pretty good about backwards compatibility. I'm not sure when you last tried, but you probably don't need to muck around with Oracle JDK builds at at all.
A standalone POSIX shell is far easier to deploy. Something in Rust needs to be packaged for your distro. Want to use another distro where it isn't packaged? Build it from source.
In fact, I'm gonna rewrite my dotfiles manager from Rust into POSIX sh.
It means I can install it easily and it's probably going to work well on the first try, and it'll likely start up and run fast.
It also uses clap for argument parsing so I know I can run it with `--help` to discover its options, and that the parsing of flags is likely not buggy, and consistent with other Rust tools I use.
None of this is _guaranteed_ with Rust, but the tooling and libraries make it so much easier for you to succeed at making a fast and robust piece of software. So for me "written in Rust" is usually a quality indicator of sorts. It's not 100% though, there will always be misses because it's still very possible to write bad software in any language.
It’s the mark of a good programming language that you can, with sufficient effort, write bad code.
Maybe it’s a way to attract contributors?
It can also serve an indicator of being in the know and with the times while also being performance-, close-to-the-metal oriented. "A dot file manager not written in Fortran, but one that could have been written in Python, but actually written in Rust"
Likely no dependency hell in pip or npm. Likely fast and well thought out. Not sure fire things, but given the choice between a program written in Rust (or Go) vs one written in JavaScript or (especially) Python, the former two win every time.
[flagged]
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.
Chezmoi is what you want.
I haven't looked at this one yet, but until someone compares it to Chezmoi and points out where it's better I'm not even looking attention I fear. Chezmoi is just that good.
For the sake of answering the parent question with regard to Chezmoi specifically: Chezmoi is a very comprehensive dotfiles manager. It can do a lot of things. More than any other I'm aware of.
More does not necessarily equal better, though. I think that's a matter of personal preference. I tried Chezmoi for a while and ultimately decided it was just a lot more levers at my disposal than I really wanted to even think about.
Dotter, by contrast, is a lot more minimal. Dotter is little more than a symlink manager plus templating engine plus config files to declare what machines need what config.
Chezmoi is all that, and does a lot more: encryption/decryption (even has password manager integrations), automatic push/pull. It's also designed so that you can add or manage files regardless of what your current working directory is (via commands like `chezmoi edit/add`).
In my case, after deciding I wanted to go for the minimal end of things, I almost went for GNU Stow however, I wanted templating functionality and I liked dotter's "packages" system for defining what files a given computer needs.
And very much a personal bias here: I found the learning curve of Chezmoi templates not great. I'm also not a big fan of the fact that Chezmoi relies on you naming your source files in particular ways in order to determine what the target file permissions should be.
> naming your source files in particular ways in order to determine what the target file permissions
How does dotter handle permissions?
> does a lot more: encryption/decryption (even has password manager integrations), automatic push/pull.
But you don't have to learn about it / use it?
Wait until you get a load of nix's home manager!
How do you manage system wide settings? I've been using ansible, but it seems a bit overkill. I feel it's over complicating things.
I have a multi-tier system.
Chezmoi manages stuff that's in my /home - configurations, scripts in ~/bin/ etc. It also installs a bunch of applications with a runonce_ -script both on Linux and MacOS.
Ansible makes sure the correct system-level packages are installed, things in /etc/ are set up the way I like etc. There's a bunch of overlap with the packages installed by ansible and Chezmoi - but I run `chezmoi update` multiple times a week an I can run it on any computer I'm on. Ansible is for Big Things.
Then I have an opentofu setup that manages a bunch of docker containers, keeping them as stateful as possible.
For daily simple things, I can just edit any config file, add it to chezmoi and push it to git. Then on any machine I can `chezmoi update` and everything is synced.
I use my dotfiles repo for this.
For example in my dotfiles repo I'll have `etc/pacman.d/01-options.conf` and the dotfiles install script will symlink that to `/etc/pacman.d/01-options.conf`. This way the source of truth is always in a single dotfiles repo.
This strategy has worked well for dotfiles I use on Arch, Debian, Ubuntu and macOS. It includes support for WSL 2 too. The install script has been working with this set up for years to run 1 single command and have everything work where work in this case is installing and configuring a bunch of tools I use. An example is here https://github.com/nickjj/dotfiles.
Not GP.
I tarball /etc. On a new system, I restore config quite carefully.
I found it quite useful. My main use case for it is managing the same dotfiles for Windows and Linux. Specifically that neovim uses different folders and I can set that per OS in dotter.
It also allows for including our not including a config based on an executable being available which can be useful. It requires some configuration, depending on how many of its features you use but I think it's worth it.
Thanks. I’m between Omarchy and MacOS mostly, but sometimes Windows, too. Seems worth putting some time into it.
I've been using "homegit" for years and never felt the need for a replacement.
https://www.atlassian.com/git/tutorials/dotfiles
great tip! also for /etc
If all you want is GNU Stow with a bit nicer UX, I wrote and have been using https://github.com/bbkane/fling for a few years now. See the demo gif in the README for the UX
I made a post recently on HN about this. All you need is git. It does everything. I didn't know why people want symlinks and everything else.
https://ericgreer.info/post/2025-08-31-simple-dotfiles-scrip...
I was using "just git" until I realized I've started writing a whole bunch of scripts of various types to recreate ("ad-hoc, informally specified and bug-ridden...") functionality that chezmoi offers out of the box and has already tested in the field.
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
How 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?
using windows is out of scope for my lifestyle
Different branches for each OS.
How does this help
> ignore "last_update_time" field diff
Also, OS-specific is in the env var (can also be machine specific, so now you have OS*machine number of branches?)
sounds annoying af
branches and symlinks . Don't throw out the 99% solution because it's missing 1%
How 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.
it's just a tradeoff
"handles dotfiles better than any bespoke platform" means there are no tradeoffs
it means the tradeoffs are the most reasonable. There's nothing in this world with no tradeoffs. Even this conversation has tradeoffs.
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
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.
https://dev.to/tonymet/how-to-put-everything-in-git-2b3d This is a variation of the same idea with some illustrations
you could think of it as a "monorepo" for multiple machines
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`
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
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.
Try Stow. You can create packages for your stuff and symlink the files as needed. I have packages like git, shell, mail,…
stow is great and I used it for many years. it's very "unix-y" in that it favors FS entries over complicated DBs / config.
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 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.
Wish there were a detailed comparison to some other managers like chezmoi
Call a potential fork 'yolk'.