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

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

From
Patrick Steinhardt <ps@pks.im>
Date
Sep 24, 2025, 07:55 UTC
Message-ID
<aNOkBuigxCODIcVN@pks.im>
In-Reply-To
<20250919010911.649831-6-sandals@crustytoothpaste.net>
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/
Show 5 quoted lines
> diff --git a/Documentation/gitformat-loose.adoc b/Documentation/gitformat-loose.adoc
> new file mode 100644
> index 0000000000..c8bef606fb
> --- /dev/null
> +++ b/Documentation/gitformat-loose.adoc

Do we maybe want to call this "gitformat-loose-objects(5)"? "loose" feels rather generic.

> @@ -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.

Show 11 quoted lines
> +NAME
> +----
> +gitformat-loose - Git loose object format
> +
> +
> +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?

On the other hand, maybe it's better to list those files and not explain them compared to not mentioning them at all. Not quite sure.

Show 6 quoted lines
> +DESCRIPTION
> +-----------
> +
> +Loose objects are how Git initially stores most of its primary repository data.
> +Over the lifetime of a repository, objects are usually written as loose objects
> +initially and then converted into packs.

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.
Show 14 quoted lines
> +== Loose objects
> +
> +Each loose object contains a prefix, followed immediately by the data of the
> +object.  The prefix contains `<type> <size>\0`.  `<type>` is one of `blob`,
> +`tree`, `commit`, or `tag` and `size` is the size of the data (without the
> +prefix) as a decimal integer expressed in ASCII.
> +
> +The entire contents, prefix and data concatenated, is then compressed with zlib
> +and the compressed data is stored in the file.  The object ID of the object is
> +the SHA-1 or SHA-256 (as appropriate) hash of the uncompressed data.
> +
> +The file for the loose object is stored under the `objects` directory, with the
> +first two hex characters of the object ID being the directory and the remaining
> +characters being the file name.
Should we maybe give a hint why we have these sharding directories?
Patrick
Previous: Junio C HamanoNext: brian m. carlson
Message 28 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.