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@xxxxxxxx>
---
object-file.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/object-file.c b/object-file.c
index 25ba54594b..b7c4fdcabd 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.541.ge258d9a1f8
