On 03/08/2015 02:33 PM, Junio C Hamano wrote:
karthik nayak <karthik....@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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
