Re: [PATCH] index-pack: fix allocation of sorted_by_pos array

From: Junio C Hamano <gitster@pobox.com>
Date: Jul 7, 2015, 15:49 UTC
Message-ID: <xmqqvbdw3r40.fsf@gitster.dls.corp.google.com>
In-Reply-To: <CACsJy8CsUu1zEnah9Ah3tQxk8N-xPpOBuV5TpQ4EB6+nyiDW3g@mail.gmail.com>

Duy Nguyen <pclouds@gmail.com> writes:

> I keep tripping over this "real_type vs type" in this code. What do
> you think about renaming "type" field to "in_pack_type" and
> "real_type" to "canon_type" (or "final_type")? "Real" does not really
> say anything in this context..

An unqualified name "type" does bother me for the word to express what representation the piece of data uses (i.e. is it a delta, or is it a base object of "tree" type, or what). I think I tried to unconfuse myself by saying "representation type" in in-code comments, reviews and log messages when it is not clear which kind between "in-pack representation" or "Git object type of that stored data" a sentence is talking about, and I agree "in_pack_type" would be a vast improvement over just "type".

To me personally real- and final- mean about the same thing (i.e. what is the real type of the object that is stored?) in the context of this codepath.

Especially, if the other one is renamed with "in_pack_" prefix, "real_type" is not just clear enough but is probably better because it explains what it is from its "meaning" (i.e. it is the type of the Git object, not how it is represented in the pack-stream) than "final_type" that is named after "how" it is computed (i.e. it makes sense to you only if you know that an in-pack type "this is delta" does not have the full information and you have to traverse the delta chain and you will finally find out what it is when you hit the base representation).

Thanks.