From: karthik nayak Date: Sun, 08 Mar 2015 10:49:16 GMT Subject: Re: [PATCH v3 2/3] sha1_file: implement changes for "cat-file --literally -t" Message-ID: <54FC292C.5060405@gmail.com> In-Reply-To: On 03/08/2015 02:33 PM, Junio C Hamano wrote: > karthik nayak writes: > > > What parse_sha1_header() does to get the type is just find the first > > occurrence of a " " manually and store everything before it as the > > type. Then it finds the size of the object if needed. And finally > > returns the type by calling type_from_string(). This is where we get > > the undefined type error. > > Yes, exactly. The change illustrated in $gmane/264420 may be > incomplete and some calls from the sha1_object_info_extended() after > that change may still need to further be tweaked to pay attention to > LOOKUP_LITERALLY bit; for example, parse_sha1_header() may want to > learn not to barf when seeing an unexpected typename in the header > when the caller asks to look up "literally". > > I thought I already said that; sorry if I forgot. > > Sorry for the confusion, you did already say that in $gmane/264955 , I'm talking about how I tackled the issue in $gmane/264855. Like : else if ((flags & LOOKUP_LITERALLY)) { size_t typelen = strcspn(hdrbuf.buf, " "); strbuf_add(oi->typename, hdrbuf.buf, typelen); } else if ((status = parse_sha1_header(hdrp, &size)) < 0) status = error("unable to parse %s header", sha1_to_hex(sha1)); else if (oi->sizep) *oi->sizep = size; This way, we don't have to modify parse_sha1_header() to worry if "literally" is set or not.