Should I avoid using git to track individual files with separate history, such as in /var/named?

Solution 1:

This is straying into "quite subjective" territory. But...

I see nothing wrong with using git to track this sort of thing. Yes, it was built for tracking large, complex collections of inter-related source files. That doesn't mean it isn't just as suited to tracking small collections of non-related files.

Personally, I use etckeeper to track /etc on my servers, using the git back-end. Works great. When installed from Ubuntu's apt repo, it comes with nice hooks into apt, so it'll automatically kick off a commit coincident with each new package install. Pretty handy.

Anyway, give it a try, it's not going to hurt anything, and if you end up wanting to switch to another version control system in the future, there are plenty of migration tools available.

Solution 2:

Subjective territory indeed. I dislike etckeeper, what it does is it creates a very messy history of /etc. Now for /var/named (I assume this is where your zones are defined) it might be better, especially if you only have a few zones, but it would still be an ugly hack.

I find that the "correct" way of doing it is to use Puppet or similar other configuration management software. Instead of configuring your servers, you write Puppet code that configures your servers. I use mercurial (but you may use git) to manage the repository of Puppet code. It's useful to branch and merge (e.g. you are working on a new configuration, which you are not certain is tested enough, and then you must urgently fix a problem in a production server; in this case you branch from the stable version and later you merge). The combination of Puppet+DVCS is very useful and very clean, but Puppet is a small beast that needs a little time to tame, and bind is particularly tricky to do right with Puppet because of the zone serial numbers.

Update:

I have been thinking about it and I tend to conclude that there is nothing wrong in using git to keep track of /var/named, and that it's not an ugly hack. Yes, the files are related. Yes, you might want to clone in order to make a serious revision of your configuration, branch, in order to maintain your production configuration while revising, and merge, when you finish the revision (although all this might be unusual).

A bit off topic, but there are two things about bind's configuration that I dislike. First, in order to add a zone I need to add/modify two files: named.conf, and the zone file. This is unnecessarily complicated. I'd prefer a setup similar to apache's, with zone files in /etc/bind/zones-available, symlinked from /etc/bind/zones-enabled, without the need to touch named.conf. Second, the serial numbers are a nuisance. We mostly automate their maintenance; in Puppet-managed machines I have a shell script that fixes them, and in others I use a vim plugin. The fact that we automate them means they could well be absent. File timestamps could be used instead. The serial numbers will create some ugliness in the repository history, but this is a problem of bind, and not a problem of git, or of the practice of using git for tracking the bind configuration.

Solution 3:

Ask yourself...

Would I ever "revert" to a particular commit in git, if it covered all of /etc?

Would I ever "merge" a commit to my current state, if it covered all of /etc?

I'm guessing the answer is NO, NO, NO.

If so, git is the wrong tool. Git is tracking a tree of files, not a single file. This is why I argue for RCS for single files.