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@gmail.com. Makes sense to me, add
that as a comment.

Signed-off-by: Ævar Arnfjörð Bjarmason <redacted>
---
 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