Thank you for this elaborate explanation and very valid use-case. I did find out that octopus merges have been used quite extensively in e.g. the Linux history as I was trawling the archives for one of the anecdotal remarks I made. I eventually found them both, by the way (post updated):

* https://lore.kernel.org/all/Pine.LNX.4.58.0506221433540.2353...

* https://www.destroyallsoftware.com/blog/2017/the-biggest-and...

I suppose whenever you've got scenarios where integrating a significant volume of unrelated work (with low probabilities of conflicts) it starts to make a lot more sense. I guess it's not really been that relevant to me personally.

Ohai! What a pleasure to both hear from you and that you enjoyed the read. I hope you're doing well yourself.

I shared your concern with letting Nix manage all configs because it felt wrong to me to have an abstraction layer over all kinds of configs. I've later realized that's got a big benefit of being able to use values across various configs, like high DPI settings for specific machines with 4k monitors as an example.

Version controlling Nix expressions is trivial since it's all just text files. So i basically use just git for that. With flake lock files you get a pretty high guarantee that rebuilding your configs (or machine setup) will be quite reproducible.

I should add that I do still have some imperative/manual steps still though, mostly setting up doom emacs.

Love this!

I should add that my Nix endeavors begun way back when I started doing Haskell because of the binary caching for Haskell libs. Nix has then gradually taken over pretty much everything I do related to software. So the OS switch was inevitable.