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* - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.htmlReceived on Fri Jan 20 09:21:44 2006
This archive was generated by hypermail 2.1.8 : 2006-01-20 09:21:53 EST