On Sat, 15 Sep 2007, Daniel Barkalow wrote:

quoted text
>> The reason why I say this should be done inside git rather than with 
>> hooks and an external tool, such as metastore is quite simple: git 
>> knows about every content entity in any tree of a repo and already has 
>> a data node for each object. Rather than introducing a parallel object 
>> database (shadow hierarchy or single file), it would make a lot more 
>> sense and be way more robust to attach additional information to these 
>> object nodes, wouldn't it?
>
> 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. And if you want to allow 
> meaningful development with this mechanism (as opposed to just archival 
> of a sequence of states of a live system)

don't underestimate the usefullness of the ability to archive and restore 
snapshots of a live system. just that ability would be wonderful to have.

the ability to checkout a copy of things elsewhere and tinker with it 
would be better, but the lack of that doesn't eliminate the utility by any 
means.

David Lang

quoted text
> , the normal case will be that 
> the metadata beyond +x is manipulated by ordinary users in some way 
> other than modifying their working directory. So the normal case here 
> will be like working on a filesystem that doesn't support symlinks or an 
> executable bit when this is important content.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html