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

From: brian m. carlson <sandals@crustytoothpaste.net>
Date: Nov 4, 2018, 18:38 UTC
Message-ID: <20181104183813.GJ731755@genre.crustytoothpaste.net>
In-Reply-To: <CADN+U_Nw5wCyK1SPRgsxzFbJ-KKnOV2Ub8YA3_a80SZYwKC5FQ@mail.gmail.com>

On Sun, Nov 04, 2018 at 05:37:09PM +0100, Adrián Gimeno Balaguer wrote:

Show 12 quoted lines

> I wrote a "counterpart" easy fix which instead only prohibites BOM for
> the opposite endianness (for example if
> working-tree-encoding=UTF-16LE, then finding an UTF-16BE BOM in the
> file would cause Git to signal the error right before committing,
> diffing, etc.). That way user would be encouraged to modify the file's
> encoding to match the one specified in working-tree-encoding before
> allowing these actions, therefore preventing Git from encoding to the
> wrong endianness after file is written out. With few repository tests,
> this new behaviour worked as expected. But then I realized this
> solution would perhaps be unacceptable for Git's source code as it
> would violate that Unicode standard. Anyways, here is a PR in my Git
> fork with the changes I did, for reference:

I actually think such a solution (although I haven't looked at your patch) would be fine, and I would encourage you to send it to the list. It's my understanding that many people on Windows want to write things in UTF-16 encoding but only little-endian with a BOM. Allowing them to write that, even if Git won't be able to guarantee producing that, would be fine, as long as the data is what we expect.

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