On Sun, Nov 04, 2018 at 05:37:09PM +0100, Adrián Gimeno Balaguer wrote: > 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
signature.asc
Description: PGP signature
