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

From: brian m. carlson <sandals@crustytoothpaste.net>
Date: Nov 4, 2018, 15:47 UTC
Message-ID: <20181104154744.GI731755@genre.crustytoothpaste.net>
In-Reply-To: <CADN+U_PUfnYWb-wW6drRANv-ZaYBEk3gWHc7oJtxohA5Vc3NEg@mail.gmail.com>

On Fri, Nov 02, 2018 at 03:30:17AM +0100, Adrián Gimeno Balaguer wrote:

Show 13 quoted lines

> 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
> 
> Here is a sample UTF-16 LE file (with BOM and LF endings) with
> following atributes in .gitattributes:
> 
> test.txt eol=lf -text working-tree-encoding=UTF-16

Do things work for you if you write this as "UTF-16LE"? When you use working-tree-encoding, the file is stored internally as UTF-8, but it's serialized to the specified encoding when written out.

Asking for "UTF-16" is ambiguous: there are two endiannesses, and so as long as you get a BOM in the output, either one is an acceptable option. Which one you get is dependent on what the underlying code thinks is the default, and traditionally for Unix systems and Unix tools that's been big-endian. If you want a particular endianness, you should specify it.

-- 
brian m. carlson: Houston, Texas, US
OpenPGP: https://keybase.io/bk2204