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

From: Jakub Narebski <[email-masked]>
Date: Sun, 10 Dec 2006 19:10:16 +0100

Kyle Moffett wrote:

> 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).

This contradict git philosophy of "tracking contents".

> 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.

Wouldn't it be better to add another field in the tree object, that
instead of storing "(filemode, link to contents, name)" it would
store "(filemode, link to extended attributes, link to contents, name)"
where "filemode" is mode of a file of which git uses only a few bits
(is a directory, is a symlink, is a file, is a executable file),
and "link to" is sha1 of appropriate blob (or tree) object? Extended
attributes could be stored in new type of object, or just in blob
object. Well, you'd have to extend index in similar way (and add
a way to store extended attributes for directories in index; nowit only
stores info about files).

This of course breaks backwards compatibility...

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git