Re: [PATCH v3 04/12] cache.h: add comment explaining the order in object_type
From: Duy Nguyen <hidden>
Date: 2018-05-08 15:35:45
On Tue, May 1, 2018 at 8:40 PM, Ævar Arnfjörð Bjarmason [off-list ref] wrote:
quoted hunk ↗ jump to hunk
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@gmail.com. Makes sense to me, add that as a comment. Helped-by: Derrick Stolee [off-list ref] 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) + */
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