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

From: Nguyen Thai Ngoc Duy <pclouds@gmail.com>
Date: Oct 23, 2011, 06:37 UTC
Message-ID: <CACsJy8CA2cqJqt7cUN1CdnOb3=qE6B2XTd1oQKZ7osVz09kSGg@mail.gmail.com>
In-Reply-To: <7vipng5k80.fsf@alter.siamese.dyndns.org>

On Sun, Oct 23, 2011 at 4:51 PM, Junio C Hamano <gitster@pobox.com> wrote:

> So in that sense, I do not think it is unreasonable to chop it off at the
> first NUL, which is the current behaviour. IOW, it is entirely sane to
> argue that there is nothing to fix.

Good for me too if we go this way. I was just curious what if we changed commit_buffer field and got hooked in.

Show 9 quoted lines

> But as Jeff suggested, we should step back a bit and think what our goal
> is.
>
> The low level object format of our commit is textual header fields, each
> of which is terminated with a LF, followed by a LF to mark the end of
> header fields, and then opaque payload that can contain any bytes. It does
> not forbid a non-Git application to reuse the object store infrastructure
> to store ASN.1 binary goo there, and the low level interface we give such
> as cat-file is a perfectly valid way to inspect such a "commit" object.

cat-file is fine, commit-tree (or any commands that call commit_tree()) cuts at NUL though.

I wonder how git processes commit messages in utf-16. Did a quick test, did not look good. But that's because git-commit cuts at NUL. But even if git-commit makes a good object, I doubt if git-log shows it right.

-- 
Duy