On Tue, May 1, 2018 at 8:40 PM, Ævar Arnfjörð Bjarmason
<avarab@xxxxxxxxx> wrote:
> 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
> 5f8b1ec1-258d-1acc-133e-a7c248b4083e@xxxxxxxxx. Makes sense to me, add
> that as a comment.
>
> Helped-by: Derrick Stolee <dstolee@xxxxxxxxxxxxx>
> 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)
> + */
I think it's more important that these constants are part of the pack
file format. Even if it follows some order now, when a new object type
comes, you cannot just reorder to keep things look nice because then
you break pack file access.
I'm afraid this comment suggests that these numbers are just about
order, which is very wrong.
> OBJ_COMMIT = 1,
> OBJ_TREE = 2,
> OBJ_BLOB = 3,
--
Duy
