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