On 08/16/2007 12:58 PM, Rene Herman wrote:

On 08/15/2007 03:52 PM, Kyle Moffett wrote:

quoted

If you were going to do that I'd just suggest making git aware of the 
"user.*" extended attributes and having it save those into the git 
repo along with the permission data.

Am looking at it but am not so sure that's a very good idea. I guess 
it'd be largely okay-ish to require the repo to be on a filesystem that 
supports EAs for this feature to work, but keeping the attributes intact 
over file system operations seems not all that easy (yet). Having not 
used EAs before I may be missing something but my version of "cp" for 
example (GNU coreutils 6.9) appears to not copy them. Nor do they seem 
to survive a trip through GNU tar 1.16.1. EAs appear to not be very 
useful unless every single tool supports them -- a repo should be 
resistant against simple operations like that.

Googling around, I see subversion already has this and calls the 
meta-data "properties" (svn propset/get and friends). It uses a few 
properties itself, such as the svn:executable property (which I saw is 
also the only permission bit git keeps) and svn:ignore, which serves the 
same role as the .gitignore files for git. Both those would fit into 
this scheme nicely for git as well, if git were to do something similar 
and reserve for example the "git.*" namespace for internal use.

Junio (and others), do you have an opinion on this? If these properties 
are versioned themselves such as in svn I believe it's a decidedly 
non-trivial addition (and I'm a complete git newbie) but to me, they 
look incredibly useful, both for the original "maintainers" properties 
(and anyone else one would want to come up with such as summary 
properties and author/license stuff) and even for git internal reasons 
such as sketched above.

The git-blame thing as sketched before by Linus would never be able to 
point out mailing lists, or general lists of "interested parties" for 
example, but these properties can do anything...

The svn implemention is that a single property is free-form text. As such, I 
guess a property would be just another file, although one that only lives in 
the index and is linked from the file/directory it is a property of.

Perhaps that immediately suggests an implementation to someone already 
familiar with git internals?

Rene.