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

Re: [PATCH 5/9] docs: add documentation for loose objects

From
brian m. carlson <sandals@crustytoothpaste.net>
Date
Sep 30, 2025, 16:39 UTC
Message-ID
<aNwH3wqMzbNMpnEB@fruit.crustytoothpaste.net>
In-Reply-To
<aNOkBuigxCODIcVN@pks.im>
On 2025-09-24 at 07:55:50, Patrick Steinhardt wrote:
Show 5 quoted lines
> On Fri, Sep 19, 2025 at 01:09:07AM +0000, brian m. carlson wrote:
> > We currently have no documentation for how loose objects are stored.
> > Let's add some here so its easy for people to understand how they
> 
> Nit: s/its/it is/
Will be fixed in v2.
> Do we maybe want to call this "gitformat-loose-objects(5)"? "loose"
> feels rather generic.
We have "index" and "pack", so I'd rather keep it short.
Show 7 quoted lines
> > @@ -0,0 +1,49 @@
> > +gitformat-loose(5)
> > +==================
> 
> Makes me wonder whether we should also have gitformat-reffiles(5) and
> gitformat-reftables(5). Obviously nothing you have to do, but rather an
> action item for myself or others interested in the ref backends.
Yeah, I definitely think that would be useful.
Show 10 quoted lines
> > +SYNOPSIS
> > +--------
> > +[verse]
> > +$GIT_DIR/objects/[0-9a-f][0-9a-f]/*
> > +$GIT_DIR/objects/loose-object-idx
> > +$GIT_DIR/objects/loose-map/map-*.map
> 
> It's a bit weird to list the mapping files here without explaining them.
> Should we maybe drop them for now and only add them once we also add a
> section explaining their format?
I've bumped those two lines to a future commit (probably part 2).
Show 11 quoted lines
> I feel that "most of its primary repository data" is a bit misleading,
> as one can expect that most of the data should be in packfiles instead.
> How about the following instead:
> 
>     Loose objects are how Git stores individual objects, where every
>     object is written as a separate file.
> 
>     Over the lifetime of a repository, new objects are typically written
>     as loose objects initially. Eventually, these loose objects will be
>     compacted into packfiles via repository maintenance to improve disk
>     space usage and speed up the lookup of those objects.
I adopted most of this language.
> Should we maybe give a hint why we have these sharding directories?
Done in v2.
-- 
brian m. carlson (they/them)
Toronto, Ontario, CA
Previous: Patrick SteinhardtNext: brian m. carlson
Message 29 of 67 in “SHA-1/SHA-256 interoperability, part 1”
  1. 0/9 SHA-1/SHA-256 interoperability, part 1brian m. carlson, Sep 19, 2025
  2. 3/9 docs: reflect actual double signature for tagsbrian m. carlson, Sep 19, 2025
  3. Junio C HamanoSep 19, 2025
  4. brian m. carlsonSep 20, 2025
  5. Junio C HamanoSep 20, 2025
  6. Patrick SteinhardtSep 24, 2025
  7. brian m. carlsonSep 25, 2025
  8. 1/9 docs: update pack index v3 formatbrian m. carlson, Sep 19, 2025
  9. Junio C HamanoSep 19, 2025
  10. brian m. carlsonSep 20, 2025
  11. Junio C HamanoSep 20, 2025
  12. Patrick SteinhardtSep 24, 2025
  13. brian m. carlsonSep 25, 2025
  14. 2/9 docs: update offset order for pack index v3brian m. carlson, Sep 19, 2025
  15. 4/9 docs: improve ambiguous areas of pack format documentationbrian m. carlson, Sep 19, 2025
  16. Junio C HamanoSep 19, 2025
  17. 8/9 Allow specifying compatibility hashbrian m. carlson, Sep 19, 2025
  18. Patrick SteinhardtSep 24, 2025
  19. brian m. carlsonSep 30, 2025
  20. 5/9 docs: add documentation for loose objectsbrian m. carlson, Sep 19, 2025
  21. Junio C HamanoSep 19, 2025
  22. Junio C HamanoSep 19, 2025
  23. brian m. carlsonSep 19, 2025
  24. Junio C HamanoSep 19, 2025
  25. Patrick SteinhardtSep 24, 2025
  26. brian m. carlsonSep 25, 2025
  27. Junio C HamanoSep 19, 2025
  28. Patrick SteinhardtSep 24, 2025
  29. brian m. carlsonSep 30, 2025
  30. 6/9 rev-parse: allow printing compatibility hashbrian m. carlson, Sep 19, 2025
  31. Junio C HamanoSep 19, 2025
  32. Patrick SteinhardtSep 24, 2025
  33. brian m. carlsonSep 25, 2025
  34. 7/9 fsck: consider gpgsig headers expected in tagsbrian m. carlson, Sep 19, 2025
  35. Junio C HamanoSep 19, 2025
  36. brian m. carlsonSep 22, 2025
  37. 9/9 t: add a prerequisite for a compatibility hashbrian m. carlson, Sep 19, 2025
  38. Patrick SteinhardtSep 24, 2025
  39. 0/9 SHA-1/SHA-256 interoperability, part 1brian m. carlson, Oct 2, 2025
  40. 1/9 docs: update pack index v3 formatbrian m. carlson, Oct 2, 2025
  41. Junio C HamanoOct 3, 2025
  42. 3/9 docs: reflect actual double signature for tagsbrian m. carlson, Oct 2, 2025
  43. 2/9 docs: update offset order for pack index v3brian m. carlson, Oct 2, 2025
  44. 4/9 docs: improve ambiguous areas of pack format documentationbrian m. carlson, Oct 2, 2025
  45. Junio C HamanoOct 3, 2025
  46. brian m. carlsonOct 3, 2025
  47. 5/9 docs: add documentation for loose objectsbrian m. carlson, Oct 2, 2025
  48. Junio C HamanoOct 3, 2025
  49. 7/9 fsck: consider gpgsig headers expected in tagsbrian m. carlson, Oct 2, 2025
  50. 6/9 rev-parse: allow printing compatibility hashbrian m. carlson, Oct 2, 2025
  51. 8/9 t: allow specifying compatibility hashbrian m. carlson, Oct 2, 2025
  52. Junio C HamanoOct 3, 2025
  53. brian m. carlsonOct 3, 2025
  54. 9/9 t1010: use BROKEN_OBJECTS prerequisitebrian m. carlson, Oct 2, 2025
  55. 0/9 SHA-1/SHA-256 interoperability, part 1brian m. carlson, Oct 9, 2025
  56. 3/9 docs: reflect actual double signature for tagsbrian m. carlson, Oct 9, 2025
  57. 4/9 docs: improve ambiguous areas of pack format documentationbrian m. carlson, Oct 9, 2025
  58. 2/9 docs: update offset order for pack index v3brian m. carlson, Oct 9, 2025
  59. 1/9 docs: update pack index v3 formatbrian m. carlson, Oct 9, 2025
  60. 5/9 docs: add documentation for loose objectsbrian m. carlson, Oct 9, 2025
  61. 6/9 rev-parse: allow printing compatibility hashbrian m. carlson, Oct 9, 2025
  62. 8/9 t: allow specifying compatibility hashbrian m. carlson, Oct 9, 2025
  63. 7/9 fsck: consider gpgsig headers expected in tagsbrian m. carlson, Oct 9, 2025
  64. 9/9 t1010: use BROKEN_OBJECTS prerequisitebrian m. carlson, Oct 9, 2025
  65. Junio C HamanoOct 13, 2025
  66. brian m. carlsonOct 13, 2025
  67. Patrick SteinhardtOct 14, 2025

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.