Jeff King <p...@peff.net> writes: > If there _is_ a performance implication to worry about here, I think it > would be that we are doing an extra malloc/free.
Thanks for reminding me; yes, that also worried me. > I'm not sure I > understand why we are copying it at all. The original code copied from > the hdr into type[10] so that we could NUL-terminate it, which was > required for type_from_string(). Sounds like a good plan. > > But now we use type_from_string_gently, which can accept a length[1]. So > we could just count the bytes to the first space and pass the original > buffer along with that length, no? > > -Peff > > [1] Not related to your patch, but it looks like type_from_string_gently > is overly lax. It does a strncmp() with the length of the candidate > name, but does not check that we consumed all of the matching name. > So "tr" would match "tree", "comm" would match "commit", and so > forth. -- 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
