Thread (2 messages) flat view 2 messages, 2 authors, 2016-06-15

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

From: Junio C Hamano <hidden>
Date: 2016-06-15 22:52:19

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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help