I do not think we want to go this route. There are two possible approaches to attack this. - If we want to show everything after a potential and rare NUL in the log message most of the time, then "struct commit" should just store <ptr,len> pair. This grows "struct commit" with one extra ulong. - If we want to give us a way to notice and show these "funnily, this commit log message has a NUL in it" case as an exception in only selected codepaths, then "struct commit" should just gain "flags" 4-byte int field between "indegree" and "date", and parse_commit_buffer() should set one bit in the flags when the log message has NUL in it. And teach only these selected codepaths to find the length from the object name with sha1_object_info() as needed. This grows "struct commit" with one 4-byte int, with runtime overhead only where it matters. The approach taken by the patch wastes two malloc() blocks with their own allocation overhead, and unused "alloc" field in the strbuf that does not have to be there. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html