managing multiple machine /etc-s with git using branches. good idea?

Question

went through multiple searches, but couldn't find a question that describes this git branch strategy idea on SU or SF. /etc count is currently < 10.

firstly, are there any obvious oversights on my part for using git branches for multiple machine etc-s? i.e. i noticed a "git branches are meant to be shortlived" in one question i browsed.

my primary motivation is the ability to quickly compare and secondarily replicate usually random individual configuration files. it'd be good to have everything pushable into a single central repo for backup.

another issue i think that might be is i'd like to have the central repo with all branches available and visible only in some central management superservermachine directory. actual production /etc-s wouldn't need to have all the history of all the other branches, just the one that's assigned to it. i believe that's possible with making a repo only track a specific remote branch. right?

Answer 1

The other question's motivation was replicating as a backup. As far as going further:

Compare works well enough (git diff, with globs, --stat and friends), but replicate is harder. You can cherry-pick if the base files are identical. You can also force checkout individual files. Mergeing will prove too hard for two reasons:

• it is designed to make branches converge. Unless you have topic branches for everything, or unless you are making a one-size-fit-all configuration with switches, this will mess up your /etc.
• it needs a common history. Even if you graft a common origin you'll have a lot of churn unrelated to the merge, which git merge will incorporate anyway.

Answer 2

I'm looking for something similar to what you propose, and I've found this interesting links:

http://jawspeak.com/2008/11/23/recommended-etckeeper-to-keep-all-your-servers-etc-in-git-or-bzr-or-hg/ http://anuradha.sayura.net/2010/01/using-git-to-manage-config-files.html Using revision control for server configuration files?