Re: [PATCH 00/22] Refactor to accept NUL in commit messages

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]