Re: Using GIT to store /etc (Or: How to make GIT store all file permission bits)

From: Andy Parkins <andyparkins@gmail.com>
Date: Dec 12, 2006, 15:53 UTC
Message-ID: <200612121553.37499.andyparkins@gmail.com>
In-Reply-To: <8900B938-1360-4A67-AB15-C9E84255107B@mac.com>

On Tuesday 2006 December 12 13:49, Kyle Moffett wrote:

Show 5 quoted lines

> Hmm, ok.  It would seem to be a reasonable requirement that if you
> want to change any of the "preserve_*_attributes" config options you
> need to blow away and recreate your index, no?  I would probably
> change the underlying index format pretty completely and stick a new
> version tag inside it.

I wonder if git's skill at managing content is the answer? Rather than mess around with git's internals, the index, or the object database; how about simply having a pre-commit script that writes out a file that looks like:

-rw-r--r-- andyp andyp CHANGES -rw-r--r-- andyp andyp COPYING -rw-rw-r-- andyp andyp CREDITS -rw-r--r-- andyp andyp Configure -rw-rw-r-- andyp andyp Makefile -rw-r--r-- andyp andyp README

If /that/ file were stored in the repository and you had a script that could read that file and apply the permissions after a checkout you'd have what you want.

If the permissions of a file changed but the content didn't, then this ".gitpermissions" file would have changed content but the file itself would remain the same. If the content changed but not the permissions then ".gitpermissions" would be untouched.

Assuming that you're allowed to mess with the index in pre-commit (I haven't checked), one half of it can be automatic. I suppose you could also plead for a post-checkout hook to apply those permissions and the whole lot would be transparent.

Andy

-- 
Dr Andy Parkins, M Eng (hons), MIEE