keeping /etc under git with etckeeper

keeping /etc under git with etckeeper

[Pierre-Julien Bringer]

Do you think storing the etc directory in git with etckeeper is a good
thing? I've heard it was not recommended to do so for the home
directory, but also for /etc:
1 Git tries to find a link between the changes and there would
probably be none for $HOME, according to Randal Schwarz [1].
2 Git does not store permissions of files [2].
3 If Git has some sort of merge conflict on important config files
(passwd, etc...), it would be pretty bad [3].

When using etckeeper:
1 There would be a link between the changes if a commit occurs between tasks.
2 Permissions are stored thanks to Metastore.

I have only superficial experience in using git, and I don't really
know how likely it would be for things to go wrong. Merging seems to
be the dangerous operation, but using it to track linear history would
be okay. Gentoo users have been able to use RCS for a long time, but
that solution is considered to be deprecated, although it does the
job. Can experienced git users think of any reason not to use a small
subset of git for this task?


Pierre-Julien Bringer


[1] Randal Schwarz, "Git" at Google, October 12 2007, available at
http://www.youtube.com/watch?v=8dhZ9BXQgc4
[2] Git project's FAQ available at http://git.or.cz/gitwiki/GitFaq
[3] Joey Hess, November 26 2007 on vcs-home -- Discussion list for
storing ~ under VCS control, available at
http://lists.madduck.net/pipermail/vcs-home/2007-November/000102.html

Re: keeping /etc under git with etckeeper

[martin f krafft]

[-- Attachment #1: Type: text/plain, Size: 630 bytes --]

also sprach Pierre-Julien Bringer <pj.bringer@gmail.com> [2008.08.09.1548 -0300]:
> Do you think storing the etc directory in git with etckeeper is a good
> thing? I've heard it was not recommended to do so for the home
> directory, but also for /etc:

You might want to discuss this also on vcs-home@lists.madduck.net.
See http://vcs-home.madduck.net .

-- 
martin | http://madduck.net/ | http://two.sentenc.es/
 
"no work of art ever puts forward views.
 views belong to people
 who are not artists."
                                                        -- oscar wilde
 
spamtraps: madduck.bogus@madduck.net

[-- Attachment #2: Digital signature (see http://martin-krafft.net/gpg/) --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: keeping /etc under git with etckeeper

[Miklos Vajna]

[-- Attachment #1: Type: text/plain, Size: 910 bytes --]

On Sat, Aug 09, 2008 at 08:48:39PM +0200, Pierre-Julien Bringer <pj.bringer@gmail.com> wrote:
> 3 If Git has some sort of merge conflict on important config files
> (passwd, etc...), it would be pretty bad [3].
> 
> When using etckeeper:
> 1 There would be a link between the changes if a commit occurs between tasks.

I don't exactly see what the problem is here.

> 2 Permissions are stored thanks to Metastore.

Actually it no longer uses metastore, but yes, etckeeper handles
permissions properly, so it is not a problem. The second problem is
point 3) from your previous list, but that's easy to avoid: never ever
merge, rebase (or any other task that can result in a conflict) in your
/etc.

In short, if you want to just track your directory, then it's OK, but if
you want to use git to handle the config of multiple machines, it'll be
too problematic, I would not suggest doing so.

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: keeping /etc under git with etckeeper

[Edward Z. Yang]

Pierre-Julien Bringer wrote:
> Do you think storing the etc directory in git with etckeeper is a good
> thing? I've heard it was not recommended to do so for the home
> directory, but also for /etc:

I've been using etckeeper for a while now, and it's working reasonably
well. The one thing I personally don't like, however, is the fact that
etckeeper automatically commits a dirty /etc state before the
auto-commits for any installed packages. I.e. auto-commit on apt-get
GOOD, auto-commit on other changes BAD. Fortunately, it's relatively
easy to change the commit hooks to do your bidding. :-)

With carefully issued Git commands, you can have Git refuse to touch any
files when there is a merge conflict, so you can resolve it in another
checkout. Of course, Git makes it extremely easy to back out a failed
merge, so as long as there isn't an essential process polling /etc every
few seconds, you should be savvy if you revert before a reboot.