Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> 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@xxxxxxxxx. 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,
