Re: /etc in git?

[Daniel Barkalow <barkalow@iabervon.org>]

On Wed, 18 Jan 2006, Junio C Hamano wrote:

> Adam Hunt <kinema@gmail.com> writes:
> 
> > Do you have any more details by chance?  Does it work?  Does it work
> > well?  How does one do it?
> 
> I personally feel it is a horrible and stupid thing to do, if by
> "version control /etc" you mean to have /.git which controls
> /etc/hosts and stuff in place.  It would work (git does not
> refuse to run as root).  But being a *source* control system, we
> deliberately refuse to store the full permission bits, so if
> your /etc/shadow is mode 0600 while /etc/hosts is mode 0644, you
> have to make sure they stay that way after checking things out.

At some point, people considered setting up an object type that would have 
all of the bits. That is, if you want a directory to come out literally 
the same as it went in, uid/gid/sticky-bit and all, you'd do something 
special to make this happen.

I think you could do some nifty stuff where you have git take care of 
/etc, and make all your changes to clones of the repository, push them, 
and check them out. I bet you could even have three-way merge on package 
installs this way; install the package into a fake root that has the /etc 
generated by the install of the previous version of the package (i.e., 
without your changes), commit that head, then merge that head into your 
master branch etc (in a non-real working tree, of course), check over the 
result, commit, push to the real repository, and check out. For that 
matter, you could probably generate the "package added replacing previous 
package" commit without using a working tree, directly from the package.

(Sure, it's currently set up for source control only, but the original 
theory was general content, and it should be good at producing exactly the 
right directory structure if it had a type to represent exact stuff like 
that)

	-Daniel
*This .sig left intentionally blank*