Re: [PATCH v11 06/10] convert: add 'working-tree-encoding' attribute

From: Lars Schneider <larsxschneider@gmail.com>
Date: Apr 15, 2018, 16:54 UTC
Message-ID: <8EBD3571-D5FA-471B-BD5F-D8401043D503@gmail.com>
In-Reply-To: <583f9ec3-3aef-d823-9fd6-3cc126ac47f6@web.de>

Show 19 quoted lines

> On 05 Apr 2018, at 18:41, Torsten Bögershausen <tboegi@web.de> wrote:
> 
> On 01.04.18 15:24, Lars Schneider wrote:
>>> TRUE or false are values, but just wrong ones.
>>> If this test is removed, the user will see "failed to encode "TRUE" to "UTF-8",
>>> which should give enough information to fix it.
>> 
>> I see your point. However, I would like to stop the processing right
>> there for these invalid values. How about 
>> 
>>  error(_("true/false are no valid working-tree-encodings"));
>> 
>> I think that is the most straight forward/helpful error message
>> for the enduser (I consider the term "boolean" but dismissed it
>> as potentially confusing to folks not familiar with the term).
>> 
>> OK with you?
> 
> Yes.

Great!

Show 14 quoted lines

> Another thing that came up recently, independent of your series:
> 
> What should happen if a user specifies "UTF-8" and the file
> has an UTF-8 encoded BOM ?
> I ask because I stumbled over such a file coming from a Windows
> which the java compiler under Linux didn't accept.
> 
> And because some tools love to put an UTF-8 encoded BOM
> into text files.
> 
> The clearest thing would be to extend the BOM check in 5/9
> to cover UTF-32, UTF-16 and UTF-8.
> 
> Are there any plans to do so?

If `working-tree-encoding` is not defined or defined as UTF-8, then we would return from encode_to_git() early. That means we would never run validate_encoding() which would check the BOM.

However, adding the UTF-8 BOM would still make sense. This way Git could scream if a user set `working-tree-encoding` to UTF-16 but the file is really UTF-8 encoded.

> And thanks for the work.

Thanks :-)

- Lars