Re: [PATCH/RFC v5 7/7] Careful with CRLF when using e.g. UTF-16 for working-tree-encoding

From: Junio C Hamano <gitster@pobox.com>
Date: Feb 2, 2018, 19:17 UTC
Message-ID: <xmqqtvuzcibz.fsf@gitster-ct.c.googlers.com>
In-Reply-To: <20180131172837.GA32723@tor.lan>

Torsten Bögershausen <tboegi@web.de> writes:

Show 7 quoted lines

> There are 2 opposite opionions/user expectations here:
>
> a) They are binary in the working tree, so git should leave the line endings
>    as is. (Unless specified otherwise in the .attributes file)
> ...
> b) They are text files in the index. Git will convert line endings
>    if core.autocrlf is true (or the .gitattributes file specifies "-text")

I sense that you seem to be focusing on the distinction between "in the working tree" vs "in the index" while contrasting. The "binary vs text" in your "binary in wt, text in index" is based on the default heuristics without any input from end-users or the project that uses Git that happens to contain such files. If the users and the project that uses Git want to treat contents in a path as text, it is text even when it is (re-)encoded to UTF-16, no?

Such files may be (mis)classified as binary with the default heuristics when there is no help from what is written in the .gitattributes file, but here we are talking about the case where the user explicitly tells us it is in UTF-16, right? Is there such a thing as UTF-16 binary?