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

> The simplest solution which admittedly breaks the ability of older  
> GITs to read the data from a file with attributes (ignoring the ext- 
> attrs themselves) is to create a new "file-with-extended-attributes"  
> object which contains a binary concatenation (with length bytes and  
> attribute names and such) of the file and its extended attributes.   
> That breaks the old GIT assumption that permission and security data  
> is part of the directory not the file, but it's more in-line with the  
> way extended attributes are attached to the inodes in the filesystem  
> (although that doesn't really matter IMO).

> Alternatively I might be able to add a new entry to each tree object  
> with invalid extended file mods bits (IE: Neither a directory, a  
> file, nor a symlink), or perhaps an entry with an empty name, which  
> points to a new "extended attribute table".  That table could either  
> map from (entry, attribute) => (data) or from (entry) =>  
> ((attribute,data),(attribute,data),[...]), depending on which would  
> be more efficient.  It's essential that the overhead for non-ext-attr  
> repositories is O(1) and ideally the overhead for a bunch of files  
> with the same ext-attr is O(size-of-ext-attr) + O(number-of-files- 
> with-that-attr), although that may vary depending on implementation.