Re: [PATCH v3 04/12] cache.h: add comment explaining the order in object_type

Ævar Arnfjörð Bjarmason  [off-list ref] writes:

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.

Derrick Stolee suggested that it's ordered topologically in
that as a comment.
5f8b1ec1-258d-1acc-133e-a7c248b4083e@gmail.com. Makes sense to me, add

When referring to a message-id, please do not omit surrounding <>,
which is part of the message-id string.  That's like writing your
e-mail address as avarab gmail.com without at sign.

 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)
+	 */

I am not sure if the above makes sense at all in explaining tag.
With all others, type with smaller type id can refer to another type
that is with equal or larger type id (tree can refer to another
tree).  If tag had the smallest ID among all, it would have made
sense, though.

Before anybody confused raises noise, a gitlink records a commit in
a tree, which may seem to contradict the rule even more, but it
merely records a commit, without "referring" to it in the same sense
as other reference that require connectivity.

 	OBJ_COMMIT = 1,
 	OBJ_TREE = 2,
 	OBJ_BLOB = 3,