On Tue, Jun 19, 2018 at 11:15 AM Ian Zimmerman <i...@very.loosely.org> wrote: > > On 2018-06-18 11:34, Rich Freeman wrote: > > > Oh, the other tool you'll want to use is etckeeper to manage /etc in a > > git repo and auto-commit changes/etc with package manager hooks. That > > is a cross-distro tool, and will save your butt if you mess something > > up. > > I already do this, only without any packaging/wrapping like etckeeper, > just bare git. It's why I want to skip all the the gentoo merge > thingies, get a crack at the updated file shipped with a package, insert > this into git on a parallel branch, then merge in the git way. >
Yeah, that certainly works, and if you're disciplined it has the advantage that your git history will always be clean and reliable. The advantage of etckeeper is the PM hooks. If you have uncommitted changes in /etc when you run emerge it will just dump them all into an auto-described commit so that you don't end up with a big pile of modified files with no history. If you always manually review all your changes and commit them dutifully after every update, then I believe etckeeper should behave as one big NOOP. It really only kicks in if you're lazy about committing your changes, to ensure that they don't pile up. Then if you have an issue you can at least look at the changes since the last time you ran emerge, or the time before that, and so on. Personally I use a hybrid approach. When I go deliberately modifying config files I make my own clean commits with the stuff I know is good. Then I let etckeeper just merge in the daily cruft that I'm not really intentionally touching anyway. That means that the commits with real descriptions are known-good, and the rest are potentially-useful snapshots I can make use of if they work. But, this is all at home - I'd be more disciplined on a system I cared about. Well, then again on a system I cared about I'd probably be using ansible or whatever and not upgrading in-place anyway. -- Rich
