dotfile management

[Dieterbe]

aconfmgr excludes /home by default under the assumption most people already have a different solution to manage their dotfiles. (see #47)

I realize that often system wide changes go hand in hand with a user's dotfile changes (e.g. usage of certain vim plugins will probably correspond to system wide package installation, or setting up brightness controls in a window manager typically also comes with packages installed or udev rules deployed, and so on). The ability to track those together seems quite useful.

I am currently not using a dotfile manager and am looking at solutions. Using aconfmgr itself actually does not seem like such a bad idea. As long as i can keep the general /home exclude but add selective overrides to that exclude to include some common dotfiles, that should probably work, although i haven't tried yet.

Thoughts anyone?
cheers and happy holidays :)

[CyberShadow]

I think it would be roughly similar to using a dotfiles manager which maintains a copy of the dotfiles under its management, so I think it wouldn't be all that unusual.

The approach I personally use for the home directory is to just keep it in git, directly. There is a ~/.git file (pointing to a bare repository) and everything. It's nice as there is no save/apply step; unfortunately, I can't use the same approach to manage the rest of the system, so I compromise by using aconfmgr for one and just git for the other.

[Dieterbe]

i gave this some more thought.

i think the main goal is to have system configuration and home/dotfile configuration in the same repository, but not necessarily using the same tool:

For system, aconfmgr makes sense because it "distills" state into a concise representation (e.g. not just tracking all files, but tracking installed packages and only tracking files and other changes "on top of" the installed package set). The tradeoff is that the real state and the representation live in 2 different places, and are out of sync until you call aconfmgr save or apply)

For $HOME, aconfmgr's distillation process would be pointless, and avoiding aconfmgr to keep the "real state" and the representation in the same place (your actual home dir) is convenient.
(there are some files in $HOME that could be diffed against their "stock versions" that may be found in /usr/share/, or in git repos of projects such as zprezto/oh-my-zsh/ etc, one could conceive a tool that does something similar to what aconfmgr does, but for the multitude of different approaches, and it still would only cover a subset of what's in home anyway)

So i think my conclusion is quite simple:

• aconfmgr is great at what it does for system stuff
• home stuff "direct" in git, is great
• I can achieve the best of both worlds by simply tracking ~/.config/aconfmgr along with the rest of my dotfiles in the same repo. I can then make atomic commits comprising of local config changes with their respective system wide changes (as they so often go hand in hand)

This feels like the right solution. it seems so obvious in hindsight.