> On 31 Jan 2018, at 18:28, Torsten Bögershausen <tboegi@xxxxxx> wrote: > > [] >>> That is a good one. >>> If you ever plan a re-roll (I don't at the moment) the *.proj extemsion >>> make much more sense in Documentation/gitattributes that *.tx >>> There no text files encoded in UTF-16 wich are called xxx.txt, but those >>> are non-ideal examples. *.proj makes good sense as an example. >> >> OK, I'll do that. Would that fix the problem which this patch tries to address for you? >> (I would also explicitly add a paragraph to discuss line endings) > > Please let me see the patch first, before I can have a comment. Sure! I'll have it ready tomorrow. > But back to the more general question: > > How should Git handle the line endings of UTF-16 files in the woring-tree, > which are UTF-8 in the index? > > > 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) Well, if you consider your UTF-16 files binary then you would not change *anything*. You would not enable the new "working-tree-encoding" attribute. As a consequence, Git's behavior would not change. Git would leave all line endings as they are for the UTF-16 files. > b) They are text files in the index. Git will convert line endings > if core.autocrlf is true (or the .gitattributes file specifies "-text") This would *only* happen if you enable the new "working-tree-encoding" attribute. In this case a user has already made the conscious decision to treat these files as text files. Therefore, the user expects Git to handle them in the same way other text files are handled. > My feeling is that both arguments are valid, so let's ask for opinions > and thoughts of others. > Erik, Junio, Johannes, Johannes, Jeff, Ramsay, everybody: > What do yo think ? - Lars
