git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Jakub Narebski <jnareb@gmail.com>
To: git@vger.kernel.org
Subject: Re: Using GIT to store /etc (Or: How to make GIT store all file permission bits)
Date: Sun, 10 Dec 2006 19:10:16 +0100	[thread overview]
Message-ID: <elhidr$tr3$1@sea.gmane.org> (raw)
In-Reply-To: 28E2300C-8F7A-406F-8FDA-F8786AE95B40@mac.com

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


  reply	other threads:[~2006-12-10 18:08 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-12-10 13:40 Using GIT to store /etc (Or: How to make GIT store all file permission bits) Kyle Moffett
2006-12-10 14:49 ` Jeff Garzik
2006-12-10 15:30   ` Jakub Narebski
2006-12-10 18:10     ` Kyle Moffett
2006-12-10 18:18       ` Jakub Narebski
2006-12-10 18:26       ` Jakub Narebski
2006-12-10 18:35         ` Kyle Moffett
2006-12-11 10:39           ` Andreas Ericsson
2006-12-11 10:55             ` Jeff Garzik
2006-12-11 12:13             ` Josef Weidendorfer
2006-12-11 13:33               ` Johannes Schindelin
2006-12-11 15:07                 ` Josef Weidendorfer
2006-12-10 15:06 ` Santi Béjar
2006-12-10 17:46   ` Kyle Moffett
2006-12-10 18:10     ` Jakub Narebski [this message]
2007-01-10  1:39   ` David Lang
2007-01-10  2:30     ` Shawn O. Pearce
2007-01-10 18:34       ` David Lang
2007-01-12  0:55         ` Shawn O. Pearce
2006-12-11 10:50 ` Nikolai Weibull
2006-12-12  3:45 ` Daniel Barkalow
2006-12-12 13:49   ` Kyle Moffett
2006-12-12 15:53     ` Andy Parkins
2006-12-12 22:49       ` Using git as a general backup mechanism (was Re: Using GIT to store /etc) Steven Grimm
2006-12-12 22:57         ` Johannes Schindelin
2006-12-12 23:06           ` Steven Grimm
2006-12-13  0:01             ` Johannes Schindelin
2006-12-12 23:15         ` Martin Langhoff
2006-12-12 23:23           ` Martin Langhoff
2006-12-12 23:43         ` Using git as a general backup mechanism Junio C Hamano
2006-12-14 23:33           ` Steven Grimm
2006-12-15  0:33             ` Junio C Hamano
2006-12-13 18:10     ` Using GIT to store /etc (Or: How to make GIT store all file permission bits) Daniel Barkalow
2006-12-14  5:06       ` Chris Riddoch

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='elhidr$tr3$1@sea.gmane.org' \
    --to=jnareb@gmail.com \
    --cc=git@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).