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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html