Re: [PATCH v3 2/3] sha1_file: implement changes for "cat-file --literally -t"

From: karthik nayak <karthik.188@gmail.com>
Date: Mar 8, 2015, 10:49 UTC
Message-ID: <54FC292C.5060405@gmail.com>
In-Reply-To: <xmqqegozsvx5.fsf@gitster.dls.corp.google.com>

On 03/08/2015 02:33 PM, Junio C Hamano wrote:

Show 18 quoted lines

> karthik nayak <karthik.188@gmail.com> 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.