RE: git-rebase is ignoring working-tree-encoding

From: Alexandre Grigoriev <alegrigoriev@gmail.com>
Date: Dec 23, 2018, 14:46 UTC
Message-ID: <009e01d49ace$4876c230$d9644690$@gmail.com>
In-Reply-To: <20181104170729.GA21372@tor.lan>

Show 10 quoted lines

>On Fri, Nov 02, 2018 at 03:30:17AM +0100, Adrián Gimeno Balaguer wrote:
>> I’m attempting to perform fixups via git-rebase of UTF-16 LE files
>> (the project I’m working on requires that exact encoding on certain
>> files). When the rebase is complete, Git changes that file’s encoding
>> to UTF-16 BE. I have been using the newer working-tree-encoding
>> attribute in .gitattributes. I’m using Git for Windows.
>> 
>> $ git version
>> git version 2.19.1.windows.1
>>

Show 10 quoted lines

>Thanks for the report.
>I have tried to follow the problem from your verbal descriptions
>(and the PR) but I need to admit that I don't fully understand the
>problem (yet).
>Could you try to create some instructions how to reproduce it?
>A numer of shell istructions would be great,
>in best case some kind of "test case", like the tests in
>the t/ directory in Git.
>It would be nice to be able to re-produce it.
>And if there is a bug, to get it fixed.

This is not as much Git issue (and not rebase issue at all), as libiconv issue.

Iconv program exhibits the same behavior. If you ask it to convert to UTF-16, It will produce UTF-16BE with BOM.

That said, it appears that Centos (tested on 7.4) devs have seen the wrong in it and patched libiconv to produce UTF-16LE with BOM. Git on Centos does check out files as UTF-16LE, and iconv produces these files, as well. Just need to find out what patch they applied to libiconv.