threads / discuss / 14907

keeping /etc under git with etckeeper

Subject: keeping /etc under git with etckeeper

## tl;dr

4 messages between Aug 9, 2008 and Aug 10, 2008.

replies: 3people: 4as markdown or json

Pierre-Julien Bringer· Aug 9, 2008, 18:48 UTC · lore

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

martin f krafft· Aug 9, 2008, 19:16 UTC · re: Pierre-Julien Bringer · lore

Re: keeping /etc under git with etckeeper

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

Miklos Vajna· Aug 9, 2008, 23:42 UTC · re: Pierre-Julien Bringer · lore

Re: keeping /etc under git with etckeeper

On Sat, Aug 09, 2008 at 08:48:39PM +0200, Pierre-Julien Bringer <pj.bringer@gmail.com> wrote:

Show 5 quoted lines

> 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.

Edward Z. Yang· Aug 10, 2008, 03:15 UTC · re: Pierre-Julien Bringer · lore

Re: keeping /etc under git with etckeeper

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.