Perhaps other people have more complex use cases than me.
The main reason was because there invariably is always something slightly sensitive you don't want in a dotfile and the rest of the file is okay. Yadm uses third party tools to do jinja templating. The first one envtpl stopped being maintained, and the second one j2cli (both jinja2 templaters) aren't very well maintained either.
With chezmoi I just use the golang text/template templater. I know it will always be maintained. The integrated password manager functionality for chezmoi also works awesome too.
I did initially use stow, but symlinks is just bad. You end up with all sorts of problems with that I can't even remember. My whole dotfiles is 7MB, so if a copy is made from a "source tree" to my home dir that's okay.
Chezmoi also encouraged me to do things more deterministically based on hosts and reduce the number of "scripts" that I run significantly, which led to less bugs. I use the same set of dotfiles across a number of my systems.
https://yadm.io/docs/templates
i like yadm because it has simply no dependencies and can be installed literally anywhere on any archs (which is important to me)....
the yadm/awk templating system is good enough for me, it let you do some if host then output this or output that kind of things..... i never had a need for more.
This is how Git was designed to be used.
Using branches for this does not scale.
For example, say I have a line "export FOO=bar" in my .bashrc on one machine and "export FOO=baz" on another. If I then indent the line on the bar branch and try to merge to the other one, something has to tell the baz branch that the right line is both differences: " export FOO=baz". Except the conflict may not be so obvious to resolve as that! And whatever you do, you'll either have a "trellis" of 'n' branches if you merge, or 'n' parallel linear branches if you cherry pick everything. Both of those history layouts quickly become very hard (to me at least) to make sure they all contain everything they should and nothing they shouldn't.
Whereas with chezmoi, the bashrc file is a template that is the same on all machines that simply says "export FOO={{ fooval }}" and chezmoi does the templating. So you can just indent the line and fast-forward/apply on other machines and that's it.
As long as the patches don't conflict its fine and dandy, if there's a collision you record a resolution that fixes the conflict
1. A branch pointing to the latest nixpkgs head.
2. A branch with commit A (let's say commit A introduces a new package to nixpkgs).
3. A branch with commit B (changing some config file).
4. A branch currently at in use for your own machines, with branches 2 and 3 rebased on top of branch 1.
Every time you do anything, you'll have to remember the flow for getting the commits fetched/rebased. Which is fine if you have a DevOps team doing exactly that, but isn't too cool if you are anything other than a large company.
In Pijul, you would have a single channel (branch sort-of equivalent) and two patches (A and B) instead, which you can push independently from each other at any time if you want to contribute them back.
Darcs does the same but wouldn't scale to Nixpkgs-sized repos.
I had more problems with differences between versions than with differences between machines. tmux is the sort of program where the available config directives change every major release and there is no full backwards compatibility.
I could do it all with shell... but every few likes of custom scripting and config I can ditch is one less thing to worry about, and I don't really need VCS for just a few kb that rarely change.
I've been using a lot more VSCode extensions lately though, so perhaps I'll want to do something for that.