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

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

From
Junio C Hamano <gitster@pobox.com>
Date
Sep 19, 2025, 23:16 UTC
Message-ID
<xmqqms6qyqw9.fsf@gitster.g>
In-Reply-To
<20250919010911.649831-6-sandals@crustytoothpaste.net>
"brian m. carlson" <sandals@crustytoothpaste.net> writes:
Show 35 quoted lines
> 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
> work.
>
> Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
> ---
>  Documentation/gitformat-loose.adoc | 49 ++++++++++++++++++++++++++++++
>  1 file changed, 49 insertions(+)
>  create mode 100644 Documentation/gitformat-loose.adoc
>
> 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
> @@ -0,0 +1,49 @@
> +gitformat-loose(5)
> +==================
> +
> +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
> +
> +DESCRIPTION
> +-----------
> +
> +Loose objects are how Git initially stores most of its primary repository data.

"most of" is a bit misleading, I would think. Those who start (what eventuall becomes) a large project from scratch are only minority of the users, and all others start with "git clone" from elsewhere, and in the resulting repository, Git initially stores most of its data in a packfile (or two).

I think it may become a bit clearer if we drop "initially", and end the sentence with "data that are created locally", perhaps?

> +Over the lifetime of a repository, objects are usually written as loose objects
> +initially and then converted into packs.
This one is good.
Show 9 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 glossary calls this "object name", not "ID".
> +the SHA-1 or SHA-256 (as appropriate) hash of the uncompressed data.

We should clarify "data" in uncompressed "data", as we earlier said "prefix and data concatenated", it can be misread as the payload alone. You have "The entire contents" that stands for "prefix and data concatenated" above, so "has of the entire contents" may work.

Also "uncompressed <whatever you rewrite 'data' with>" at the end of this sentence should be followed by "in hexadecimal". The "first two hex characters are used for fan-out" etc., depends on that you do not use binary result of the hash as the object name.

Thanks.
Previous: brian m. carlsonNext: Patrick Steinhardt
Message 27 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.