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

From: Nguyen Thai Ngoc Duy <pclouds@gmail.com>
Date: Oct 24, 2011, 05:10 UTC
Message-ID: <CACsJy8AsfQnS3L1fabzB-z7BdH=jvB=XNnmP2RZu0qp7C1uGYQ@mail.gmail.com>
In-Reply-To: <7vy5wb3sto.fsf@alter.siamese.dyndns.org>

On Mon, Oct 24, 2011 at 3:40 PM, Junio C Hamano <gitster@pobox.com> wrote:

Show 18 quoted lines

> Junio C Hamano <gitster@pobox.com> writes:
>
>> Jeff King <peff@peff.net> writes:
>>
>>> But as Duy mentions, we have an encoding header. Shouldn't we treat it
>>> like binary goo until we do reencode_log_message, and _then_ we can
>>> break it into lines?
>>
>> That's sensible. If we go that route, I think the "one allocation of
>> separate struct commit_buffer pointed from a pointer field in struct
>> commit to replace the current member 'buffer'" is a reasonable thing
>> to do.
>
> Having given that "sensible" comment, I am not convinced if this is worth
> it. We are talking about what is left in the ephemeral COMMIT_EDITMSG by
> the chosen editor, but are there really editors that can _only_ write in
> UTF-16 and not in UTF-8, and is it worth bending backwards to add support
> such an editor?

This is argument for the sake of argument because I don't use utf-16 and do not care much. UTF-16 can have more code points and some may prefer utf-16 to utf-8.

I'd be happy with git's refusing to create broken commits because people accidentally set editor encoding to utf-16. If people do use utf-16, they'll get caught and should yell up if they want utf-16 supported.

-- 
Duy