Re: [RFC] Plumbing-only support for storing object metadata

[david@lang.hm]

On Fri, 15 Aug 2008, Josh Triplett wrote:

>
> - Several proposals suggest storing the metadata as a tree object,
>  rather than a custom "props" object.  This makes a lot of sense.  It
>  allows Git to use existing logic for parsing, reachability
>  checking, merging, and checkouts.  On the other hand, we want to
>  optimize for the common cases such as POSIX permissions and ownership
>  rather than the unusual cases like extended attributes, so it might
>  make sense to store all the metadata for a particular object as a
>  single blob.

ahh, but if the 'tree object' that you are storing is named file.attr and 
contains just the posix permissions and ownership, there are a very small 
number of different permutations that you will see on any one system (let 
alone in any one repository), as such the duplicates will all hash to the 
same value and be combined in storage. your rich checkout porceleans can 
cache these into a lookup table and gain performance basicly equivalent to 
defining a custom object.

in fact, I'd be willing to bet that even when extended attributes are in 
use (say SELinux tags) the number of different tree objects that would be 
used would still be pretty small.

> On Sun, Aug 10, 2008 at 03:34:37PM -0700, Junio C Hamano wrote:
>> For merging such "metainfo", you would need to do your "flattish/unrich"
>> checkout anyway,
>
> Why not just put entries into the index for each stage as merging
> currently does?  You could then compare the metadata in the index with
> the filesystem metadata in the "rich" checkout, and resolve the conflict
> by adding the desired metadata to the index as stage 0 as usual.  You
> would just need some sort of interface like "git add --metadata file" to
> add the metadata for file to the index.  Alternatively, you could have
> some simple wrappers to directly edit the metadata in the index, much
> like the existing "git update-index --chmod" does for the execute bit.

becouse the tools to work directly on the index are very limited. yes they 
can be left in the index, but then the index-manipulation tools need to 
understand every type of metadata. if it's able to be presented in the 
"flattish/unrich" mode it will work anywhere, even on operating systems 
that can't run your 'rich' tools

David Lang