From: David Härdeman <david@hardeman.nu>
Date: Wed, 19 Sep 2007 19:16:07 GMT
Subject: Re: metastore (was: Track /etc directory using Git)
Message-ID: <20070919191607.GE13683@hardeman.nu>
In-Reply-To: <20070916060859.GB24124@piper.oerlikon.madduck.net>

On Sun, Sep 16, 2007 at 08:08:59AM +0200, martin f krafft wrote:
>also sprach Daniel Barkalow <barkalow@iabervon.org> [2007.09.15.2156 +0200]:
>> Configuration options only apply to the local aspects of the repository. 
>> That is, when you clone a repository, you don't get the configuration 
>> options from it, in general. And changing configuration options on a 
>> repository does not have any effect on the content it contains. So 
>> configuration options aren't appropriate.
>
>Sure they are. Just like git-commit figures out your email address 
>if user.email is missing from git-config, or core.sharedRepository 
>or core.umask deal with permissions only when you tell them to, 
>you'd have to enable core.track or else git would just do what it
>does right now.
>
>> Git doesn't have any way to represent owners or groups, and they
>> would need to be represented carefully in order to make sense
>> across multiple computers. If you're adding support for
>> metadata-as-content (for more than "is this a script?"), you
>> should be able to cover all of the common cases of extended stuff,
>> like AFS-style ACLs.
>
>Ideally, git should be able to store an open-ended number of
>properties for each object, yes.

I haven't followed the discussion at all I must admit (I wrote metastore 
as a quick hack to store some extended metadata and it works for my 
purposes as long as I don't do anything fancy). But I agree, if any 
changes were made to git, I'd advocate adding arbitrary attributes to 
files (much like xattrs) in name=value pairs, then any extended metadata 
could be stored in those attributes and external scripts/tools could use 
them in some way that makes sense...and also make sure to only update 
them when it makes sense.

-- 
David Härdeman