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

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

From
JHJan Hudec <bulb@ucw.cz>
Date
Aug 10, 2008, 18:11 UTC
Message-ID
<20080810181115.GA3906@efreet.light.src>
In-Reply-To
<20080810175735.GA14237@cuci.nl>
On Sun, Aug 10, 2008 at 19:57:35 +0200, Stephen R. van den Berg wrote:
Show 11 quoted lines
> Jan Hudec wrote:
> >On Sun, Aug 10, 2008 at 05:16:47 -0700, david@lang.hm wrote:
> >> On Sun, 10 Aug 2008, Stephen R. van den Berg wrote:
> >>> However, pondering the idea a bit more, I could envision something
> >>> similar to the following:
> 
> >.... provided the two entries under the same name wouldn't drive the internal
> >logic completely mad, I quite like this. Note by the way, that you need to
> >allow for two trees too, because you may want to store attributes for
> 
> Well, in theory yes, but currently git doesn't store directories.

It depends. It does store directories in the tree objects, it just does not do that in index. And we are talking about tree objects, where git does store directories.

Besides, that is irrelevant to storing attributes for directories -- the attribute objects are not themselves directories, so git would store them just fine.

Show 6 quoted lines
> How about extending git-core to allow for storage of directories by
> virtue of the following object in a tree:
> 
> 040000 blob e69de29bb2d1d6434b8b29ae775ad8c2e48c5391  .
> 
> I.e. the hash belongs to the empty blob.

Sorry, but this is insane. If git was to store anything for empty directories, it would be empty tree, not a tree containing empty blob called '.'. There was even a prototype patch to do that sent to the list (I believe it was from Linus and was part of an argument along the lines "you could do it like this, so stop talking and finish it if you have good enough reason to want it (which you obviously don't)").

> Normally you don't (have to) store these directory blobs, but if you
> insist on having them, git will create the empty directory on checkout
> (i.e. you wouldn't need the dummy file trick anymore to force the
> directory to be present).

No, I don't give a damn about directories themselves. I want to store their attributes, which is completely different thing.

-- 
						 Jan 'Bulb' Hudec <bulb@ucw.cz>
Previous: Stephen R. van den BergNext: Stephen R. van den Berg
Message 8 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.