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

[PATCH 2/6] object-file: drop confusing oid initializer of empty_tree struct

From
Jeff King <peff@peff.net>
Date
Nov 18, 2024, 09:55 UTC
Message-ID
<20241118095507.GB3992317@coredump.intra.peff.net>
In-Reply-To
<20241118095423.GA3990835@coredump.intra.peff.net>

We treat the empty tree specially, providing an in-memory "cached" copy, which allows you to diff against it even if the object doesn't exist in the repository. This is implemented as part of the larger cached_object subsystem, but we use a stand-alone empty_tree struct.

We initialize the oid of that struct using EMPTY_TREE_SHA1_BIN_LITERAL. At first glance, that seems like a bug; how could this ever work for sha256 repositories?

The answer is that we never look at the oid field! The oid field is used to look up entries added by pretend_object_file() to the cached_objects array. But for our stand-alone entry, we look for it independently using the_hash_algo->empty_tree, which will point to the correct algo struct for the repository.

This happened in 62ba93eaa9 (sha1_file: convert cached object code to struct object_id, 2018-05-02), which even mentions that this field is never used. Let's reduce confusion for anybody reading this code by replacing the sha1 initializer with a comment. The resulting field will be all-zeroes, so any violation of our assumption that the oid field is not used will break equally for sha1 and sha256.

Signed-off-by: Jeff King <peff@peff.net>
---
 object-file.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/object-file.c b/object-file.c
index 8101585616..19fc4afa43 100644
--- a/object-file.c
+++ b/object-file.c
@@ -326,9 +326,7 @@ static struct cached_object {
 static int cached_object_nr, cached_object_alloc;
 
 static struct cached_object empty_tree = {
-	.oid = {
-		.hash = EMPTY_TREE_SHA1_BIN_LITERAL,
-	},
+	/* no oid needed; we'll look it up manually based on the_hash_algo */
 	.type = OBJ_TREE,
 	.buf = "",
 };
-- 
2.47.0.547.g778689293a
Previous: Jeff KingNext: Jeff King
Message 19 of 25 in “-Wunterminated-string-initialization warning with GCC 15 in object-file.c”
  1. Sam JamesNov 17, 2024
  2. Jeff KingNov 17, 2024
  3. 1/5 object-file: prefer array-of-bytes initializer for hash literalsJeff King, Nov 17, 2024
  4. René ScharfeNov 17, 2024
  5. Jeff KingNov 18, 2024
  6. 2/5 object-file: drop confusing oid initializer of empty_tree structJeff King, Nov 17, 2024
  7. 3/5 object-file: move empty_tree struct into find_cached_object()Jeff King, Nov 17, 2024
  8. Patrick SteinhardtNov 18, 2024
  9. Jeff KingNov 18, 2024
  10. 4/5 object-file: drop oid field from find_cached_object() return valueJeff King, Nov 17, 2024
  11. 5/5 object-file: inline empty tree and blob literalsJeff King, Nov 17, 2024
  12. Patrick SteinhardtNov 18, 2024
  13. brian m. carlsonNov 17, 2024
  14. Jeff KingNov 18, 2024
  15. Sam JamesNov 18, 2024
  16. Patrick SteinhardtNov 18, 2024
  17. 0/6 -Wunterminated-string-initialization warning + cleanupsJeff King, Nov 18, 2024
  18. 1/6 object-file: prefer array-of-bytes initializer for hash literalsJeff King, Nov 18, 2024
  19. 2/6 object-file: drop confusing oid initializer of empty_tree structJeff King, Nov 18, 2024
  20. 3/6 object-file: move empty_tree struct into find_cached_object()Jeff King, Nov 18, 2024
  21. 4/6 object-file: drop oid field from find_cached_object() return valueJeff King, Nov 18, 2024
  22. 5/6 object-file: treat cached_object values as constJeff King, Nov 18, 2024
  23. 6/6 object-file: inline empty tree and blob literalsJeff King, Nov 18, 2024
  24. Patrick SteinhardtNov 18, 2024
  25. Junio C HamanoNov 18, 2024

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.