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-a7c248b4083e@xxxxxxxxx. Makes sense to me, add
that as a comment.
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx>
---
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
