On Sun, Oct 23, 2011 at 4:51 PM, Junio C Hamano <gitster@xxxxxxxxx> 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. > 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 -- 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