git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Ddavid@lang.hm <david@lang.hm>
Date
Aug 16, 2008, 07:56 UTC
Message-ID
<alpine.DEB.1.10.0808160046250.12859@asgard.lang.hm>
In-Reply-To
<20080816062130.GA4554@oh.minilop.net>
On Fri, 15 Aug 2008, Josh Triplett wrote:
Show 9 quoted lines
>
> - 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.

Show 12 quoted lines
> 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
Previous: Josh TriplettNext: Junio C Hamano
Message 14 of 22 in “[RFC] Plumbing-only support for storing object metadata”
  1. Jamey SharpAug 9, 2008
  2. Scott ChaconAug 9, 2008
  3. Shawn O. PearceAug 10, 2008
  4. Stephen R. van den BergAug 10, 2008
  5. david@lang.hmAug 10, 2008
  6. Jan HudecAug 10, 2008
  7. Stephen R. van den BergAug 10, 2008
  8. Jan HudecAug 10, 2008
  9. Stephen R. van den BergAug 10, 2008
  10. Junio C HamanoAug 10, 2008
  11. david@lang.hmAug 10, 2008
  12. Stephen R. van den BergAug 11, 2008
  13. Josh TriplettAug 16, 2008
  14. david@lang.hmAug 16, 2008
  15. Junio C HamanoAug 16, 2008
  16. Jan HudecAug 16, 2008
  17. Shawn O. PearceAug 18, 2008
  18. Derek FawcusAug 18, 2008
  19. Shawn O. PearceAug 18, 2008
  20. Marcus GriepAug 18, 2008
  21. Shawn O. PearceAug 18, 2008
  22. Jan HudecAug 10, 2008

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.