| |||||||||||||
|
| |||||||||||||
/etc is a good candidate/etc is a good candidatePosted Aug 5, 2008 15:23 UTC (Tue) by alex (subscriber, #1355)In reply to: Simplified porcelains? by Sutoka Parent article: Git Magic
Every time I go into a sub directory in /etc to edit a file for config for the first time the first thing I do is: git-init-db; git-add .; git-commit -m "Initial Version" I'd tried various approaches with CVS before but it quickly turned ugly. Now I can easily roll back changes, start again or fork of in a new direction without loosing track of what I did and why.
(Log in to post comments)
Good idea Posted Aug 5, 2008 15:30 UTC (Tue) by dmarti (subscriber, #11625) [Link] Good idea, but have a look at etckeeper. It will also automatically track any changes that the package manager makes in /etc.
for now I'll hand roll Posted Aug 5, 2008 16:48 UTC (Tue) by alex (subscriber, #1355) [Link] For now I'll hand roll. I started with my whole /etc in git, no I tend to have mini-repos for each bit of /etc so it's not tied to the rest of the system. Hence I can pull my apache or exim config without the mess of the rest of /etc involved :-)
/etc is a good candidate Posted Aug 5, 2008 17:19 UTC (Tue) by mikachu (guest, #5333) [Link] You should be using "git init; git add .; git commit -m 'Initial Version'", since init-db has been deprecated since before i can remember. git-* have been since 1.5, and will not be available by default in 1.6.0.
/etc is a good candidate Posted Aug 6, 2008 6:32 UTC (Wed) by alex (subscriber, #1355) [Link] Well all the servers which I muck around with the config on run Debian which is a little behind the bleeding git edge ;-)
/etc is a good candidate Posted Aug 6, 2008 7:51 UTC (Wed) by nix (subscriber, #2304) [Link] Storing /etc in git seems like a bad idea to me, as git doesn't preserve permissions (other than the executable bit), ownership information, hard links, or any type of file other than regular files and directories.
/etc is a good candidate Posted Aug 6, 2008 8:44 UTC (Wed) by alex (subscriber, #1355) [Link] I don't store the whole of etc, usually only the bits I need to tweak/configure, e.g. /etc/apache2 or /etc/exim4
/etc is a good candidate Posted Aug 6, 2008 11:07 UTC (Wed) by rleigh (subscriber, #14622) [Link] There are, however, people who want git to be able to do this: [git storage backend for chroots] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=477942 This is essentially using git directly as a snapshottable filesystem; cloning the chroot would be effectively a git clone (and/or branch). In this case, file ownership, permissions, special files and empty directories are all features we would like git to store. I have heard there are patches in the works to implement (some of) the above, though I haven't seen them myself. This would also allow /etc to be stored directly in git. Regards, Roger
/etc is a good candidate Posted Aug 6, 2008 16:42 UTC (Wed) by iabervon (subscriber, #722) [Link] Ideally, it should be possible to have a more flexible mapping between the index and the working directory, such that the repository's contents are of the same type as any other repository (and it could be checked out as a description), but, when it's used as an actual chroot, it works directly. For example, it should be possible to work on a chroot image for some other machine without being root on the machine you're working on; this is easy if the image is stored with the "special stuff" as plain files that only translate into device nodes and permissions when in the chroot checkout. (Actually, I suspect that the ideal thing is a fakeroot/git team effort, where git stores what fakeroot stores, not what the actual filesystem stores, and you can check this out as a real chroot image if you're root, or fake it in fakeroot, or as a set of control files and data if you want that.)
/etc is a good candidate Posted Aug 6, 2008 21:33 UTC (Wed) by rickmoen (subscriber, #6943) [Link] nix wrote:Storing /etc in git seems like a bad idea to me, as git doesn't preserve permissions (other than the executable bit), ownership information, hard links, or any type of file other than regular files and directories. etckeeper's author (Joey Hess) was well aware of this; that's why it uses metastore to encode that information transparently, so that git can track it. (etckeeper's integration into Debian/*buntu package management is also a killer advantage, over just checking /etc into an RCS: Changes to /etc resulting from a package operation get checked in automatically.) Rick Moen
/etc is a good candidate Posted Aug 7, 2008 0:25 UTC (Thu) by bronson (subscriber, #4806) [Link] It doesn't use metastore anymore. A certain lwn reader didn't like having a big binary-only file in /etc and sent Joey some patches to replace it with a text file and simple find commands. ~March 17-20, 2008 I like etckeeper. When the bad stuff starts flying, it sure is nice to be able to roll back to a known good config. And the cryptographic integrity makes a nice sanity check.
|
|
||||||||||||