The order in the enum might seem arbitrary, and isn't explained by
72518e9c26 ("more lightweight revalidation while reusing deflated
stream in packing", 2006-09-03) which added it, but Derrick Stolee
suggested that it's ordered topologically in
5f8b1ec1-258d-1acc-133e-a7c248b40...@gmail.com. Makes sense to me, add
that as a comment.

Signed-off-by: Ævar Arnfjörð Bjarmason <ava...@gmail.com>
---
 cache.h | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/cache.h b/cache.h
index 77b7acebb6..354903c3ea 100644
--- a/cache.h
+++ b/cache.h
@@ -376,6 +376,14 @@ extern void free_name_hash(struct index_state *istate);
 enum object_type {
        OBJ_BAD = -1,
        OBJ_NONE = 0,
+       /*
+        * Why have our our "real" object types in this order? They're
+        * ordered topologically:
+        *
+        * tag(4)    -> commit(1), tree(2), blob(3)
+        * commit(1) -> tree(2)
+        * tree(2)   -> blob(3)
+        */
        OBJ_COMMIT = 1,
        OBJ_TREE = 2,
        OBJ_BLOB = 3,
-- 
2.17.0.290.gded63e768a

Reply via email to