From: Junio C Hamano <gitster@pobox.com>
To: "Nguyễn Thái Ngọc Duy" <pclouds@gmail.com>
Cc: git@vger.kernel.org, peff@peff.net, "Ævar Arnfjörð" <avarab@gmail.com>
Subject: Re: [PATCH 00/22] Refactor to accept NUL in commit messages
Date: Sat, 22 Oct 2011 15:47:12 -0700 [thread overview]
Message-ID: <7vobx863v3.fsf@alter.siamese.dyndns.org> (raw)
In-Reply-To: <1319277881-4128-1-git-send-email-pclouds@gmail.com> ("Nguyễn Thái Ngọc Duy"'s message of "Sat, 22 Oct 2011 21:04:19 +1100")
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.
next prev parent reply other threads:[~2011-10-22 22:47 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1319277881-4128-1-git-send-email-pclouds@gmail.com>
2011-10-22 19:09 ` [PATCH 00/22] Refactor to accept NUL in commit messages Jeff King
2011-10-23 10:44 ` Robin Rosenberg
2011-10-23 16:09 ` Jeff King
2011-10-22 22:47 ` Junio C Hamano [this message]
2011-10-23 1:24 ` Nguyen Thai Ngoc Duy
2011-10-23 5:51 ` Junio C Hamano
2011-10-23 6:37 ` Nguyen Thai Ngoc Duy
2011-10-23 9:46 ` Junio C Hamano
2011-10-23 10:17 ` Nguyen Thai Ngoc Duy
2011-10-23 16:07 ` Jeff King
2011-10-23 20:16 ` Junio C Hamano
2011-10-24 4:40 ` Junio C Hamano
2011-10-24 5:10 ` Nguyen Thai Ngoc Duy
2011-10-24 11:09 ` Štěpán Němec
2011-10-24 22:45 ` Jeff King
2011-10-25 10:16 ` Štěpán Němec
2011-10-25 14:07 ` Junio C Hamano
2011-10-27 18:13 ` Jeff King
2011-10-27 18:47 ` Junio C Hamano
2011-10-27 18:52 ` Jeff King
2011-10-27 19:14 ` Junio C Hamano
2011-10-27 23:44 ` Jeff King
2011-10-28 0:03 ` Junio C Hamano
2011-10-28 0:19 ` Jeff King
2011-10-28 1:40 ` Miles Bader
2011-10-28 4:07 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7vobx863v3.fsf@alter.siamese.dyndns.org \
--to=gitster@pobox.com \
--cc=avarab@gmail.com \
--cc=git@vger.kernel.org \
--cc=pclouds@gmail.com \
--cc=peff@peff.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).