> On 05 Apr 2018, at 18:41, Torsten Bögershausen <tboegi@xxxxxx> 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!
> 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
