...making Linux just a little more fun!
Rick Moen [rick at linuxmafia.com]
[[[ This is a followup to "Version control for /etc" in https://linuxgazette.net/144/lg_mail.html -- Kat ]]]
A promising solution to the exact problem discussed earlier -- put together by my friend Joey Hess. See: https://kitenet.net/~joey/code/etckeeper/ One key ingredient is David H?rdeman's "metastore" (https://david.hardeman.nu/software.php), used to capture metadata that git would otherwise ignore.
----- Forwarded message from Jason White <jason@jasonjgw.net> -----
Date: Tue, 25 Dec 2007 19:07:59 +1100 From: Jason White <jason@jasonjgw.net> To: luv-main <luv-main@luv.asn.au> Subject: etckeeperFor those who are running Debian or debian-derived distributions, there is a relatively new package, etckeeper, which I have found rather useful: it maintains a revision history of /etc in a Git repository, including file permissions and other metadata not normally tracked by Git.
It is also invoked by Apt, using standard Apt mechanisms, to commit changes introduced into /etc when packages are installed or removed.
I don't know whether there exist any similar tools for non-Debian distributions.
----- End forwarded message -----
Rick Moen [rick at linuxmafia.com]
I wrote:
> A promising solution to the exact problem discussed earlier -- put together > by my friend Joey Hess. See: https://kitenet.net/~joey/code/etckeeper/ > One key ingredient is David H<a4>rdeman's "metastore" > (https://david.hardeman.nu/software.php), used to capture metadata that > git would otherwise ignore.
Here's Joey's announcement and explanation of the software (explaining in particular how it avoids some of the drawbacks of IsiSetup): https://kitenet.net/~joey/blog/entry/announcing_etckeeper/ Particularly winning is its close integration (on Debian and similar) into apt, so that changes to /etc/ resulting from package operations get checked in automatically.
etckeeper being an excellent idea whose time has definitely come, Mathieu Clabaut has also adapted it to use the increasingly popular revision control system Mercurial (hg) as its back-end storage, instead of git (although, as built locally on my Xubuntu iBook, v. 0.6 still ends up needing package "git-core"). See:
https://hg.sharesource.org/etckeeperhg https://sharesource.org/project/etckeeperhg/
I notice that Ubuntu does package etckeeper (but not yet the Mercurial variant) in its "Hardy Heron" development branch's "universe" collection.
By the way, here's a nice little user tutorial on git: https://hwasungmars.wordpress.com/2007/11/25/journey-to-a-backup-solution-git/
And a separate Nov. 2007 analysis of the need for something like etckeeper (mentioning it only in a followup) that cites an earlier solution by Michael Prokop using Mercurial (https://michael-prokop.at/blog/2007/03/14/maintain-etc-with-mercurial-on-debian/), which itself points to Enrico Zini's method of doing similar things in svk (a superset of subversion that supports decentralised operation and in general improves it): https://lists.debian.org/debian-devel/2005/02/msg00495.html
(As I believe was noted in earlier go-rounds of this subject in TAG, one still rather rare quality in revision control systems is the ability to not have metadata rubbish sitting around in .CVS, .svn, or equivalent directories/files in one's working areas, and svk is among the few that solve that problem.)
Another, and related, recent contribution from Joey is "mr" (https://kitenet.net/~joey/code/mr/):
The mr(1) command can checkout, update, or perform other actions on a set of repositories as if they were one combined respository. It supports any combination of subversion, git, cvs, mecurial, bzr and darcs repositories, and support for other revision control systems can easily be added.
Rick Moen [rick at linuxmafia.com]
Reminder about the GIT_DIR variable, for git.
----- Forwarded message from Jason White <jason@jasonjgw.net> -----
Date: Fri, 4 Jan 2008 10:10:43 +1100 From: Jason White <jason@jasonjgw.net> To: luv-main@luv.asn.au Subject: Re: etckeeperOn Thu, Jan 03, 2008 at 10:31:53AM -0800, Rick Moen wrote:
> (As I believe was noted in earlier go-rounds of this subject in TAG, > one still rather rare quality in revision control systems is the > ability to not have metadata rubbish sitting around in .CVS, .svn, > or equivalent directories/files in one's working areas, and svk is > among the few that solve that problem.)
I haven't tried it, but apparently the GIT_DIR environment variable allows you to refer to a git repository directory anywhere in the file system. Provided you set it before invoking git, the problem noted by Rick should be overcome.
This could be useful with etckeeper if your /etc happens to be in a small root partition in which you don't want space to be consumed by a .git directory.
----- End forwarded message -----
Peter Knaggs [peter.knaggs at gmail.com]
On Jan 3, 2008 4:52 PM, Rick Moen <rick@linuxmafia.com> wrote:
> Reminder about the GIT_DIR variable, for git.
The GIT_DIR does work, but there's a small quirk to be aware of:
It seems that the last component of the path specified in the GIT_DIR variable needs to be the word ".git", otherwise "git-add" won't work properly:
e.g.:
mkdir -p /tmp/git_metadata/test export GIT_DIR=/tmp/git_metadata/test mkdir /tmp/git_testdir && cd /tmp/git_testdir git-init Initialized empty Git repository in /tmp/git_metadata/test/ ls -l . .. touch file1 git-add file1 fatal: add must be run in a work treewhereas when the GIT_DIR variable ends with the word ".git", all is fine:
mkdir -p /tmp/git_metadata/.git export GIT_DIR=/tmp/git_metadata/.git mkdir /tmp/git_testdir && cd /tmp/git_testdir git-init Initialized empty Git repository in /tmp/git_metadata/test/ ls -a . .. touch file1 git-add file1 git-commit warning: unable to read /etc/mailname: Success warning: unable to read /etc/mailname: Success warning: unable to read /etc/mailname: Success warning: unable to read /etc/mailname: Success Created initial commit fc652c0: Add 0 files changed, 0 insertions(+), 0 deletions(-) create mode 100644 file1The tutorials here seem to be quite readable:
https://www.kernel.org/pub/software/scm/git/docs/tutorial.html https://www.kernel.org/pub/software/scm/git/docs/tutorial-2.html https://www.kernel.org/pub/software/scm/git/docs/everyday.html
Cheers, Peter.