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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
